PRD & Product Feature Requirement Spec

What it does

/feature-spec is a Cursor slash command. Type it in chat to run a saved workflow: PRD & Product Feature Requirement Spec.

Drafts comprehensive PRD specifications: user personas, functional requirements, technical edge cases, success metrics, and acceptance criteria.

Product Requirement Documents with user stories, acceptance criteria, and scopes. Unlike a skill, a command is something you invoke on purpose. The agent does not decide to run /feature-spec for you.

Why it exists

Founders retype the same multi-step prompt until it rots. /feature-spec exists so the pipeline, all 4 steps of it, is a file in .cursor/commands, versioned with the repo.

It ships in the Marketing Kit. It is wired to the Technical Lead & System Architect (tech-lead) and User & JTBD Researcher (market-researcher) agents. Required skills: Jobs-To-Be-Done (JTBD) Customer Research; SaaS Architecture Patterns & Multi-Tenancy.

When to use it

• Use before starting development on complex multi-week features.
• Use /feature-spec when you want that pipeline, not a freeform chat. If you only need one step, use a narrower command or a single agent.
• Start a new chat. Do not run this command in a thread that just touched production SQL.

When not to use it

• Do not run /feature-spec as a substitute for reading the diff. The command produces files; you still gate them.
• Do not chain it into a 40-turn chat. Fresh context is part of the design.
• Do not run it if you have not filled CURSOR.md. The pipeline will invent a stack.

Example workflow

1. Define user problem statement and target customer personas
2. List detailed user stories in 'As a... I want to... So that...' format
3. Specify technical acceptance criteria and edge case handling
4. Auto-save PRD specification to docs/specs/feature-name.md

Example usage

Type this in Cursor chat: /feature-spec Draft PRD for team collaboration and workspace sharing with RBAC

The command file tells the session which agents to adopt and which skills to read. You should see phase headers, not a single dump of code.

If a phase fails its gate, stop. Do not add 'just continue'.

Example output

• Expected artifact: docs/specs/...md

Best practices

• Keep the prompt specific. /feature-spec Draft PRD for team collaboration and workspace sharing with RBAC is the shape: object, constraint, and outcome.
• Let the listed agents work in order: tech-lead → market-researcher.
• Save outputs in the repo. Chat-only answers evaporate.
• Marketing commands write to docs/marketing/ so the next command can read positioning before it writes a landing page.

Common mistakes

• Typing /feature-spec with no object ('do the thing'). The pipeline will guess.
• Re-running the command in the same chat after a failed gate instead of fixing the failing file.
• Editing the command file to skip review so it 'goes faster'.
• Skipping the Jobs-To-Be-Done (JTBD) Customer Research skill that the command depends on.