Release-Driven Development (RDD) is a methodology where the deployable behavior change — not the commit, not the PR — is the unit of work. RDD answers the question: "How do we deliver value reliably?"
RDD is the execution layer of the framework. It pairs with VDD (Vision-Driven Development), which handles strategy. Together, they form a complete AI-autonomous development pipeline.
- The release is the unit of work. Commits and PRs are means, not ends.
- Review behavior, not code. The review target is the change in observable behavior, not the code diff.
- TDD supports the release. Test-Driven Development is the implementation technique within each release cycle.
- Every release has explicit scope and risk. No implicit assumptions about what changed or what might break.
| Phase | Responsibility |
|---|---|
| Requirements | Define what to achieve (goals, user stories, constraints) |
| Design dialogue | Participate in shaping the implementation approach |
| QA | Final verification of value and quality |
| Phase | Responsibility |
|---|---|
| Implementation | Write code, following TDD |
| Testing | Create and maintain automated tests |
| Self-evaluation | Assess own work before review |
| Review | Conduct and coordinate multi-perspective reviews |
The human states the essential purpose:
- User stories or goals
- Constraints and boundaries
- What success looks like
Implementation details are not included at this stage.
Based on requirements, the human and AI discuss the implementation approach:
- Architecture decisions
- Release splitting (if the work should be divided)
- Tradeoffs and alternatives
Output: Release specification (stored at a configurable path, e.g., {{RELEASE_SPECS_DIR}}/{release-name}.md)
When the work is split into multiple releases, a release tree is produced to visualize the structure (see Release Tree Notation below).
The AI works in an isolated worktree on a release/* branch:
- Create worktree and release branch
- Commit the release specification
- Implement using TDD (test-first, strictly enforced)
- Stay within the scope defined by the release specification
- Run project checks (type checking, linting, tests)
- Execute self-evaluation (release readiness check)
- Run independent AI review (separate context, different perspective)
- Optionally run external AI review (different model, different blind spots)
- Fix any issues found, re-run checks
- Create PR with review results, reports, and development insights
- PR targets the integration branch (
develop) - An independent reviewer (human or AI approver) reviews and approves the PR
- The implementing agent confirms approval, then merges
- Human performs exploratory QA on the integration environment
- Human triggers promotion from integration to production
The goal for Phase 4 is: "Complete the merge to the integration branch." Rather than prescribing step-by-step procedures, the framework declares the goal and verifies completion conditions mechanically via Stop hooks (L4).
Example completion conditions verified by the exit gate:
- Release specification is committed
- Review has been executed (output of Phase 3)
- PR is merged into the integration branch
The agent chooses its own means. Whether it uses a skill, runs commands manually, or finds another path — as long as the completion conditions are met, the gate passes. See Philosophy for the "Goal + Exit Gate" principle.
Every release must produce:
| Artifact | Description |
|---|---|
| Release specification | What this release does, what it does not do, and what risks exist |
| Expected behavior | How the system should behave after the release |
| Out-of-scope declaration | What is explicitly not part of this release |
| Risk disclosure | Known risks and mitigation strategies |
- 1 release = 1 independently deployable change
- Must be rollback-capable
- Must not have unnecessary dependencies on other releases
- If a release includes database migrations, no other concurrent release should include migrations (to avoid schema conflicts)
Every release/* branch merge is an RDD release. This includes releases with no version tag.
| Classification | Target | Version Tag | Changelog | Docs Update |
|---|---|---|---|---|
| developer-only | Refactoring, CI, docs, internal improvements | None | None | Not required |
| user-facing (bugfix) | User-visible bug fixes | patch | Created | Not required |
| user-facing (feature) | New features | minor | Created | Required |
| user-facing (breaking) | Breaking changes / major milestones | major | Created | Required |
- Does it include user-visible behavior changes? No → developer-only (no tag)
- Bug fix or new feature? Bug fix → patch, Feature → minor
- Does documentation need updating? Required for minor+ user-facing releases
- Batching: Multiple RDD releases can be grouped into a single semantic version when they form a meaningful unit
When requirements are split into multiple releases during Phase 1 (design dialogue), the structure is visualized using a text-based release tree.
- Visualize "how many releases exist and what their ordering is" at any point during the dialogue
- Enable agreement on splitting, merging, and reordering releases before specifications are written
- Ensure structural consensus before committing to implementation
[R1] release/<name>
| <one-line summary>
|
+---> [R2] release/<name>
| <one-line summary>
|
+---> [R3] release/<name>
<one-line summary>
|
+---> [R3a] release/<name>
| <one-line summary>
|
+---> [R3b] release/<name>
<one-line summary>
- Numbers are temporal: R1 is released before R2, R2 before R3
- Suffixes indicate branching: R3 splits into R3a, R3b (can execute in parallel)
- Arrows indicate dependencies: The target of
+-->is the dependent release - Sequential: Parent to single child in a line (R1 → R2 → R3)
- Parallel: Same parent to multiple children (R1 → R2 and R1 → R3)
[R1] release/data-schema
| DB: Add new table
|
+---> [R2] release/data-ui
UI: Selection and filtering
|
+---> [R3] release/data-integration
Integrate with core feature
[R1] release/data-schema
| DB: Add new table
|
+---> [R2] release/data-ui
| UI: Selection and filtering
|
+---> [R3] release/data-api
API: CRUD endpoints
- AI outputs the release tree during design dialogue; human agrees on the structure
- Each release in the tree gets its own release specification
- PR descriptions include the release tree (optionally converted to a diagram)
TDD is mandatory within every RDD release cycle. Implementation code must not be written before tests.
- Write a failing test that describes the expected behavior
- Confirm it fails (proves the behavior does not yet exist)
- Write the minimum implementation to make the test pass
- Refactor as needed while keeping tests green
- Write a test that reproduces the bug
- Confirm the test fails (proves the bug exists)
- Fix the bug so the test passes
- Always reference the release specification; do not change code outside its scope
- If the specification is ambiguous, ask the human. For everything else, proceed autonomously
- Include development insights in the PR description (potential issues discovered, unexpected behaviors, technical constraints, design rationale)
- After implementation, run the full review kata: checks → self-evaluation → independent review → fix → commit
During implementation, the AI may discover:
- Latent issues or risks in existing code
- Behaviors that differ from expectations
- Technical constraints that affect future work
- Performance or security observations
- Rationale for design choices made
These insights are recorded in the PR description under a dedicated section, making implicit knowledge explicit for reviewers and future developers.
RDD is the execution engine. VDD is the upstream input layer.
VDD defines direction and decisions. RDD receives them, translates them into release specifications, and executes the full cycle from implementation through review to merge.
- VDD Specification — Vision-Driven Development
- Branch Strategy — 3-layer branch structure
- QA Layers — 3-layer quality assurance model
- Enforcement Levels — How rules are technically enforced
- Cloud Execution — Headless VPS execution