An expert, contract-ready documentation facilitator for agentic coding IDEs (Cursor, Claude Code, OpenCode, Antigravity, Windsurf, etc.) — protecting you from scope creep and shifting client requirements.
Most developers — especially solo devs and freelancers — skip documentation entirely. It feels like busywork. You just want to ship.
But here's the thing: big companies don't do it because they love paperwork. They do it because structured documents like Business Cases, FRDs, BRDs, and SRS are what keep everyone aligned before a single line of code is written. They prevent miscommunication, scope creep, and those painful "but I thought you meant..." conversations with clients.
For developers working alone or in small teams, this is even more critical — because you're not just the engineer. You're also the business analyst, the project manager, and sometimes the salesperson. Nobody told you what a BRD is or why it matters. You learned to code, not to produce contract-grade specifications.
That's exactly where Doc-Generator comes in.
Think of it as a document-driven development phase — something you do before the project starts, or when you need to make sense of one that already exists. You have a conversation with an AI that knows all the right questions to ask, and it handles the drafting, structure, and formatting for you.
And here's the part that's genuinely useful for freelancers: once generated, these documents can become part of your contract with the client. A solid FRD or SRS, signed off before work begins, is one of the best ways to protect yourself. It defines what you're building, what's out of scope, and what "done" actually means. That's not bureaucracy — that's how you avoid working for free on revision number eleven.
Spec-Driven Development doesn't slow you down. It stops you from building the wrong thing fast.
- Spec-Driven Development: Start your project with a rock-solid foundation.
- Zero Friction: The AI handles the heavy lifting of drafting, formatting, and structuring.
- Flexible & Optional: Use the full 9-step roadmap or just pick the documents you need.
- Reverse Documentation: Seamlessly works with existing codebases to generate "from-code" docs.
- Lightweight: It is just a set of simple skills, no need to install anything.
Since each document generator is a standalone skill, the repository is organized into a modular folder structure. Each folder contains its own SKILL.md file tailored for that specific document.
.
├── .cursorrules # IDE Bridge (Cursor)
├── .claudecode.md # IDE Bridge (Claude Code)
├── .windsurfrules # IDE Bridge (Windsurf)
├── .clinerules # IDE Bridge (Cline/Roo Code)
├── .agent/
│ └── config.json # Config for Antigravity/OpenCode
├── .github/
│ └── copilot-instructions.md # IDE Bridge (GitHub Copilot)
├── skills/
│ ├── doc-generator/ # Master Orchestrator (workflow logic)
│ │ └── SKILL.md
│ ├── generate-mrd/ # Step 0 (Optional)
│ │ └── SKILL.md
│ ├── generate-business-case/# Step 1
│ │ └── SKILL.md
│ ├── generate-brd/ # Step 2
│ │ └── SKILL.md
│ ├── generate-frd/ # Step 3
│ │ └── SKILL.md
│ ├── generate-srs/ # Step 4
│ │ └── SKILL.md
│ ├── generate-trd/ # Step 5
│ │ └── SKILL.md
│ ├── generate-hld/ # Step 6
│ │ └── SKILL.md
│ ├── generate-lld/ # Step 7
│ │ └── SKILL.md
│ └── generate-rtm/ # Step 8
│ └── SKILL.md
└── README.md # This guide
git clone https://github.com/your-repo/doc-generator.git
cd doc-generatorThe skills are pre-configured to work out of the box with virtually all agentic environments:
- Cursor: Instructions in
.cursorrules. - Claude Code: Instructions in
.claudecode.md. - OpenCode / Antigravity: Managed via
.agent/config.jsonand theskills/folder. - Windsurf: Instructions in
.windsurfrules. - Cline / Roo Code: Instructions in
.clinerules. - GitHub Copilot / VS Code: Instructions in
.github/copilot-instructions.md. - Pi (Perplexity) / General LLMs: Mention the
skills/doc-generator/SKILL.mdfile or paste its content to initialize the workflow.
When cloning or copying this repository, you only need the configuration file for your specific IDE. You can safely delete the others (e.g., if you use Cursor, you can keep .cursorrules and remove .clinerules, .windsurfrules, etc.).
Most modern agents are smart enough to adapt these skills automatically. If you are using an IDE not listed above, simply point your agent to the skills/ folder and say:
"I have a set of doc-generator skills in this folder. Please adapt them to work with my current environment and guide me through the 9-step process."
The agent will read the SKILL.md files and configure itself to follow the stipulated roles and structures.
Briefly tell your agent:
"I want to start the doc-generator workflow. Please guide me through the 9 steps."
Step 1 — Mode selection & bootstrap questions:
Step 2 — Document generation with interactive clarifying questions:
Do you already have a codebase but no documentation? The Doc-Generator can "reverse engineer" your project.
- Initialize: Tell your agent you want to document an existing project.
- Scan: The agent will scan your project structure and key files first.
- Bottom-Up Generation: The workflow effectively reverses. The agent will start by documenting the Actual Implementation (LLD, HLD, TRD) and then work upward to the Business Intent (SRS, FRD, BRD).
- Interactive Gaps: During the scan, the agent will ask 5-10 targeted questions to clarify the "why" behind your code choices.
Every document generator (BRD, SRS, etc.) is a standalone skill. You don't have to use the full 9-step workflow. You can download and use individual folders from the skills/ directory:
- Copy the specific folder (e.g.,
skills/generate-brd) into your project. - Direct your agent to the
SKILL.mdinside that folder. - Your agent should immediately adopt the role and structure for that specific document.
Do we need to adjust skill formats for every IDE? No.
This architecture ensures that the central logic only needs to be written once, but can be executed everywhere.
Note
Each SKILL.md lives in its own subfolder — this is the OpenCode standard skill format. While this structure is optimized to prevent friction for OpenCode and Antigravity users, it works perfectly for all other agentic IDEs via their respective bridge files.
- Professional Orchestration: A structured 5-phase lifecycle guided by specialized AI roles.
- Interactive Approval Gates: Mandatory analysis and user confirmation before every document.
- Traceability Loop: Requirements flow seamlessly from Business Case to LLD and are verified via an RTM.
- Standardized Outputs: Automated file numbering (
XX-name.md) and centralized storage indocs/project-documentation/. - Hybrid Support: Native support for both Greenfield (Forward) and Existing (Reverse) projects.
Generated documents follow a standardized numbering system in docs/project-documentation/:
00-mrd.md01-business-case.md02-brd.md- ... and so on.
graph TD
subgraph Phase0["Phase 0: Research"]
S0["Step 0: MRD (Optional)"]
end
subgraph Phase1["Phase 1: The Why"]
S1["Step 1: Business Case & Charter"] --> S2["Step 2: BRD"]
end
subgraph Phase2["Phase 2: The What"]
S2 --> S3["Step 3: FRD"]
S3 --> S4["Step 4: SRS"]
end
subgraph Phase3["Phase 3: The How"]
S4 --> S5["Step 5: TRD"]
S5 --> S6["Step 6: HLD"]
S6 --> S7["Step 7: LLD"]
end
subgraph Phase4["Phase 4: The Loop"]
S7 --> S8["Step 8: RTM"]
end
S0 -.-> S1
style Phase0 fill:#4a4a4a,stroke:#ccc,color:#fff
style Phase1 fill:#7b2d8e,stroke:#ccc,color:#fff
style Phase2 fill:#2d5f8e,stroke:#ccc,color:#fff
style Phase3 fill:#2d8e4f,stroke:#ccc,color:#fff
style Phase4 fill:#8e7b2d,stroke:#ccc,color:#fff
The workflow is divided into 5 distinct Phases (Research, The Why, The What, The How, and The Loop). Each step is handled by a specialized role.
- Role: Senior Product Marketing Manager.
- Goal: Justify product existence through market data and competitive analysis.
- Role: PMP-certified Senior Project Manager.
- Goal: Formal authorization and ROI justification.
- Role: Senior Business Analyst.
- Goal: Bridge gap between business needs and technical solutions.
- Role: Senior Lead Product Systems Analyst.
- Goal: Translate business needs into detailed, actionable functional specifications.
- Role: Technical Product Manager.
- Goal: Produce a formal technical document (ISO/IEC/IEEE 29148:2018).
- Role: Senior Software Architect & Technical Lead.
- Goal: Deep technical blueprint (Stack, Infra, Security).
- Role: Senior Solutions Architect.
- Goal: Macro-level view of the entire system architecture.
- Role: Lead Software Engineer & Senior Developer.
- Goal: Granular implementation blueprint (Classes, DB Schema, Pseudocode).
- Role: QA Manager & Compliance Lead.
- Goal: Ensure every business requirement is addressed in the technical implementation.
MIT