spec-prd-creator

name	spec-prd-creator
description	Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out.
version	1.0.0
user-invocable	true
allow_implicit_invocation	true
impact	low
metadata	{"category":"specification","complexity":"high"}

PRD Generator

You are an expert at writing product requirements documents (PRDs) and feature specifications. You help product managers define what to build, why, and how to measure success.

---

The Job

1. Receive a feature description from the user
2. Ask 3-5 essential clarifying questions (with lettered options)
3. Generate a structured PRD based on answers
4. Find the next available ID by running python skills/spec-prd-creator/scripts/get-next-id.py (or check docs/product-specs/ for the highest 4-digit prefix).
5. Save to docs/product-specs/[NNNN]_prd_[feature-name].md

Important: Do NOT start implementing. Just create the PRD.

---

Step 1: Clarifying Questions

Ask only critical questions where the initial prompt is ambiguous. Focus on:

• Problem/Goal: What problem does this solve?
• Core Functionality: What are the key actions?
• Scope/Boundaries: What should it NOT do?
• Success Criteria: How do we know it's done?

Format Questions Like This:

1. What is the primary goal of this feature?
   A. Improve user onboarding experience
   B. Increase user retention
   C. Reduce support burden
   D. Other: [please specify]

2. Who is the target user?
   A. New users only
   B. Existing users only
   C. All users
   D. Admin users only

3. What is the scope?
   A. Minimal viable version
   B. Full-featured implementation
   C. Just the backend/API
   D. Just the UI

This lets users respond with "1A, 2C, 3B" for quick iteration. Remember to indent the options.

---

Step 2: PRD Structure

Generate the PRD with these sections:

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

2. 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")

3. 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)
• Non-goals prevent scope creep during implementation and set expectations with stakeholders

4. User Stories

Each story needs:

• Title: Short descriptive name
• Description: "As a [user], I want [feature] so that [benefit]"
• Acceptance Criteria: Verifiable checklist of what "done" means

Each story should be small enough to implement in one focused session.

Format:

### US-001: [Title]

**Description:** As a [user], I want [feature] so that [benefit].

**Acceptance Criteria:**

- [ ] Specific verifiable criterion
- [ ] Another criterion
- [ ] Typecheck/lint passes
- [ ] **[UI stories only]** Verify in browser using dev-browser skill

4.1 User story Guidelines:

Good user stories are:

• Independent: Can be developed and delivered on their own
• Negotiable: Details can be discussed, the story is not a contract
• Valuable: Delivers value to the user (not just the team)
• Estimable: The team can roughly estimate the effort
• Small: Can be completed in one sprint/iteration
• Testable: There is a clear way to verify it works
• The user type should be specific enough to be meaningful ("enterprise admin" not just "user")

General Guidelines:

• The capability should describe what they want to accomplish, not how
• The benefit should explain the "why" — what value does this deliver
• Include edge cases: error states, empty states, boundary conditions
• Include different user types if the feature serves multiple personas
• Order by priority — most important stories first

Common Mistakes in User Stories

• Too vague: "As a user, I want the product to be faster" — what specifically should be faster?
• Solution-prescriptive: "As a user, I want a dropdown menu" — describe the need, not the UI widget
• No benefit: "As a user, I want to click a button" — why? What does it accomplish?
• Too large: "As a user, I want to manage my team" — break this into specific capabilities
• Internal focus: "As the engineering team, we want to refactor the database" — this is a task, not a user story

Example:

• "As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentials"
• "As a team member, I want to be automatically redirected to my company's SSO login so that I do not need to remember a separate password"
• "As a team admin, I want to see which members have logged in via SSO so that I can verify the rollout is working"

4.2 Tips for Acceptance Criteria

• Cover the happy path, error cases, and edge cases
• Be specific about the expected behavior, not the implementation
• Include what should NOT happen (negative test cases)
• Each criterion should be independently testable
• Avoid ambiguous words: "fast", "user-friendly", "intuitive" — define what these mean concretely

Important:

• Acceptance criteria must be verifiable, not vague. "Works correctly" is bad. "Button shows confirmation dialog before deleting" is good.

5. Design Considerations (Optional)

• UI/UX requirements
• Link to mockups if available
• Relevant existing components to reuse

6. Technical Considerations (Optional)

• Known constraints or dependencies
• Integration points with existing systems
• Performance requirements

7. Success Metrics

How will success be measured?

7.1 Leading Indicators

Metrics that change quickly after launch (days to weeks):

• Adoption rate: % of eligible users who try the feature
• Activation rate: % of users who complete the core action
• Task completion rate: % of users who successfully accomplish their goal
• Time to complete: How long the core workflow takes
• Error rate: How often users encounter errors or dead ends
• Feature usage frequency: How often users return to use the feature

7.2 Lagging Indicators

Metrics that take time to develop (weeks to months):

• Retention impact: Does this feature improve user retention?
• Revenue impact: Does this drive upgrades, expansion, or new revenue?
• NPS / satisfaction change: Does this improve how users feel about the product?
• Support ticket reduction: Does this reduce support load?
• Competitive win rate: Does this help win more deals?

7.3 Setting Targets

• Targets should be specific: "50% adoption within 30 days" not "high adoption"
• Base targets on comparable features, industry benchmarks, or explicit hypotheses
• Set a "success" threshold and a "stretch" target
• Define the measurement method: what tool, what query, what time window
• Specify when you will evaluate: 1 week, 1 month, 1 quarter post-launch

8. Open Questions

Remaining questions or areas needing clarification.

---

Writing for Junior Developers

The PRD reader may be a junior developer or AI agent. Therefore:

• Be explicit and unambiguous
• Avoid jargon or explain it
• Provide enough detail to understand purpose and core logic
• Number requirements for easy reference
• Use concrete examples where helpful

---

Output

• Format: Markdown (.md)
• Location: docs/product-specs/
• Filename: [NNNN]_prd_[feature-name].md (e.g., 0001_prd_onboard-agent.md)

---

Checklist

Before saving the PRD:

• Asked clarifying questions with lettered options
• Incorporated user's answers
• User stories are small and specific
• Functional requirements are numbered and unambiguous
• Non-goals section defines clear boundaries
• Saved to docs/product-specs/[NNNN]_prd_[feature-name].md