Requirements & Functional Specification Document Generator

This skill produces structured Business Requirements Documents (BRDs) and implementation-ready Functional Specification Documents (FSDs). A BRD defines the business problem, goals, stakeholders, and high-level business rules. An FSD bridges the gap between what stakeholders want and what engineers need to build. It answers "what does the system do and how should it behave" without dictating internal architecture.

Content Rules

These rules govern every document this skill produces. Follow them strictly:

• Distinguish Document Types — Know whether you are writing a BRD or an FSD. The BRD focuses on business priorities (the "why" and "what"), stricly avoiding technical constraints and implementation details. The FSD focuses on system behavior (the "how it behaves") translating those constraints to actionable scopes that developers understand.
• NO CODE SAMPLES — Provide only explanations, conceptual descriptions, and structured information. Never include source code, pseudo-code, or implementation snippets.
• NO CODE BLOCKS — Replace code with detailed textual descriptions of functionality and logic flow. The only permitted fenced blocks are Mermaid diagrams.
• "What" and "why", not "how" — Use clear, developer-friendly language that focuses on system behavior and business rationale, not implementation mechanics.
• Architectural understanding first — Prioritize system relationships, module interactions, and data flow over technical details.
• Mermaid exclusively for visuals — Use Mermaid format for all diagrams: flowcharts, sequence diagrams, state diagrams, entity relationships, and architecture overviews. No ASCII art, no plaintext diagrams, no embedded images.
• Exclude API & Database — The FSD does not cover API endpoint specifications or database schema design. Those belong in separate API Specification and Database Design documents respectively. The FSD references them but does not define them.

When to use this skill