write-spec

name	write-spec
description	Write a feature spec or PRD from a problem statement or feature idea. Use when creating product requirements documents.
argument-hint	<feature or problem statement>

/write-spec — Feature Specification

Write a feature specification or product requirements document (PRD).

Activated role

When /write-spec runs, activate the Product Manager role — they own PRD creation, user stories, and acceptance criteria. For roadmap-level prioritisation calls, escalate to the Head of Product.

Design-heavy features should also involve the UX Designer (for user flows) and the UI Designer (for component specs) once the PRD has a problem statement. Technical feasibility review happens at the Tech Design phase, not here — the /write-spec output hands off to the Tech Lead who activates for Phase 2.

See .claude/rules/role-triggers.md for the full activation protocol.

Usage

/write-spec SSO support for enterprise
/write-spec Users want to export data as CSV
/write-spec We need better onboarding

Workflow

1. Understand the Feature

Accept any of: a feature name, a problem statement, a user request, or a vague idea.

2. Gather Context

Ask conversationally:

• User problem — what problem does this solve? Who experiences it?
• Target users — which user segment(s)?
• Success metrics — how will we know this worked?
• Constraints — technical, timeline, dependencies?
• Prior art — has this been attempted before?

3. Pull Context from Connected Tools

If the project has integrations available:

• GitHub Issues (the default tracker) — search for related issues, epics, or features in the project's repo. Teams using other trackers (Linear, Jira) can substitute the equivalent search.
• Notion / Confluence — search for related research, specs, or design docs
• Figma — pull related mockups or wireframes

4. Generate the PRD

Resolve the PRD template via the portfolio helper so adopter overrides win when present:

source "$(git rev-parse --show-toplevel)/.claude/hooks/_lib-read-config.sh"
source "$(git rev-parse --show-toplevel)/.claude/hooks/_lib-portfolio-paths.sh"
template=$(portfolio_resolve_template prd.md)   # → custom-templates/prd.md if present, else templates/prd.md

Single-fork adopters (no portfolio block) and adopters with no override fall straight through to templates/prd.md. Adopters who want a customised PRD shape drop their version at <private_repo>/custom-templates/prd.md. See templates/README.md for the path-mirroring convention.

The PRD should include:

# {Feature Name} — PRD

## Problem Statement
## Goals
   3–5 specific, measurable outcomes

## Non-Goals
   3–5 things explicitly out of scope

## User Stories
   As a [user type], I want [capability] so that [benefit]

## Requirements
### Must-Have (P0)
### Nice-to-Have (P1)
### Future (P2)

## Success Metrics
### Leading Indicators (days–weeks)
### Lagging Indicators (weeks–months)

## Open Questions
## Timeline

5. Review and Iterate

After generating the draft: ask if sections need adjustment, offer follow-ups.

6. Create the Tracking Ticket

Offer to create an epic / feature ticket in the team's tracker with the PRD content.

---

Part of ApexYard — multi-project SDLC framework for Claude Code · MIT.