How do I install the Fsd Generator skill?

Run npx skillmds@latest add tomevault-io/fsd-generator in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Fsd Generator safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Fsd Generator?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Fsd Generator free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Fsd Generator?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Fsd Generator by tomevault-io — Agent Skill

Name: Fsd Generator
Author: tomevault-io

Fsd Generator

Generate comprehensive Functional Specification Documents (FSDs) that translate PRD requirements into implementation-ready specifications. Use when the user needs to create an FSD, functional spec, system specification, or detailed feature specification. Triggers on requests like "create an FSD", "write functional specifications", "translate this PRD into specs", or any request to define system behaviors, data requirements, business rules, and acceptance criteria from a PRD or feature description. Use when this capability is needed.

tomevault-io aa17080 2 files · 3.9 KB Updated Sep 17, 2026

File contents

Functional Specification Document (FSD) Generator

Role

Senior Technical Business Analyst and Solutions Architect. Specializes in translating PRDs into implementation-ready functional specifications that bridge business vision and technical implementation.

Objective

Generate a complete FSD that converts PRD requirements into precise functional specifications, system behaviors, data requirements, and acceptance criteria — usable directly by development teams.

Process

Step 1: Analyze the PRD

Extract from the provided PRD:

All business requirements and user stories
Core features and their priorities
User personas mapped to functional needs
Constraints, assumptions, and dependencies

If no PRD is provided, gather the necessary information from the user:

Must-have (ask first):

Product/feature name and description
Core user stories or requirements
User roles and permissions
Key business rules

Important (ask second):

Data entities and relationships
Integration or API requirements
Error handling expectations
Non-functional constraints (performance, security)

Step 2: Generate the FSD

Use the template in references/template.md as the output structure.

Key generation rules:

Convert each PRD item into specific, testable functional requirements with unique IDs (FR-XXX)
Establish requirement traceability back to PRD sections
Use Given-When-Then for all acceptance criteria
Define business rules as atomic, non-contradictory rules (BR-XXX)
Use MoSCoW prioritization (Must Have / Should Have / Could Have / Won't Have)
Use precise language — "shall", "will", "must" instead of "should", "might", "could"
Include negative test scenarios (what should NOT happen)
Every PRD requirement must map to at least one functional specification
If the PRD is vague, document gaps in "Open Questions/TBD Items" and mark assumptions clearly

Step 3: Review & Refine

Present the generated FSD to the user. Flag any PRD inconsistencies or conflicts identified during generation. Iterate on feedback until approved.

Quality Checklist

Every PRD requirement maps to at least one functional specification
All requirements are SMART (Specific, Measurable, Achievable, Relevant, Testable)
Each acceptance criterion is verifiable by QA
Business rules are atomic and non-contradictory
Data specifications cover all functional requirements
Traceability matrix links every PRD item to FSD requirements

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: fsd-generatordescription: Generate comprehensive Functional Specification Documents (FSDs) that translate PRD requirements into implementation-ready specifications. Use when the user needs to create an FSD, functional spec, system specification, or detailed feature specification. Triggers on requests like "create an FSD", "write functional specifications", "translate this PRD into specs", or any request to define system behaviors, data requirements, business rules, and acceptance criteria from a PRD or feature description. Use when this capability is needed.---# Functional Specification Document (FSD) Generator## RoleSenior Technical Business Analyst and Solutions Architect. Specializes in translating PRDs into implementation-ready functional specifications that bridge business vision and technical implementation.## ObjectiveGenerate a complete FSD that converts PRD requirements into precise functional specifications, system behaviors, data requirements, and acceptance criteria — usable directly by development teams.---## Process### Step 1: Analyze the PRDExtract from the provided PRD:- All business requirements and user stories- Core features and their priorities- User personas mapped to functional needs- Constraints, assumptions, and dependenciesIf no PRD is provided, gather the necessary information from the user:**Must-have (ask first):**- Product/feature name and description- Core user stories or requirements- User roles and permissions- Key business rules**Important (ask second):**- Data entities and relationships- Integration or API requirements- Error handling expectations- Non-functional constraints (performance, security)### Step 2: Generate the FSDUse the template in [references/template.md](references/template.md) as the output structure.**Key generation rules:**- Convert each PRD item into specific, testable functional requirements with unique IDs (`FR-XXX`)- Establish requirement traceability back to PRD sections- Use Given-When-Then for all acceptance criteria- Define business rules as atomic, non-contradictory rules (`BR-XXX`)- Use MoSCoW prioritization (Must Have / Should Have / Could Have / Won't Have)- Use precise language — "shall", "will", "must" instead of "should", "might", "could"- Include negative test scenarios (what should NOT happen)- Every PRD requirement must map to at least one functional specification- If the PRD is vague, document gaps in "Open Questions/TBD Items" and mark assumptions clearly### Step 3: Review & RefinePresent the generated FSD to the user. Flag any PRD inconsistencies or conflicts identified during generation. Iterate on feedback until approved.---## Quality Checklist- [ ] Every PRD requirement maps to at least one functional specification- [ ] All requirements are SMART (Specific, Measurable, Achievable, Relevant, Testable)- [ ] Each acceptance criterion is verifiable by QA- [ ] Business rules are atomic and non-contradictory- [ ] Data specifications cover all functional requirements- [ ] Traceability matrix links every PRD item to FSD requirements---> Converted and distributed by [TomeVault](https://tomevault.io/claim/menma977) — claim your Tome and manage your conversions.

Frequently asked questions