Skip to main content

The 6-Stage ADLC Lifecycle, End-to-End

At a Glance​

The ADLC (Agent Development Lifecycle) product-development lifecycle has six stages: five ratified by ADR-020, plus Deprecate added by ADR-021. Each stage has a clear gate (the artifact that signals "ready for next stage"), an autonomy tier (who acts and who decides), and an owning command.

A HITL can learn all six stages and drive a feature end-to-end from one page using the copy-paste command card below. No need to assemble context from four scattered sources.

The Six Stages​

Each stage is a distinct phase in the product lifecycle — from problem validation through secure retirement.

Stage 1: Discover​

Purpose: Validate WHETHER a feature is worth building. Surface the problem, evidence, riskiest assumptions, and the north-star metric — without designing the solution.

Gate (signed artifact): discovery-brief.md signed by HITL (APPROVE / DEFER / KILL)

Autonomy tier: [A] (agent explores) + [HITL-gate] (HITL decides go/no-go)

Owning command: /adlc:discover <topic>

What it produces: A discovery brief that names the problem, cites evidence, lists the 3 riskiest assumptions, and sets the north-star metric. HITL signs APPROVE to authorize Stage 2. See canonical lifecycle reference: .adlc/.claude/skills/governance/lifecycle-ssot/SKILL.md (Section 1).

Stage 2: Design​

Purpose: Plan the solution. Design the API surface, architecture, and the thin-slice order of work — targeting Stage 1's riskiest assumptions first.

Gate (signed artifact): feature-spec.md + lld.md + tasks.md with zero open clarifications

Autonomy tier: [A] (agent designs) + [HITL-gate] (HITL confirms no gaps)

Owning command: /adlc:design <brief-path>

What it produces: A feature specification, low-level design document, and ordered task list. Each task is ready for build (no "figure out on the way"). HITL gate confirms design is complete before Stage 3 begins.

Stage 3: Build​

Purpose: Implement the code, write and execute tests, update docs. Ship tests-green PRs ready for deploy.

Gate (signed artifact): Tests green; PR ready for merge; docs updated (cross-cutting requirement)

Autonomy tier: [A] (code + tests) + [A-gated] (code review + test results before merge)

Owning command: /adlc <tasks-path>

What it produces: Implementation code with full test coverage, passing E2E, and updated product documentation. Tests are the definition of done.

Stage 4: Deploy​

Purpose: Promote environments, apply infrastructure, run visual verification. Move the tested feature into production.

Gate (signed artifact): Plan reviewed and approved; visual verification passes (the feature renders and works as specified)

Autonomy tier: [A-gated] (plan) → [HITL] (apply/release)

Owning command: /commerce:tf-plan (agent-prepares) → [HITL applies] or /cdk:deploy

What it produces: Infrastructure changes applied, environment promoted, visual verification passed. Only HITL executes the apply/release step. The stage is complete when the feature is live and verified.

Stage 5: Support & Scale​

Purpose: Monitor the feature in production, collect metrics (DORA), debug issues, scale as needed. Understand what happened and learn.

Gate (signed artifact): DORA collected; retro evidence; remediation prepared (if needed)

Autonomy tier: [A-readonly] (collect metrics + debug) + [HITL-decide] (approve remediation)

Owning command: /itsm:lifecycle (runbook-based ops), /aws:investigate (AWS-aware diagnostics), /ceremony:retro (post-sprint review)

What it produces: Operational metrics (DORA), incident reports, and retrospective evidence. HITL decides whether to remediate, scale, or defer improvements.

Stage 6: Deprecate​

Purpose: End-of-life. Confirm usage is below the floor, clear dependencies, archive data, preserve evidence, and retire the feature securely.

Gate (signed artifact): decommission-plan.md signed by HITL; usage < floor; dependencies cleared; data archived

Autonomy tier: [A-readonly] (collect usage data) + [HITL-decide] (approve plan) + [HITL] (execute destroy)

Owning command: /adlc:deprecate <plan>

What it produces: A decommission plan with usage analysis, dependency map, and data archival evidence. HITL approves and executes the final destruction.

Drive It Yourself — Quick-Start Command Card​

Copy-paste these commands in order to drive a feature end-to-end. Each command produces a gate artifact; HITL makes the decision before moving to the next stage.

StageCommand (copy-paste)ProducesGate
1. Discover/adlc:discover <topic>discovery-brief.md (problem, north-star, assumptions)HITL signs: APPROVE / DEFER / KILL
2. Design/adlc:design <brief-path>feature-spec.md + lld.md + tasks.mdHITL confirms: zero clarifications open
3. Build/adlc <tasks-path>Tests green, PR ready, docs updatedCode reviewer: tests + review gate before merge
4. Deploy/commerce:tf-plan → HITL /commerce:tf-applyEnv promoted, visual-verify passedHITL applies: must review plan first
5. Support & Scale/ceremony:retro · /aws:investigateDORA + retro evidence; remediation preparedHITL decides: scale / remediate / defer
6. Deprecate/adlc:deprecate <plan>decommission-plan.md signed; usage < floorHITL approves then destroys

Notes:

  • Each [HITL] gate requires human decision — the command produces evidence, HITL reviews it, then HITL executes the next step.
  • Build stage (/adlc <tasks-path>) is autonomous code + gated review (no HITL block). Other stages require explicit HITL approval before the next stage starts.
  • Commands live at: /.adlc/.claude/commands/adlc/ (discover, design, deprecate) + /.adlc/.claude/commands/commerce/, /.adlc/.claude/commands/ceremony/, /.adlc/.claude/commands/aws/ (deploy, support, investigate).

Worked Example: Order-to-Cash (Stage 1 → Stage 2, Real)​

A concrete example proves the lifecycle is real, not theory. The order-to-cash epic (B2B buyer pays for an accepted quote) walked Stages 1 and 2 in June 2026.

Stage 1: Discover​

Brief signed APPROVE: /adlc:discover order-to-cash produced discovery-brief.md, which states the problem:

A buyer can accept a quote and create an order, but cannot pay, see fulfillment, or receive an invoice. The merchant (operator) has no order-management surface. This is the single highest-leverage gap: quote→order already works; payment is the missing revenue leg. North-star metric: % of accepted-quote orders reaching PAID = 0% today.

Gate artifacts (on-disk evidence):

  • tmp/b2b-commerce/discover/order-to-cash-2026-06-11/discovery-brief.md — problem, 3 assumptions, north-star, success criteria
  • tmp/b2b-commerce/coordination-logs/product-owner-order-to-cash-2026-06-11.json — PO sign-off (APPROVE)

HITL Decision: APPROVED. Stage 2 authorized. Assumption #1 (native Medusa payment covers B2B order context) to be de-risked via thin vertical slice in Design.

Stage 2: Design (In Progress)​

Command: /adlc:design tmp/b2b-commerce/discover/order-to-cash-2026-06-11/discovery-brief.md

Gate artifacts to be produced:

  • feature-spec.md — API surface for buyer payment, order status, invoice retrieval, fulfillment tracking
  • lld.md — Stripe integration design, Medusa payment session flow, native module vs custom
  • tasks.md — Ordered task list: thin-slice Stripe payment first (de-risk assumption #1), then invoice, then admin-orders surface

HITL Decision (awaited): Confirms spec, lld, and tasks are complete with zero open clarifications. Then Stage 3 (Build) begins.

How the Engineering Inner-Loop Nests​

The constitution declares a 6-phase engineering loop: Plan → Build → Test → Deploy → Monitor → Operate. This loop is NOT a competing lifecycle model; it is the engineering inner loop nested inside Stage 3 (Build) + Stage 4 (Deploy) of the 6-stage product lifecycle.

6-stage product lifecycle (outer):
  Discover → Design → [ Build → Deploy ] → Support & Scale → Deprecate
                          │        │
                          └────────┴── engineering inner loop (per-feature mechanics):
                                        Plan → Build → Test → Deploy → Monitor → Operate
                                        with two optimization sub-loops:
                                          • Experimentation Loop (Build ↔ Test)
                                          • Runtime Optimization Loop (Deploy → Monitor → Operate)

What this means for you:

  • The outer 6 stages are product-development vocabulary (for HITL, CxOs, boards).
  • The inner 6-phase loop is engineering vocabulary (for agents, feature teams, per-task granularity).
  • Both are true and consistent. Use whichever language fits your audience.

For the complete nesting detail, see the canonical lifecycle reference: .adlc/.claude/skills/governance/lifecycle-ssot/SKILL.md (Section 3).

Provenance & Further Reading​

The 6-stage lifecycle is the result of a deliberate migration and standardization effort:

  • ADR-020: 7-Phase to 5-Stage Lifecycle Migration — Ratified 2026-05-02. Unified three competing lifecycle models into the 5-stage canonical aligned with Anthropic Claude Code and McKinsey Rewired.

  • ADR-021: Deprecate Stage (Additive Stage 6) — Ratified 2026-05-30. Added Deprecate as the sixth stage to close the lifecycle loop with secure retirement.

  • The Golden Path: SDLC Lifecycle — Extended guide on how the inner engineering loop integrates with the outer product lifecycle, with team roles and decision points.

  • Canonical SSOT: .adlc/.claude/skills/governance/lifecycle-ssot/SKILL.md — The single source of truth for all lifecycle stage definitions, tiers, gates, and commands. All other docs reference it; none restate the stage table independently.

Last updated: 2026-06-11 | Stage: Documentation (cross-cutting, part of Build DoD)