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.

#What are the five phases?

Synthex's lifecycle has five phases: Discover (turn intent into requirements), Plan (turn requirements into a peer-reviewed implementation plan), Build (execute plan tasks in parallel git worktrees), Ship (merge, validate, release), and Learn (run a retrospective and fold the learnings back into the plan). Each phase emits the artifact the next phase consumes, so requirements, decisions, and code stay linked end-to-end with no manual hand-offs.

#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 can lead 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 (by default the Product Manager, Tech Lead, and Lead Frontend Engineer) then run a clarity loop on the PRD — flagging ambiguity, missing acceptance criteria, and untestable claims — and the PRD is updated directly until it's sharp enough to plan against.

Run it with /synthex: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. A zero-token structural lint catches template problems first, then the Architect, Design System Agent, and Tech Lead review in parallel (optionally alongside external models — see Multi-model review) and the PM iterates on their findings until severity-high issues are resolved.

Each task carries a typed acceptance criterion:

The plan also records dependencies, parallelizable batches, and a per-task complexity grade (S/M/L).

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

#Phase 3 — Build

Build is where the plan becomes code. /synthex: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 (or, with cloud execution, a cloud agent per task), and delegates each one to a Tech Lead instance that orchestrates the specialists it needs — coding, frontend, security, testing. Pass --loop to keep it going until the plan is done — see Native looping.

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. The Tech Lead reviews every change before accepting it, and security review gates security-sensitive changes. [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 (/synthex:performance-audit/synthex:performance-audit, /synthex:design-system-audit/synthex:design-system-audit,

).

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. /synthex: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

• Parallel execution — how Build runs many tasks at once safely
• Configuration — tune review loops, concurrency, and reviewer rosters per project
• Getting started — install Synthex and run your first loop