FRD Generator Skill
Generate the complete FRD markdown structure with all required sections, numbering conventions, and platform-specific elements.
Philosophy
A well-structured FRD serves both as client communication and developer specification.
Core Beliefs
- Structure Enables Clarity - Consistent sections help readers find information
- Traceability Through Numbers - Requirements need unique identifiers (FR-001, TR-002)
- Client and Developer Dual Purpose - Balance readability with technical precision
- Platform Context Matters - Drupal recipes need different structure than WordPress blocks
Why FRD Structure Matters
- Organized Information - Clear sections prevent information overload
- Requirement Traceability - Numbered requirements link to tickets and tests
- Professional Quality - Consistent format signals thoroughness
- Developer Reference - Technical sections provide implementation guidance
When to Use This Skill
Activate this skill when:
- Requirements gathering is complete
- Platform and architecture are identified
- Ready to generate the FRD markdown document
- Need to structure requirements into standardized format
- Agent needs to apply FRD templates and numbering
FRD Document Structure
Core Sections (All Projects)
The FRD follows this 10-section structure:
1. Executive Summary
Purpose: High-level overview for stakeholders
Required Content:
- Project vision and business objectives
- High-level scope and key deliverables
- Expected business value and ROI
- Target launch date or milestone
- Success criteria summary
Numbering: None (narrative section)
2. Technical Requirements
Purpose: Platform, architecture, and technology decisions
Required Content:
- Platform & architecture overview (with specific versions)
- Technology stack with justifications
- Architecture patterns (recipe-based, microservices, monolithic)
- Module/package dependencies
- Third-party integrations and APIs
- Performance requirements and SLAs
- Security requirements and data protection
- Development environment setup
Numbering: TR-001, TR-002, TR-003...
Note: Place BEFORE Functional Requirements for technical projects
3. Functional Requirements
Purpose: User stories, features, and business logic
Required Content:
- User stories with acceptance criteria
- Feature specifications with priority levels (Must Have/Should Have/Nice to Have)
- User roles and permissions matrix
- Business logic and workflow descriptions
Numbering:
- FR-001, FR-002, FR-003... (functional requirements)
- US-001, US-002, US-003... (user stories)
Format for Recipe-Based Projects:
## FR-001: saplings_person Recipe [MUST HAVE]
**Purpose**: Provider/staff directory with biographical information
**Recipe Structure**:
- Content Type: Person
- Taxonomies: Specialties, Languages
- Fields: field_phone (SHARED), field_services (SHARED)
- Views: Provider Directory with filters
- Pathauto: /providers/[node:title]
- Image Style: person_headshot (300×300)
**Story Points**: 8 points
**Priority**: Must Have
**Dependencies**: drupal_cms_starter (base fields)
4. User Interface Requirements
Purpose: Design, UX, and accessibility specifications
Required Content:
- Key user flows and wireframe descriptions
- Responsive design requirements (breakpoints)
- Accessibility standards (WCAG compliance level)
- Branding and design system considerations
- Theme/styling approach
Numbering: UI-001, UI-002, UI-003...
5. Data Requirements
Purpose: Data models, storage, and migration
Required Content:
- Data models and entity relationships
- Data validation rules
- Storage and backup requirements
- Data migration needs (if applicable)
- Demo/sample data requirements
Numbering: DR-001, DR-002, DR-003...
Platform-Specific:
- Drupal: Include field storage matrix for shared fields
- WordPress: Include custom post type and taxonomy structure
6. Non-Functional Requirements
Purpose: Performance, scalability, compatibility
Required Content:
- Performance benchmarks (specific tools: Lighthouse, Core Web Vitals)
- Scalability considerations
- Browser/device compatibility matrix
- Availability and uptime requirements
- SEO requirements
Numbering: NFR-001, NFR-002, NFR-003...
7. Implementation Plan
Purpose: Phased delivery with milestones and dependencies
Required Content:
- Phase breakdown with objectives
- Epic and story structure
- Dependencies and critical path
- Risk assessment matrix
- Team velocity assumptions
- Timeline with sprint projections
Numbering: PHASE-1, PHASE-2, PHASE-3...
Format:
## Phase 1: Foundation [21 points, Sprint 1]
**Objective**: Establish development environment and base architecture
**Epics**:
- EPIC-001: Development Environment Setup [8 points]
- EPIC-002: Base Theme Configuration [5 points]
- EPIC-003: Content Model Foundation [8 points]
**Dependencies**: None (critical path start)
**Risks**: Environment compatibility issues
8. Testing Requirements
Purpose: Test scenarios, benchmarks, and UAT process
Required Content:
- Functional test scenarios by feature
- Performance testing benchmarks
- Accessibility testing requirements (WCAG compliance)
- Security testing requirements
- Cross-browser/device testing matrix
- UAT process and timeline
Numbering: TS-001, TS-002, TS-003... (test scenarios)
9. Risk Assessment
Purpose: Identify and mitigate technical and project risks
Required Content:
- Technical risks (integrations, dependencies, performance)
- Project risks (scope, resources, timeline)
- Risk matrix with likelihood and impact
- Mitigation strategies for each risk
- Contingency plans
- Early warning signs
Numbering: RISK-001, RISK-002, RISK-003...
Format: See templates/risk-framework.md
10. Success Criteria
Purpose: Define measurable outcomes
Required Content:
- Functional success metrics (features delivered, tests passed)
- Technical success metrics (performance, accessibility, security)
- Business success metrics (timeline, budget, stakeholder satisfaction)
Numbering: None (metric-based section)
Sprint Planning Section (Appendix)
Add at end of FRD:
Required Content:
- Total story points - Sum of all work
- Suggested sprint breakdown - Based on team velocity
- Critical path identification - Dependencies and blockers
- Next steps for stakeholder review
- Questions requiring client input
- Recommended technical spikes or POCs
- Suggested project kickoff activities
Numbering Conventions
Requirement Prefixes
Use these prefixes for all requirements:
- FR-XXX - Functional Requirements (features, user stories)
- TR-XXX - Technical Requirements (platform, architecture)
- US-XXX - User Stories (specific user-facing scenarios)
- UI-XXX - User Interface Requirements (design, UX)
- DR-XXX - Data Requirements (models, storage)
- NFR-XXX - Non-Functional Requirements (performance, security)
- TS-XXX - Test Scenarios (specific test cases)
- RISK-XXX - Risk Items (identified risks)
- PHASE-X - Implementation Phases (1, 2, 3...)
- EPIC-XXX - Epic Work Items (large features)
Numbering Rules
- Zero-padded: Use 3 digits (001, 002, ..., 999)
- Sequential: Number within each type sequentially
- No Gaps: Don't skip numbers (enables traceability)
- Cross-Reference: Link related requirements (e.g., "See FR-001")
Example:
## Technical Requirements
### TR-001: Drupal 10.2 LTS Platform
The project will use Drupal 10.2 LTS (Long-Term Support) with Composer-based architecture.
**Justification**: LTS version provides stability and security updates through November 2026.
**Dependencies**: PHP 8.1+, MySQL 8.0+, Composer 2.x
**Related Requirements**: FR-001, FR-002 (content types depend on platform)
### TR-002: Recipe-Based Architecture
Use recipe-based architecture for modular, reusable configuration management.
**Structure**: See FR-001 through FR-008 for individual recipe specifications.
**Related Requirements**: DR-001 (shared field storage)
Platform-Specific Section Additions
Drupal Recipe-Based Projects
Add these subsections when recipe architecture is detected:
In Technical Requirements (TR-XXX):
- Recipe architecture overview
- Recipe naming conventions (
[project]_[feature])
- Master recipe structure
- Base recipe dependencies (Drupal CMS, Saplings)
In Functional Requirements (FR-XXX):
- Recipe structure for each feature
- Shared field storage documentation
- Recipe dependencies and installation order
In Data Requirements (DR-XXX):
- Shared field storage matrix (which recipes create/use each field)
- Field storage installation order
- Demo content strategy (Default Content module)
Appendices:
- Recipe dependency diagram
- Shared field storage reference table
- Recipe installation order flowchart
WordPress Block Theme Projects (Future - Phase 2)
To be added in v0.3.0:
- Block/pattern inventory
- theme.json configuration specs
- Core Web Vitals performance budget
- Plugin dependency justification
Output Format Guidelines
Document Formatting
Headers:
- Use
# for document title
- Use
## for major sections
- Use
### for requirement items
- Use
#### for subsections within requirements
Lists:
- Use
- for unordered lists
- Use
1. for ordered lists (sequential steps)
- Indent sublists with 2 spaces
Emphasis:
- Use
**bold** for labels (Purpose, Priority, Story Points)
- Use
_italic_ for notes and clarifications
- Use
> blockquotes for user stories
Code:
- Use
`inline code` for commands, paths, field names
- Use triple backticks for code blocks with language identifier
Tables:
- Use markdown tables for matrices (permissions, risks, dependencies)
- Include header row with alignment
- Keep columns readable
Writing Style
Client-Facing Sections (Executive Summary, Functional Requirements, UI Requirements):
- Clear, jargon-free language
- Business value emphasized
- "You" and "your users" language
- Benefits over features
Developer-Facing Sections (Technical Requirements, Data Requirements, Implementation Plan):
- Technical precision
- Specific versions and tools
- Architecture decisions justified
- Implementation guidance included
Shared Sections (Non-Functional Requirements, Testing, Success Criteria):
- Balance technical and business language
- Measurable criteria
- Specific benchmarks
- Testable outcomes
Cross-Referencing
Link related requirements:
- "See FR-001 for feature details"
- "Depends on TR-002 (recipe architecture)"
- "Relates to RISK-003 (integration complexity)"
- "Tested in TS-005"
Visual Aids
Include placeholders for diagrams:
- Architecture diagrams
- User flow diagrams
- Data relationship diagrams
- Recipe dependency flowcharts
- Risk matrix tables
Format:
**[Diagram: User Authentication Flow]**
_Placeholder for diagram showing registration → verification → login flow_
FRD Generation Workflow
Step 1: Initialize Document
Start with frontmatter and title:
---
title: Functional Requirements Document
project: [Project Name]
version: 1.0
date: [YYYY-MM-DD]
author: [Author Name]
status: Draft
---
# Functional Requirements Document: [Project Name]
**Version**: 1.0
**Date**: [Current Date]
**Status**: Draft
Step 2: Generate Each Section
Follow the 10-section structure:
- Executive Summary (narrative)
- Technical Requirements (TR-XXX)
- Functional Requirements (FR-XXX, US-XXX)
- User Interface Requirements (UI-XXX)
- Data Requirements (DR-XXX)
- Non-Functional Requirements (NFR-XXX)
- Implementation Plan (PHASE-X, EPIC-XXX)
- Testing Requirements (TS-XXX)
- Risk Assessment (RISK-XXX)
- Success Criteria (metrics)
Step 3: Add Platform-Specific Content
If Drupal + Recipe-Based:
- Add recipe structure to FR-XXX items
- Include shared field storage matrix in DR section
- Add recipe dependency diagram to appendix
If WordPress + Block Theme (future):
- Add block/pattern inventory
- Include theme.json specs
Step 4: Add Appendices
Include as needed:
- Glossary of terms
- Acronym definitions
- Dependency diagrams
- Field storage matrices
- Sprint planning details
Step 5: Number Requirements
Ensure all requirements have proper prefixes:
- Count each type separately
- Use zero-padded 3-digit numbers
- Verify no gaps in sequence
Step 6: Cross-Reference
Add links between related requirements:
- Link dependencies
- Reference related risks
- Connect requirements to test scenarios
Templates
Detailed templates are available for reference:
Use these templates as starting points, customizing for the specific project needs.
Integration with frd-specialist Agent
This skill is invoked by the frd-specialist agent after:
- Platform detection complete
- Requirements gathering finished
- Story point estimation applied (via story-point-estimator skill)
The frd-specialist orchestrates the workflow and passes structured requirements to this skill for formatting.
Example Output Structure
See templates/frd-structure.md for a complete example with all sections populated.
Quick preview of structure:
# Functional Requirements Document: Healthcare Provider Directory
## Executive Summary
[Narrative overview...]
## Technical Requirements
### TR-001: Drupal 10.2 LTS Platform
[Platform details...]
### TR-002: Recipe-Based Architecture
[Architecture details...]
## Functional Requirements
### FR-001: saplings_person Recipe [MUST HAVE]
[Recipe structure...]
### US-001: View Provider Directory
> As a site visitor, I need to search for healthcare providers so that I can find appropriate care.
[User story details...]
## [Continue with remaining sections...]
## Appendix A: Risk Assessment Matrix
[Risk table...]
## Appendix B: Sprint Planning
[Sprint breakdown...]
Best Practices
- Consistent Structure - Always use the 10-section format
- Complete Numbering - Never skip requirement numbers
- Platform Context - Add platform-specific sections when appropriate
- Cross-Reference - Link related requirements throughout
- Balance Audiences - Write for both clients and developers
- Visual Aids - Include diagram placeholders where helpful
- Measurable Criteria - Make success criteria testable
- Traceability - Number requirements for ticket linking
Resources