A documentation-driven development methodology that turns ideas into working software through a structured, repeatable pipeline.
SOW → User Journey → Use Cases → Business Rules → Test Cases → Solution Draft → Implementation
│ │ │ │ │ │ │
│ │ │ │ │ │ └─ Protocol 004
│ │ │ │ │ └─ Protocol 003
│ │ │ │ └─ Protocol 002
│ │ │ │
└─────────┴──────────────┴─────────────┴──────────────── Protocol 001 (stages 1-4)
Every feature follows this pipeline. No stage may be skipped. Each stage feeds the next.
Protocols define how to do each thing:
| # | Protocol | Governs |
|---|---|---|
| 001 | Documentation-Driven Development | The full pipeline — stages 1 through 7; Architectural Decision Records (ADRs); Stage 7 Pre-Flight Architectural-Pivot Checkpoint |
| 002 | Test-Driven Business Rules | Stage 5 — writing test cases from BRs; runtime behavior coverage check (E2E scenarios) |
| 003 | Solution Architecture | Stage 6 — designing the technical solution; cross-component service references |
| 004 | Red-Green-Refactor | Stage 7 — implementing with strict TDD |
| 005 | Cross-Project Integration | Multi-project boundaries — contracts between systems |
| 006 | Phased Multi-Component Delivery | Multi-component systems — master SOW, build order, vertical slices |
| 007 | Multi-Agent Pipeline Execution | Multi-agent decomposition — agent roles, orchestration, context handoff, workspace isolation, developer agent prohibitions, orchestrator prohibitions, agent behavior on undocumented architecture, Stage 7 pre-flight sequencing rule |
| 008 | Agent Communication Contract | Dispatch, completion, and gate feedback artifacts between Orchestrator and agents |
Prompts are executable instructions — give them to an AI assistant or follow them yourself:
| # | Prompt | Pipeline Stage |
|---|---|---|
| 001 | Create SOW | Stage 1 |
| 002 | Create User Journey | Stage 2 |
| 003 | Create Use Cases | Stage 3 |
| 004 | Create Business Rules | Stage 4 |
| 005 | Create BR Test Specifications | Stage 5 |
| 006 | Create Solution Draft | Stage 6 |
| 007 | Implement (Red-Green-Refactor) | Stage 7 |
| 008 | Define Agent Communication Contract | Protocol 008 |
| 009 | Clarify Agent Identity vs Instance | Protocol 007 |
| 010 | Orchestrate Pipeline | Orchestrator — triage, routing, propagation |
| 011 | Recurring Discrepancy Rule | Protocol 007 — recurring discrepancies in triage |
| 012 | Parallel Workspace Isolation | Protocol 007 — workspace isolation for parallel agents |
| 013 | Developer Agent Prohibitions | Protocol 007 — behavioral constraints for Stage 7 developer agents |
| 014 | Dispatch Deliverable Grouping | Protocol 008 — deliverable grouping for high-count dispatches |
| 015 | Orchestrator Prohibitions | Protocol 007 — orchestrator write-scope prohibitions |
| 016 | Retroactive Formalization | Protocol 006 — formalization debt tracking and resolution |
| 017 | Dispatch Context Reset | Protocol 008 — context reset field for fresh agent sessions |
| 018 | Self-Contained Dispatch | Protocol 008 — self-containment requirement for reset dispatches |
| 019 | Architectural Documentation | ADR requirement (Protocol 001) and agent behavior on undocumented architecture (Protocol 007) |
| 020 | Stage 6 Gate — Cross-Component Service References | Protocol 003 — mandatory enumeration of external services consumed across release/namespace boundaries |
| 021 | Stage 5 Gate — Runtime E2E Tests | Protocol 002 — runtime behavior coverage check (E2E scenarios required for runtime BRs) |
| 022 | Stage 7 Pre-Flight — Architectural-Pivot Checkpoint | Protocol 001 Stage 7 + Protocol 007 Rule 11 — 5-question pre-flight gate that blocks tactical dispatches expanding architectural surface area |
Reusable configuration files for projects adopting this methodology:
| Template | Purpose |
|---|---|
| Developer Agent CLAUDE.md | CLAUDE.md template for Stage 7 developer agents — enforces behavioral prohibitions (no writes to coordination directory, no branch merging, no self-issued gate verdicts) |
| Architectural Decision Record | Canonical ADR template — use for documenting architectural decisions before encoding them in code, charts, BRs, or solution docs |
| Test Specification with E2E Scenario | Test specification template including the canonical end-to-end scenario shape for BRs that specify runtime behavior (Protocol 002, Rule 8) |
- Start a new feature: Run Prompt 001 to create a Statement of Work
- Walk through the pipeline: Run each subsequent prompt in order (002 → 007)
- Gate each stage: Don't proceed until the current stage's gate conditions are met
- Adapt the templates: Replace
PROJwith your project identifier (e.g.,BR-MYAPP-001)
The methodology is language-agnostic and framework-agnostic. The examples use generic placeholders — adapt the test file extensions, build commands, and tooling to your stack.
- No code without documentation — every line traces back to a use case and business rule
- Tests are the specification — written before implementation, in a failing state
- One test at a time — strict Red-Green-Refactor discipline
- Cross-references are mandatory — use cases reference business rules and vice versa
- Prompts drive execution — reproducible, auditable stage transitions
MIT