Write Spec
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Write a feature specification or product requirements document (PRD).
Usage
/write-spec $ARGUMENTS
Workflow
1. Understand the Feature
Ask the user what they want to spec. Accept any of:
- A feature name ("SSO support")
- A problem statement ("Enterprise customers keep asking for centralized auth")
- A user request ("Users want to export their data as CSV")
- A vague idea ("We should do something about onboarding drop-off")
2. Gather Context
Ask the user for the following. Be conversational — do not dump all questions at once. Ask the most important ones first and fill in gaps as you go:
- User problem: What problem does this solve? Who experiences it?
- Target users: Which user segment(s) does this serve?
- Success metrics: How will we know this worked?
- Constraints: Technical constraints, timeline, regulatory requirements, dependencies
- Prior art: Has this been attempted before? Are there existing solutions?
3. Pull Context from Connected Tools
If ~~project tracker is connected:
- Search for related tickets, epics, or features
- Pull in any existing requirements or acceptance criteria
- Identify dependencies on other work items
If ~~knowledge base is connected:
- Search for related research documents, prior specs, or design docs
- Pull in relevant user research findings
- Find related meeting notes or decision records
If ~~design is connected:
- Pull related mockups, wireframes, or design explorations
- Search for design system components relevant to the feature
If these tools are not connected, work entirely from what the user provides. Do not ask the user to connect tools — just proceed with available information.
4. Generate the PRD
Produce a structured PRD with these sections. See PRD Structure below for detailed guidance on what each section should contain.
- Problem Statement: The user problem, who is affected, and impact of not solving it (2-3 sentences)
- Goals: 3-5 specific, measurable outcomes tied to user or business metrics
- Non-Goals: 3-5 things explicitly out of scope, with brief rationale for each
- User Stories: Standard format ("As a [user type], I want [capability] so that [benefit]"), grouped by persona
- Requirements: Categorized as Must-Have (P0), Nice-to-Have (P1), and Future Considerations (P2), each with acceptance criteria
- Success Metrics: Leading indicators (change quickly) and lagging indicators (change over time), with specific targets
- Open Questions: Unresolved questions tagged with who needs to answer (engineering, design, legal, data)
- Timeline Considerations: Hard deadlines, dependencies, and phasing
5. Review and Iterate
After generating the PRD:
- Ask the user if any sections need adjustment
- Offer to expand on specific sections
- Offer to create follow-up artifacts (design brief, engineering ticket breakdown, stakeholder pitch)
PRD Structure
Problem Statement
- Describe the user problem in 2-3 sentences
- Who experiences this problem and how often
- What is the cost of not solving it (user pain, business impact, competitive risk)
- Ground this in evidence: user research, support data, metrics, or customer feedback
Goals
- 3-5 specific, measurable outcomes this feature should achieve
- Each goal should answer: "How will we know this succeeded?"
- Distinguish between user goals (what users get) and business goals (what the company gets)
- Goals should be outcomes, not outputs ("reduce time to first value by 50%" not "build onboarding wizard")
Non-Goals
- 3-5 things this feature explicitly will NOT do
- Adjacent capabilities that are out of scope for this version
- For each non-goal, briefly explain why it is out of scope (not enough impact, too complex, separate initiative, premature)
…