Prd

Core Principles

• Read-only (source code modification prohibited)
• Faithfully reflect input file content (do not add or remove requirements arbitrarily)
• Mark ambiguous descriptions as "[Needs Confirmation]" and present options
• Output is intended for human review and approval
• Maintain consistency with existing docs/ documentation

Usage

/prd <path-to-requirement-notes>

File paths can be absolute or relative. Specify multiple files separated by spaces.

Examples

/prd requirements.md
/prd input/requirements/REQ_001.md
/prd memo1.md memo2.md

Output Destination

• Default: output/prd/PRD_<feature-name>.md (when output/ directory exists)
• Fallback: docs/PRD.md

Integration with Other Skills

Workflow

Phase 1: Input Analysis

1. File Reading — Read the provided files using the Read tool
2. Structural Analysis — Classify the types of requirements:
   • New feature additions
   • Changes/improvements to existing features
   • Bug fixes
   • Non-functional requirements (performance, security, etc.)
3. Terminology Extraction — Extract and define domain-specific terms

Phase 2: Current State Investigation

1. Existing Codebase Survey — Identify related existing features, components, and stores
2. Existing Documentation Review — Check related information under docs/
3. Technical Constraints — Organize constraints from tech stack and architecture

Phase 3: PRD Generation

1. Structuring — Generate the PRD following the output format below
2. Consistency Check — Verify no contradictions or gaps between requirements
3. Ambiguity Flagging — Mark items requiring decisions as "[Needs Confirmation]"

Phase 4: Output

1. File Output — Write to output/prd/PRD_<feature-name>.md (or docs/PRD.md if output/ doesn't exist)
2. Summary Presentation — Present a PRD overview to the user

Output Format

# PRD: [Feature/Project Name]

> Source: [Input file name]
> Generated: [YYYY-MM-DD]
> Status: Draft

## 1. Overview

### 1.1 Background & Purpose
### 1.2 Scope

#### In Scope
#### Out of Scope

## 2. Terminology

| Term | Definition |
| ---- | ---------- |

## 3. Functional Requirements

### FR-001: [Feature Name]
- **Summary**: [Feature description]
- **User Story**: As a [who], I want to [what] so that [why]
- **Acceptance Criteria**:
  - [ ] [Specific condition]
- **Screen/Interaction Flow**: [UI behavior description]
- **Data Model Changes**: [Required schema changes]
- **Priority**: Must / Should / Could / Won't

## 4. Non-Functional Requirements

### NFR-001: [Requirement Name]
- **Category**: Performance / Security / Usability / Maintainability
- **Requirement**: [Specific criteria]
- **Measurement Method**: [How to verify]

## 5. Data Model

### New Schemas
### Existing Schema Changes

| Schema | Field | Change Description | Backward Compatibility |
| ------ | ----- | ------------------ | ---------------------- |

## 6. Screen/UI Specifications
## 7. Technical Considerations
## 8. Test Strategy
## 9. Implementation Phases (Recommended)
## 10. Items Requiring Confirmation

| # | Item | Options | Impact Scope |
| - | ---- | ------- | ------------ |

## 11. Risks & Concerns

| Risk | Impact Level | Mitigation |
| ---- | ------------ | ---------- |

Output Contract

Section Definitions

Functional Requirement (FR) Writing Constraints

• FR IDs are sequential from FR-001, zero-padded to 3 digits
• Acceptance criteria use "shall" phrasing (verifiable statements)
• Priority enumeration values: Must / Should / Could / Won't

Vocabulary Constraints

Structural Constraints

• Sections are output in numerical order (1–11)
• Do not add requirements to FRs that are not in the input memo
• Do not decide technology choices; present options and rationale
• [Needs Confirmation] must always include options (Option A/Option B) and impact scope

PRD Quality Checklist

• All requirements from the input memo are reflected in FR/NFR
• Each functional requirement has acceptance criteria
• Acceptance criteria are specific and testable
• Data model changes consider backward compatibility
• Consistent with existing architecture
• Ambiguous points are flagged as "[Needs Confirmation]"
• Terminology is consistent throughout
• In scope/out of scope are clearly defined

Consistency with Existing Documentation

Reference the following documents during PRD generation to ensure consistency:

Output Files

• When output/prd/ directory exists: output/prd/PRD_<feature-name>.md
• Fallback: docs/PRD.md
• If already exists: Confirm overwrite with the user
• When multiple PRDs are needed: Name as PRD_<feature-name>.md

Prohibited Actions

• Modifying source code (including test files)
• Adding requirements not in the input memo (do not inflate features with guesses)
• Making final technology decisions (limit to presenting options and rationale)
• Including project-specific data (IDs, passwords, etc.) in documentation
• Modifying existing documentation (under docs/)