---
description: Draft a product spec (PRD) for a feature or initiative, pulling context from Notion, Slack, and Drive first so the draft isn't starting from zero. Produces a draft — does not publish to Notion without approval.
disable-model-invocation: true
argument-hint: "<feature name or one-line description>"
---

# Draft a product spec

**Invocation: user only.** Drafts a spec; saves to Notion only after explicit approval.

## Workflow

### 1. Sharpen the ask

From $ARGUMENTS, identify:
- The feature or problem name
- The target user segment (if mentioned)
- Any constraints (deadline, team capacity, scope hints)

If the ask is vague ("do something about onboarding"), ask 1-2 clarifying questions — don't guess the problem.

### 2. Pull context (in parallel)

- **Notion:** search for existing specs, RFCs, or notes matching the feature name or related concepts. If a draft exists, use it as the base — don't start over.
- **Slack:** search recent messages in product/eng channels for the feature name or key concepts. Surface 3-5 most relevant threads with links.
- **Drive:** search for decks or docs with matching names.
- **Fathom (if applicable):** recent meetings mentioning the feature — pull the summaries, not transcripts.

Report what you found before drafting. The user should be able to say "use the Sept 14 thread, ignore the rest."

### 3. Draft the spec

Use this template. Fill what you have; mark gaps clearly with `[NEEDS INPUT: ...]`.

```markdown
# <Feature name>

**TL;DR** <one sentence. What and why.>

**Status:** draft  ·  **Owner:** <user>  ·  **Date:** <today>

## Problem
<2-3 paragraphs. Who has the problem, how often, what's the cost of not solving.>

## Users
<Specific segment(s). Numbers if we have them.>

## Goals
- <primary outcome — measurable if possible>
- <secondary>

## Non-goals
- <what this explicitly does not do — prevents scope creep>

## Proposed solution
<What we're going to build. Lead with user-facing behavior, not implementation.>

## Open questions
- [ ] <question>  — needs input from <eng | design | legal | ...>
- [ ] ...

## Risks
- <risk>: <mitigation or "accepted">

## Rollout
<How we'll ship — behind a flag? staged rollout? internal first?>

## Metrics
- Primary: <metric + target + timeline>
- Secondary: <metric>

## Appendix — context we pulled
- <Slack link>: <one line>
- <Notion link>: <one line>
```

### 4. Review with the user

Show the draft. Ask:
- Anything factually wrong?
- Any `[NEEDS INPUT]` the user can resolve right now?
- Where does this live in Notion? (Default: the team's specs path from CLAUDE.md, but confirm.)

### 5. Publish (only on approval)

On "ship it" / "publish" / equivalent:
1. Create the Notion page at the agreed path via the Notion MCP.
2. Return the Notion URL.
3. Offer to draft a Slack post announcing the spec (use `/team-core:draft-email`-style flow — draft first, send on approval).

## Don't

- Don't invent metrics. If you don't have a baseline number, say `[NEEDS INPUT: current baseline]`.
- Don't write a Solution section without a Problem section.
- Don't publish to Notion without confirming the target path.