CONCEPTS · LIFECYCLE

The lifecycle

Synthex models software delivery as a five-phase loop: Discover, Plan, Build, Ship, Learn. Each phase emits an artifact the next phase consumes, so requirements, decisions, and code stay linked end-to-end.

Lifecycle

Idea to production, traced end-to-end.

Every task maps to a requirement, every change maps to a task, every architectural decision is recorded. Five phases, one continuous loop.

  1. PHASE · 01

    Discover

    Brain-dump → conversation → PRD that captures the why.

  2. PHASE · 02

    Plan

    Milestones, phases, tasks. Peer-reviewed before a line of code.

  3. PHASE · 03

    Build

    Parallel worktrees, specialist agents, mandatory quality gates.

  4. PHASE · 04

    Ship

    Performance audited, observable, and operationally ready.

  5. PHASE · 05

    Learn

    DORA, retros, and follow-through loops back into discovery.

Why a phased loop

Most teams already do these things. They just do them implicitly, in side conversations and private notebooks. When the work fans out across people and AI agents, implicit context is the first thing to break.

The lifecycle exists to make that context inspectable: every plan task points back to a requirement, every commit points back to a task, every architectural decision lives in version control next to the code it shaped. Nothing needs to be reconstructed from memory.

Phase 1 — Discover

The goal of Discover is a Product Requirements Document (PRD) that captures why the work matters before anyone argues about how to build it.

The Product Manager agent leads a structured interview, prompting for the user, the problem, the success metrics, and the non-goals. The output lands at docs/reqs/main.md. Reviewer agents (PM, Tech Lead, Designer) then run a clarity loop on the PRD — flagging ambiguity, missing acceptance criteria, and untestable claims — until the document is sharp enough to plan against.

Run it with refine-requirements/synthex:refine-requirements.

Phase 2 — Plan

The Plan phase converts the PRD into a milestone-and-task implementation plan at docs/plans/main.md. The PM agent drafts. The Architect, Designer, and Tech Lead review in parallel and the PM iterates on their findings until severity-high issues are resolved.

Each task carries a typed acceptance criterion:

TagMeaning
[T]Testable — proven by an automated test that must pass before merge
[H]Human-validated — requires explicit approval before merge
[O]Observational — measurable only after deployment

The plan also records dependencies, parallelizable batches, and a per-task complexity estimate.

Run it with write-implementation-plan/synthex:write-implementation-plan.

Phase 3 — Build

Build is where the plan becomes code. next-priority/synthex:next-priority picks the next batch of unblocked, non-overlapping tasks (up to your concurrent_tasks limit), provisions a git worktree per task, and delegates each one to a Tech Lead instance that orchestrates the specialists it needs — coding, frontend, security, testing.

Two structural rules govern the phase:

  • Parallel work is isolated. Each task gets its own worktree branch. Concurrent tasks never share a working tree, so they cannot stomp on each other's files.
  • Quality gates are mandatory. Every change passes through code review and security review before merge. [T] criteria require linked, passing tests. [H] criteria require your explicit approval.

See Parallel execution for the worktree model in detail.

Phase 4 — Ship

Ship is the deployment-readiness gate. Performance, accessibility, observability, and operational concerns are audited before any code reaches production. Specialist agents — the performance engineer, the design-system reviewer, the SRE — run targeted audits driven by the relevant commands (performance-audit/synthex:performance-audit, design-system-audit/synthex:design-system-audit, reliability-review/synthex:reliability-review).

Findings flow back into the plan as new tasks if they cross the severity threshold. The plan is the system of record; the audit reports are inputs to it, not parallel sources of truth.

Phase 5 — Learn

Learn closes the loop. retrospective/synthex:retrospective facilitates a structured retro (start-stop-continue, 4Ls, or sailboat), captures DORA-style metrics where they're measurable, and surfaces follow-through items as new entries in the discovery backlog.

The retrospective output is committed to docs/retros/. The point isn't the document — it's that the next Discover cycle starts from a stated baseline rather than collective amnesia.

How the phases connect

Discover ──▶ PRD                     (docs/reqs/main.md)
   │
Plan     ──▶ Implementation plan     (docs/plans/main.md)
   │
Build    ──▶ Code + tests + ADRs     (worktrees → main)
   │
Ship     ──▶ Audit reports           (docs/runbooks/, plan updates)
   │
Learn    ──▶ Retrospective           (docs/retros/) ─┐
                                                     │
                                                     ▼
                                                 Discover

Every artifact references the artifact upstream of it. A code review can ask which task is this proving?; a task can ask which requirement is this serving?; a retro can ask which decision caused this outcome?. The loop is auditable in either direction.

Next