-
Notifications
You must be signed in to change notification settings - Fork 1
Workflow PRD to Production
The outer engineering loop. Takes a feature from "idea worth doing" to "live in production with stable metrics." Composes every artifact SpecRoute produces.
For the canonical version, see workflows/prd-to-production.md.
1. PRD draft → 2. PRD review → 3. PRD approved
│
▼
4. Spec triplet draft → 5. Spec review → 6. Spec approved
│
▼
7. Implementation tasks → 8. Implementation → 9. PR review
│
▼
10. Validation → 11. Rollout → 12. Production stable → 13. Closeout
Each stage has an entry condition, an output, and an exit gate.
Owner: product / sponsor (with prd-author agent).
Output: prds/active/<slug>.md with Status: Draft.
Exit: every section has at least placeholder content; open questions listed; success metrics concrete.
Owner: product owner + stakeholders (eng, ops, security, compliance). Exit: open questions resolved or assigned owner + date; stakeholders sign off.
Output: Status: Approved. The PRD is now the contract.
Owner: tech lead (with spec-author agent). Use prompts/shared/prd-to-spec-prompt.md.
Output: specs/<slug>/{requirements,design,tasks}.md with stable IDs, back-refs, populated coverage table.
Exit: every PRD acceptance criterion maps to ≥1 requirement; every requirement maps to ≥1 task; coverage table has no TODO rows.
Owner: tech lead, architect, security reviewer. Exit: open design questions resolved; design doesn't introduce risks the PRD doesn't mention.
Output: each of requirements.md, design.md, tasks.md has Status: Approved.
Owner: tech lead (with prompt-engineer agent if many tasks).
Output: agent-roster.md + (for multi-week initiatives) prompts/000_GLOBAL_MASTER.md and numbered task prompts under prompts/phase{N}_<name>/; an implementation-plan.md.
Exit: every task in tasks.md has a primary agent assigned; implementation plan has a defensible schedule.
Owner: each task's primary agent. Output: code, tests, observability, doc updates. Each task back-references requirement IDs in commits and PRs. Exit: each task's checkbox is checked; PR is open.
See Workflow Spec to Implementation for the inner loop.
Owner: code reviewer (human or code-reviewer agent).
Use: prompts/shared/code-review-prompt.md.
Exit: approval; tests pass; /audit clean; sanitization gate doesn't fire.
See Workflow Agent Review Loop.
Owner: QA / test engineer + template-quality-reviewer agent for cross-cutting checks.
Output: validation report. Every requirement has a passing test; every NFR is measured; performance budgets met.
Exit: validation report clean.
See Workflow Testing and Validation.
Owner: deployment / SRE. Output: production deployment per the PRD's rollout strategy (typically feature flag → 10% → 50% → 100% with monitoring at each stage). Exit: 100% traffic with stable error rates and latency for the duration specified in the PRD.
See Workflow Release Readiness.
Owner: deployment / SRE → product. Exit: every PRD acceptance criterion checked; success metrics within target.
Owner: PRD author.
Output: PRD Shipped + moved to prds/archive/; spec triplet Complete; lessons-learned doc; any deferred work surfaces as new PRDs.
For trivial work, some stages collapse:
-
Lightweight feature — Stages 4–6 use
feature-spec-template.mdinstead of the spec triplet. -
Refactor with no behavior change — skip the PRD; use
technical-spec-template.mdstarting at Stage 4. - One architectural decision — use the ADR template only.
Don't skip Stages 9 (review), 10 (validation), or 11 (rollout). Those are the gate.
| Stage | Primary role | Agent (if delegating) |
|---|---|---|
| 1 — PRD draft | Product owner | prd-author |
| 2 — PRD review | Stakeholders | (review prompt) |
| 4 — Spec triplet | Tech lead | spec-author |
| 7 — Tasks + prompts | Tech lead | prompt-engineer |
| 8 — Implementation | Each task's owner | (per task assignment) |
| 9 — PR review | Reviewer | code-reviewer |
| 10 — Validation | QA | template-quality-reviewer |
| 11 — Rollout | SRE | deployment-validator |
The canonical example walks this entire workflow for the user-search feature. See Worked Example.
- Workflow Spec to Implementation — Stages 7–9 in detail
- Workflow Agent Review Loop — Stage 9
- Workflow Testing and Validation — Stage 10
- Workflow Release Readiness — Stage 11
- Spec-Driven Development — the philosophy
Repository · Issues · Roadmap · Changelog · Security · License (Apache 2.0) — © Enovatr Labs
- Philosophy
- Spec-Driven Development
- Agentic Coding Model
- Automation Decision Framework
- Multi-Agent Orchestration
- Two-Tier Docs Pattern
- Multi-Vendor Context Files
- Documentation Structure
- Agent Memory
- Artifact Taxonomy
- PRDs
- Specs
- Agents
- Skills
- Commands
- Hooks
- Prompts
- Rules
- Frontmatter Contracts
- Sanitization