Draft a product spec

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: ...].

# <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.