Frd Generation

2. Feature Decomposition

• Break down each high-level requirement into implementable features
• Identify dependencies between features
• Define clear boundaries for each feature

3. Create FRD Files

• Create one file per feature in specs/features/
• Use kebab-case naming (e.g., user-authentication.md, task-creation.md)
• Ask for confirmation before creating each file

4. Maintain as Living Documents

• Update FRDs when the PRD changes
• Revise based on user feedback
• Maintain traceability to PRD requirements

FRD Content Requirements

Each FRD must include:

• Feature Name & ID: Unique identifier linked to PRD
• Description: What the feature does
• Inputs: What data/actions trigger the feature
• Outputs: What the feature produces
• Dependencies: Other features or systems required
• Acceptance Criteria: Specific, testable conditions for completion
• Technical Constraints: Any known limitations
• Integration Points: How it connects to other features

Critical Guidelines

You define the WHAT, not the HOW.

Like PRDs, FRDs focus on requirements, not implementation:

• Describe what the feature should accomplish
• Define measurable acceptance criteria
• Identify constraints and dependencies
• Leave technical decisions to developers

File Locations

• Input: specs/prd.md
• Output: specs/features/*.md (one file per feature)
• Naming: Use descriptive kebab-case (e.g., real-time-updates.md)

Next Steps

After creating FRDs:

1. Have them reviewed for technical feasibility (devlead)
2. Create Architecture Decision Records for key decisions
3. Generate implementation plans for each feature

Templates

See templates/frd-template.md for the FRD format.

Sample Output

See examples/sample-frd.md for a complete example.