From PRD to Production: My spec-kit Workflow for Structured Development
A Reddit user asked me about my “recipe” for using GitHub’s spec-kit with an existing PRD (Product Requirements Document). Here’s my complete workflow that transforms chaotic development into a structured, predictable process.
The Initial Setup
The process starts with a simple initialization command. You have two options depending on your situation:
uvx - from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>Or if you’re working in an existing directory:
uvx - from git+https://github.com/github/spec-kit.git specify init - hereThis creates the initial folder structure with a crucial `memory` folder containing the `constitution.md` file.
The Constitution: Your Project’s DNA
This is essential: You need to check the `constitution.md` file first. Make sure your preferred rules for conducting development are documented in that file. Throw everything away that doesn’t fit your approach. You can delete the template-ish markup — in the end, it’s just a plain markdown file.
Here’s how mine starts:
# Constitution
## Core Principles
### I. The Rails-Way
Every feature is implemented following idiomatic Ruby On Rails approaches of Version 8 or future-8.1 (https://guides.rubyonrails.org/v8.0/index.html)
### II. Maximum Productivity and Simplicity
Our development process must be relentlessly focused on simplicity and efficiency. We prioritize solutions that reduce setup time and streamline the workflow, allowing a new developer to get a project up and running in minutes, not hours or days. We favor integrated, elegant solutions over complex, fragmented toolchains. We always follow the Rails-Way
### III. Test-Coverage (NON-NEGOTIABLE)
All features must be checked by Rails specs that adhere to their respective Feature Specification. The actual code follows the specification. No exceptions!
### IV. Integration Testing
Example: Use few integration tests and test the happy path user stories. Make sure they don't fail! Create test-dataset snapshots and make sure tests are repeatable.
### V. Make features SOLID
Apply the SOLID principles as long as they don't conflict with the above principles
### VI. Task-based Commit-Strategy (NON-NEGOTIABLE)
Every completed task (T001, T002, etc.) requires its own commit with a structured commit message.
**Commit-Template**: you are required to use `/templates/commit-message-template.md` as a template for ALL commit messages.
**Commit-Frequency**:
- After every completed task
- When moving on from one task category to the next (Infrastructure → API → WebSocket, etc.)
- When droping a plan with immediate reasoning
## Governance
- Constitution supersedes all other practices
- Amendments require documentation, approval, migration plan
All PRs/reviews must verify compliance with these principles; Complexity must be justified; Deviations require explicit documentation and approval.Setting Up the Constitution Update Process
You can ask Claude Code to adapt the `constitution_update_checklist.md` in accordance with the constitution. Check it afterwards!
If you want to save some tokens along the way, make sure to define a research-agent that creates summarized reports for the feature, plan and task-generation later.
Integrating Your PRD
Now is the time to put your PRD into the folder. I just place it in the project root as `PRD.md` and then ask Claude Code to read the file (by pointing it to it with the @ sign).
In the same sentence, I also tell it to read the spec-template and the specify command files and to create a comprehensive specification of its identifiable features. The prompt ends with ”What questions do you have?”
With this, the process to go through the PRD and make it sound and complete is started and you can watch in awe.
Organizing Your Specifications
Make sure that afterwards you have a sub-directory for every spec below the “specs” directory. Tell Claude to make it so, if the specs are all in the same directory.
Creating the Foundational Feature 000
This is the time where I do my own thing and tell Claude to create a “foundational feature 000” to provide the technical base for all the other features (which are purely business specifications at this point).
The prompt I use:
Please read constitution.md and the specs (001–006, or whatever)
and create a foundational feature 000 to set up the actual development
environment using <STACK> with <DATABASE>…So it will create Feature 000 with everything it thinks is required and a dependency of the following features. Pure magic, again!
Fine tune, ask questions. Let Claude ask questions. Do more research. And when you have everything, commit & push.
Plan Generation
Now you can ask Claude to create a plan (reading the plan-template and the plan command) for Feature 000. After that with all the research and questions etc. (and please: Always tell Claude to ask questions, otherwise it will assume “whatever” later and you lose control.).
When the plan is finished and you approved (after reading it from top to bottom! Remember: You are in control!!) you tell it to create read the task-template and the task command and to start creating all the tasks for feature 000.
Again, ask questions, read the tasks, tell it to ask questions. And when you’re done: Commit & push.
Development Execution
Then you tell it to start work on Feature 000 in its feature-branch and enjoy the show.
Peanuts!
The Key Points That Make This Work
1. Constitution First: Everything flows from your documented principles
2. Question-Driven Process: Always tell Claude to ask questions at each step
3. You Stay in Control: Review everything before moving to the next phase
4. Structured Commits: Every task gets its own commit following your template
5. Research Integration: Let Claude research and ask questions to fill gaps
Why This Approach Works
This workflow transforms spec-kit from a simple tool into a comprehensive development framework. By starting with your PRD and constitution, you ensure that every generated line of code aligns with your project’s vision and technical standards.
The magic happens when Claude has the full context of your requirements, principles, and structured templates. Instead of generating random code, it creates implementations that fit seamlessly into your defined architecture.
Most importantly, this process keeps you in the driver’s seat while leveraging AI’s capability to handle the implementation details. You define the “what” and “why” — Claude handles the “how” within your established boundaries.
Try this workflow with your next project. The combination of structured specifications, clear principles, and systematic execution will transform how you work with AI coding assistants.
Thank’s for reading!
You can find Spec Kit here: https://github.com/github/spec-kit
