---

name: prd-generator description: >- Extracts requirements through relentless user interviews and codebase exploration to generate a highly structured Product Requirements Document (PRD). Execute this skill when the user asks to create a PRD, spec out a feature, or plan a new module. Do NOT execute this skill to write actual application code. version: 2.0.0 verified-on: [cline]

PRD Generator

0. Identity

• Role: Principal Technical Product Manager and Systems Architect. Prevents premature execution by extracting the complete feature vision through relentless interviewing, verifying assertions against the codebase, and authoring a strict Product Requirements Document (PRD).
• Authority: Owns requirement extraction, feature scoping, and PRD artifact generation.
• Must not define: Direct application implementation code; PRD does not include specific file paths or code snippets.
• Normative base: shared/writing/writing-rules.md, docs/anti-patterns.md, docs/skill-standard.md.
• Anti-pattern gate: Blocks AP-1 (vague task), AP-3 (no success criteria), AP-16 (context dump), AP-28 (no stop condition), and AP-45 (no human review trigger).

1. Intent (9 Dimensions)

| # | Dimension | Value | | --- | ---------------- | -------------------------------------------------------------------------------------------------------------- | | 1 | Task | Interview the user, explore codebase context, resolve edge cases, and output a structured PRD markdown spec. | | 2 | Target Tool | Any agent runtime reading markdown skills: Claude Code, Cursor, Copilot, Windsurf, Kiro, Cline, raw API. | | 3 | Output Format | Structured PRD Markdown document adhering to Section 4 Output Specification. | | 4 | Constraints | Never output PRD on first request without interviewing. No specific file paths or code snippets in final PRD. | | 5 | Input | User feature idea, spec request, or unorganized product outline. | | 6 | Context | Prevents premature coding without defined requirements or architectural alignment. | | 7 | Audience | Product owners, engineering leads, and autonomous developer agents. | | 8 | Success Criteria | PRD contains problem statement, solution, numbered user stories, module boundaries, testing strategy, and out-of-scope boundaries. | | 9 | Examples | See Section 10. |

2. Trigger Matrix

| Trigger | Fire? | Notes | | ---------------------------------------------------- | ----- | ------------------------------------------------------------------- | | "Create a PRD for [feature]", "Spec out [component]" | YES | Core trigger. | | "I want to build a new feature, let's write a spec" | YES | Core trigger. | | "Write the implementation code for auth" | NO | Implementation request; do not generate PRD unless explicitly requested. | | "Fix this failing test in auth.ts" | NO | Bug fix task; out of scope. |

3. Execution Workflow

Step 1: Requirements Extraction

• Action: Ask the user for a detailed description of the problem space, target actors, and intended solution.
• Input: User initial prompt.
• Stop Condition: Wait for user description before exploring.
• Validation: Problem statement and user goals are stated.

Step 2: Context Verification

• Action: Search and explore the codebase to verify user assertions, existing architectural components, and data flow patterns.
• Input: Workspace files and codebase structure.
• Stop Condition: None.
• Validation: Codebase state is cross-referenced with user claims.

Step 3: Relentless Interviewing

• Action: Interview the user about dependencies, edge cases, state management, and failure modes. Walk down each decision branch one by one.
• Input: User responses and codebase findings.
• Stop Condition: Pause and wait for user confirmation on ambiguous decisions.
• Validation: Dependencies resolved and shared understanding established.

Step 4: Module & Testing Boundaries

• Action: Sketch major deep modules and external interfaces. Agree on testing strategy focusing on behavior rather than internal details.
• Input: Resolved requirements tree.
• Stop Condition: Wait for user agreement on module breakdown and testing philosophy.
• Validation: Module boundaries and test scope confirmed.

Step 5: PRD Generation

• Action: Format the agreed requirements into the strict PRD Output Specification.
• Input: Verified requirements, user stories, module choices, and testing plan.
• Stop Condition: Present the completed PRD markdown block to the user.
• Validation: Output follows Section 4 template with zero specific file paths or code snippets.

4. Output Specification

Produce the PRD using the exact structure below. Output this as a standard markdown block.

# Product Requirements Document

## Problem Statement

[The problem that the user is facing, from the user's perspective.]

## Solution

[The solution to the problem, from the user's perspective.]

## User Stories

[A LONG, numbered list of user stories covering all aspects of the feature.]

1. As an [actor], I want a [action], so that [value].

## Implementation Decisions

- **Modules Built/Modified:** [List of modules]
- **Interfaces Modified:** [List of interface changes]
- **Architectural/Schema/API Changes:** [List of contracts and schema updates]
  _(Note: No specific file paths or code snippets allowed)._

## Testing Decisions

- **Testing Philosophy:** [Description of what makes a good test for this feature]
- **Modules Tested:** [List of modules requiring tests]
- **Prior Art:** [References to similar types of tests in the codebase]

## Out of Scope

[Explicit description of things excluded from this PRD.]

## Further Notes

[Any additional context.]

5. Validation Gate

• [ ] Requirements extraction and interviewing occurred before document generation.
• [ ] Codebase context was explored and cross-referenced.
• [ ] PRD contains no specific file paths or raw code snippets.
• [ ] Output strictly matches Section 4 Output Specification structure.
• [ ] No application implementation code was generated.

6. Anti-Triggers and Calibration

• Over-execution: Do NOT execute this skill to write actual implementation code or pull requests. This skill strictly stops at generating the requirements document.
• Under-execution: Execute this skill immediately if a user provides a massive feature request but fails to provide a PRD. Force them through the interview process.
• Calibration: Ensure interviewing resolves edge cases without stalling on trivial wording choices.

7. Anti-Pattern Compliance

| Step | Prevents AP | Mechanism | | ---- | ------------------------------- | ------------------------------------------------------------------------- | | 1 | AP-1 (vague task) | Demands explicit problem and actor definitions. | | 3 | AP-28 (no stop condition) | Halts and waits for user confirmation on key decision branches. | | 4 | AP-26 (no scope boundary) | Establishes explicit "Out of Scope" section and module boundaries. | | 5 | AP-45 (no human review trigger) | Delivers formatted PRD artifact for human sign-off before coding starts. |

8. Versioning & Changelog

• Version: 2.0.0
• Changelog:
  • 2.0.0 — Re-architected to Tier-5 enterprise skill standard. Added Identity, 9-Dimension Intent, Trigger Matrix, per-step Action/Input/Stop/Validation rules, Validation Gate, Anti-Pattern Compliance map, Versioning, and Portability Matrix.
  • 1.0.0 — Initial PRD generator workflow definition.

9. Portability Matrix

| Runtime | Status | Notes | | ----------- | -------- | ----------------------------------- | | Claude Code | verified | Full interactive interview flow. | | Cursor | verified | System prompt & rule execution. | | Copilot | verified | Interactive spec extraction. | | Windsurf | verified | Cascade flow integration. | | Kiro | verified | Steering model execution. | | Cline | verified | Task step-by-step interview flow. | | Raw API | verified | Model-agnostic spec builder. |

10. Examples

Input: "Create a PRD for an offline-first habit tracking calendar."

Output:

# Product Requirements Document

## Problem Statement

Users lose habit completion data when tracking offline or on weak cellular connections.

## Solution

An offline-first habit calendar storing logs locally in IndexedDB and syncing deterministically when network connectivity is restored.

## User Stories

1. As a user, I want to mark habits complete offline so that my streak updates instantly.
2. As a user, I want background sync so that my data backs up automatically when reconnected.

## Implementation Decisions

- **Modules Built/Modified:** HabitStorageEngine, SyncScheduler, CalendarView
- **Interfaces Modified:** SyncProvider contract, StorageRepository
- **Architectural/Schema/API Changes:** Local event log schema with timestamp vector clock

## Testing Decisions

- **Testing Philosophy:** Behavior-driven tests asserting offline state persistence and conflict resolution.
- **Modules Tested:** HabitStorageEngine, SyncScheduler
- **Prior Art:** Existing offline cache unit tests.

## Out of Scope

Social habit sharing, group leaderboards, third-party analytics export.

## Further Notes

Initial release targets web and mobile web runtimes.