protocol · 5 steps

task.

task carries one unit of work from “understand the request” through to “merged, issue closed, archived.” The engine applies the right DAIC mode on each step and runs the git/issue plumbing automatically — your job is to discuss, write code, and provide verification evidence. Everything else is enforced structurally.

Steps

  1. 01Investigationread-only

    Read-only. Understand scope, align on an approach, compose the task file. No code is written here. This is also the re-planning anchor — any later step returns here when an assumption breaks.

    OpusAntigravityCodexyour call — answer to go on
  2. 02Implementationedit tools unlocked

    Full edit access. Write code to satisfy every success criterion — no new scope, no drive-by refactors. Stop-on-blocker rather than guess. Changes are not committed yet.

  3. 03Code-reviewspec gate

    The two-stage gate. Stage 1: spec-compliance against the success criteria. Stage 2: parallel code-quality review (Claude + any AI providers). Cannot advance without passing both.

    OpusAntigravityCodex
  4. 04Documentationdocs only

    Docs-only edits — source edits are hook-blocked. Update affected CLAUDE.md files, finalize the work log, refresh the wiki if enabled.

    writes back to the shared LLM wiki
  5. 05Completionsquash & push

    You verify, then the engine does all git/issue/archive work automatically: branch merge, push, MR/PR, issue close, archive.

What makes it distinctive

The two-stage code-review gate

Stage 1 (“does the diff match the promise?”) catches well-written code that drifted from spec — the spec-compliance-reviewer audits the diff against your Success Criteria and writes a SPEC_REVIEW: PASSED sentinel. Stage 2 (“is the diff correct/secure?”) dispatches the Claude code-review agent plus one Task per configured AI provider, in parallel. Both stages are post_funcs with stop-on-failure — un-bypassable by construction.

Commits happen only at completion

The LLM never commits prematurely. The engine creates the branch up front (an investigation post-func), but every commit, merge, push and MR/PR lives in the completion step’s engine-driven funcs, which branch on your issue-tracking provider (or present a 4-option menu when none is configured).

Evidence-gated advance

The advance summary out of code-review must carry literal verification evidence — a fenced output block, “N/N passed”, “exit 0” — or the escape hatch no-verification-applicable: <reason>. Prose like “looks good” is rejected.

branch feature/ · fix/ — set by task prefix