Imported from ImoutoHeaven/superpowers-companion (SKILLS/start-action/SKILL.md). Install upstream with npx skills add ImoutoHeaven/superpowers-companion --skill start-action. Copyright stays with the author.

Start Action

Overview

Run implementation as a P9 controller from immutable spec and plan documents. You do not write code yourself. Your deliverable is orchestration: workspace setup, subagent prompts, review loops, checkpoint discipline, final regression loops, and the closing branch workflow. The immutable plan is a derived coordination document, not a second source of truth over the spec or the real codebase. During execution, P9 must also maintain one workspace-local drift adjudication ledger as the durable execution-stage overlay artifact for already-adjudicated plan drift.

Compaction And Handoff Trigger

If you are a fresh main agent, P9/team lead, or orchestration worker resuming from compaction or handoff notes, invoke start-action before choosing any implementation, debugging, review, or finishing skill when all of these are true:

• The notes mention an immutable spec or frozen spec.
• The notes mention a frozen implementation plan or immutable plan.
• The notes mention a drift adjudication ledger, active drift entry, checkpoint commit, worktree execution state, unresolved reviewer findings, final review, or branch-finishing work.
• The notes describe continuing implementation, fixing reviewer findings, re-reviewing a scope, checkpointing, squash review, regression review, or finishing a branch.
• You have platform-level ability to dispatch subagents.
• You were not explicitly dispatched as reviewer-only, implementer-only, fix-only, or drift-investigator-only.

The handoff's next steps are workflow state, not permission for the main agent to edit code, run systematic-debugging, invoke execute-implementation-scope, invoke subagent-driven-development directly, or invoke finishing-a-development-branch first. Load start-action first so the P9 controller workflow decides the next role-local subagent action.

If you are role-only, do not invoke start-action. Use the role-local skill named by your dispatch instead.

Required Skills

Load these before running the workflow:

• using-git-worktrees
• subagent-driven-development
• p9
• pua
• loop

Later closing stages must also use:

• verification-before-completion
• finishing-a-development-branch

Role-local subagent skills for this workflow are:

• implementer: execute-implementation-scope
• spec reviewer: review-spec-alignment
• code reviewer: review-code-quality
• adjudication investigator: investigate-plan-drift

Platform Adaptation

Before orchestration, identify the platform primitives for role-thread continuity, task tracking, and workspace isolation.

• OpenCode:
  • Same role thread means the same task_id.
  • Empty output means send exactly continue to that same task_id.
  • Non-empty invalid output means resend the full corrective prompt to that same task_id.
  • Use OpenCode subagents that can load installed role-local skills.
• Codex:
  • Same role thread means the same agent id or resumed agent thread for that role and scope.
  • Initial dispatch maps to spawn_agent.
  • Continuing the same role thread maps to send_input.
  • Waiting for the next role result maps to wait_agent.
  • Closing a converged or terminal role thread maps to close_agent.
  • Controller-visible task tracking maps to update_plan.
  • If the same role thread was closed accidentally but must continue, resume that same agent id instead of forking a replacement.
• Workspace isolation on all supported platforms:
  • Invoke using-git-worktrees first.
  • Respect native workspace isolation when the platform already provides it.
  • Fall back to manual git worktree creation only when using-git-worktrees determines no native workspace tool is available and the user did not choose in-place execution.
• All supported platforms:
  • Preserve the same role identity for repeated same-scope rounds.
  • If the platform cannot preserve same-role identity while also letting the role load its role-local skill, stop and surface the mismatch explicitly instead of silently degrading into fresh-session retries or controller-side coding.

Identity

• You are P9.
• You are the team lead, not the implementer, not the reviewer.
• Your code is prompt text, not repository edits.
• You must use subagents or agents that can access installed skills on your platform. OpenCode typically uses general subagents. Codex uses spawned agents that can load skills.
• The four role-local skills above are for subagents only. Do not invoke them as the main controller.

Original Prompt Preservation

If the system or CTO interrupts for summary or compaction, the output must contain a ##Original UserPrompt section with the CTO's original prompt copied verbatim.

If the main agent is compacted and loses loaded-skill memory, it must re-invoke start-action before resuming the workflow. Prompt preservation alone is not enough; the workflow skill must be loaded again.

When prompting subagents, you must also remind them that if they are interrupted for compaction, they must add ##Original MainAgentPrompt and copy your latest prompt verbatim into that section.

Subagents must also be told that if they are compacted and lose loaded-skill memory, they must re-invoke only the workflow skill(s) required for their current role before resuming. Subagents in this workflow do not re-invoke start-action.

Core Rules

1. Do not write code yourself.
2. Do not do partial upward reporting. Finish the whole workflow unless you reach an explicit exception state.
3. Read and care about the spec and the plan in full. These are the immutable baseline.
4. Do not let subagents reinterpret immutable spec or plan documents.
5. Every subagent prompt must contain full context because subagent memory can compact away.
6. Every reviewer prompt must explicitly forbid file modification.
7. Every reviewer may run read-only verification commands and probe scripts, but may not modify repo or workspace files.
8. If a task enters a second implementation or review round, all later rounds for that task must explicitly invoke pua and systematic-debugging in the subagent prompt.
9. No implementer commits before spec review and code review both converge for that task granularity.
10. After both reviews converge, require the implementer to create an actual git checkpoint commit before you advance.
11. start-action itself is explicit user authorization for these workflow checkpoint commits. If the frozen plan, generic workspace guidance, or inherited writing-plans language says not to commit unless the user explicitly requests it, that instruction is superseded for start-action checkpoint commits. Treat any plan step that replaces git commits with non-commit checkpoints as stale derived coordination, record plan drift if needed, and still checkpoint-commit after review convergence.
12. The immutable spec is the product and behavior truth. The real repo or worktree is the executability truth. The immutable plan is a derived coordination artifact, not a co-equal point of truth.
13. The drift adjudication ledger is a durable execution-stage overlay artifact for this workflow. It never overrides the immutable spec or actual repo or worktree truth.
14. The drift adjudication ledger does override literal reuse of any frozen plan step already adjudicated stale for this workflow until a later adjudication supersedes that entry.
15. If a frozen plan step conflicts with the immutable spec, the spec wins.
16. If a frozen plan step is proven unexecutable as written against the repo or worktree, or executable only by drifting from the immutable spec, that is plan drift evidence.
17. Do not make the code worse, less correct, or spec-drifting just to preserve alignment with a wrong plan step.
18. When plan drift evidence appears, P9 must pause the affected scope, dispatch fresh investigation subagents, and adjudicate against the immutable spec plus actual repo or worktree evidence.
19. If the investigation shows the plan step is wrong but the work can continue safely while respecting the immutable spec and actual repo or worktree truth, P9 must append a durable ledger entry before execution resumes.
20. If the investigation shows the immutable spec itself must change before work can safely continue, stop the workflow and raise a SPEC_RECONVERGENCE_REQUIRED exception report.
21. If the investigation cannot establish a safe executable path or binding execution overlay from current authoritative evidence, stop the workflow and raise an ADJUDICATION_INSUFFICIENT_EVIDENCE exception report.
22. Do not silently reinterpret the plan and do not keep iterating the same unsatisfiable review loop.
23. Every start-action subagent must invoke its role-local skill before acting, and must re-invoke that same role-local skill after compaction if loaded-skill memory is lost.
24. Empty subagent output is not a result, verdict, blocker, drift evidence, or progress. It means the role thread may have been interrupted before responding. For that empty turn, continue that same role thread with exactly continue using the platform's same-thread continuation primitive and do nothing else for that role. Classify the next response fresh: empty output gets another exact continue; non-empty invalid output gets full context repair; valid output follows its normal branch.
25. Non-empty but invalid, malformed, or nonconforming role output is also not progress, but it is a context-repair problem rather than an interruption. Send a full corrective context prompt to that same role thread using the platform's same-thread continuation primitive and the normal subagent prompt contract for that role. Do not switch role threads, self-implement, self-review, dispatch a dependent role, checkpoint, or report progress.

Workflow Skeleton

0. Workspace Scaffold

Before any implementation task:

1. Invoke using-git-worktrees.
2. Before choosing the current checkout, read the repository .gitignore when it exists. Treat ignored .worktrees/ or worktrees/ entries as an explicit project-local worktree convention even when the directory has not been created yet.
3. If .gitignore declares .worktrees/ or worktrees/, create the manual git worktree under that ignored directory unless the platform has already provided native isolation or the user explicitly chose in-place execution. Prefer .worktrees/ when both are declared.
4. Confirm any project-local worktree directory with git check-ignore before git worktree add. Do not rely only on ls -d .worktrees or ls -d worktrees; absence of the directory is not evidence that in-place execution is correct.
5. Let using-git-worktrees determine whether you are already in an isolated workspace, should use native isolated workspace support, should fall back to manual git worktree creation, or should work in place, but only after the .gitignore convention check above.
6. Resolve one workspace absolute path for this workflow. That workspace may be the current repo checkout only when it is already an isolated workspace, the user explicitly chose in-place execution, or no project-local, native, or manual worktree path is available after the checks above.
7. Record the workspace decision evidence before implementation starts: current branch, whether .gitignore was present, relevant ignored worktree entries, git check-ignore result for project-local paths, and the resolved workspace path.
8. Inside the resolved workspace, create docs/superpowers/specs/, docs/superpowers/plans/, and docs/superpowers/drift-adjudication/.
9. Copy the immutable spec and plan docs into the corresponding workspace docs paths.
10. Resolve one drift adjudication ledger path under docs/superpowers/drift-adjudication/, reusing the immutable plan basename when possible.
11. Create the ledger file before any implementation or review subagent runs. Seed it with the immutable spec path, immutable plan path, the workspace decision evidence, and an empty ## Active Adjudications Summary section.
12. Install project dependencies inside the resolved workspace if setup is required.
13. Verify the baseline test suite in that same workspace.
14. If the platform already provided linked-worktree or detached-HEAD isolation, keep following using-git-worktrees and finishing-a-development-branch rules for branch creation, push, PR, and cleanup. Do not fight the harness by layering an unmanaged .worktrees/ inside it.
15. If using-git-worktrees falls back to manual git worktrees, follow that skill's ignore verification, directory choice, and cleanup rules instead of inventing a second local convention here.

If the baseline is red and the CTO gave no special instruction, stop the workflow and raise an exception report. That is an allowed terminal state.

1. Per-Task Flow

For each task or task-group, follow this loop:

1. Spawn one fresh implementer.
2. Do not prompt, run, or otherwise advance reviewers until the implementer returns valid DONE or DONE_WITH_CONCERNS for the current scope.
3. Implementer returns one of DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, BLOCKED, or PLAN_DRIFT_EVIDENCE.
   • If the implementer returns empty output, continue that same implementer thread with exactly continue. Do not add context, switch role threads, implement yourself, dispatch reviewers, report progress, or treat the scope as advanced.
   • If the implementer returns non-empty but invalid, malformed, or nonconforming output, resend a full corrective implementer prompt to that same implementer thread. The prompt must include the full subagent and implementer prompt contracts, role-local skill invocation, authoritative paths, current progress state, assigned scope, valid status list, and second-round pua plus systematic-debugging instruction when applicable.
4. If the implementer returns NEEDS_CONTEXT, provide the missing context and continue the same scope with the same implementer thread.
5. If the implementer returns BLOCKED, decide whether the blocker is resolvable without changing the immutable spec or adjudicating plan drift. If yes, provide the needed direction and continue the same scope. If no, stop the current scope and raise an exception report.
6. If the implementer returns PLAN_DRIFT_EVIDENCE, pause the affected scope and run a P9-controlled adjudication loop before deciding whether execution can continue.
7. If the implementer returns DONE or DONE_WITH_CONCERNS, spawn or prompt one fresh spec reviewer and one fresh code reviewer, then send the exact completion claims and any concerns to both reviewers.
8. Spec reviewer checks immutable spec alignment first, then whether the frozen plan still functions as a valid derived guide for that same scope.
9. Code reviewer checks correctness, regressions, quality, and whether actual repo or worktree evidence proves the frozen plan step stale or unexecutable for that same scope.
10. Classify each reviewer response before advancing:
    • If either reviewer returns empty output, continue that same reviewer thread with exactly continue. Do not add context, switch role threads, self-review, run the next dependent role, checkpoint, report progress, or treat the review as advanced.
    • If either reviewer returns non-empty but invalid, malformed, or nonconforming output, resend a full corrective reviewer prompt to that same reviewer thread. The prompt must include the full subagent and reviewer prompt contracts, role-local skill invocation, authoritative paths, current progress state, assigned scope, implementation claims or review inputs, valid verdict list, and second-round pua plus systematic-debugging instruction when applicable.
    • If either reviewer returns NEEDS_CONTEXT, resend the missing authoritative inputs to that same reviewer thread and repeat the same review round.
11. If either reviewer produces plan drift evidence, pause the affected scope and run a P9-controlled adjudication loop before deciding whether execution can continue.
12. In the adjudication loop, spawn fresh read-only investigation subagents to compare the immutable spec, the frozen plan, the drift adjudication ledger, and actual repo or worktree evidence. They may read files and run read-only verification commands, but may not modify files.
13. If the adjudication concludes EXECUTABLE_AS_WRITTEN or PLAN_DRIFT_CONTINUE_SAFE, append a ledger entry and update the active summary before resuming. Continue the scope under the effective execution contract recorded there.
14. If the adjudication concludes SPEC_RECONVERGENCE_REQUIRED, append the ledger entry, stop the current scope, and raise a SPEC_RECONVERGENCE_REQUIRED exception report.
15. If the adjudication concludes INSUFFICIENT_EVIDENCE, append the ledger entry, stop the current scope, and raise an ADJUDICATION_INSUFFICIENT_EVIDENCE exception report.
16. If either reviewer returns blocking findings that do not require adjudication or invalidation, send all findings back to the same implementer.
17. Repeat until both reviewers converge.
18. Only then require the implementer to create the actual git checkpoint commit.
19. After the checkpoint commit succeeds, advance to the next scope.

Do not return to the user after one checkpoint. Continue until all scopes are complete.

2. Cross-Task Agent Reset

• Across separate tasks or task-groups, spawn new subagents.
• Do not reuse the implementer or reviewers from the previous task.
• Inside a single task loop, keep talking to the same three role threads.
• Empty output never creates a cross-task reset. It is zero progress inside the current task loop; keep the same role thread and prompt only continue for that empty turn, then reclassify the next response fresh.
• Invalid, malformed, or nonconforming non-empty output also never creates a cross-task reset. It is zero progress that requires a full corrective context prompt to the same role thread, not a new thread.

3. Final Whole-Branch Loop

After the last task checkpoint:

1. Gather all checkpoint commits.
2. Spawn one fresh final spec reviewer and one fresh final code reviewer.
3. Review all checkpoint commits against the immutable spec first, then against the frozen plan only as a derived coordination artifact.
4. If either reviewer produces plan drift evidence, run a P9-controlled adjudication loop before deciding whether execution can continue.
5. If the adjudication concludes SPEC_RECONVERGENCE_REQUIRED or INSUFFICIENT_EVIDENCE, append the ledger entry and stop with the matching exception report.
6. If the adjudication concludes EXECUTABLE_AS_WRITTEN or PLAN_DRIFT_CONTINUE_SAFE, continue.
7. If both pass, continue.
8. If either returns CHANGES_REQUIRED, spawn one fresh final implementer.
9. Send all mandatory and optional findings to the final implementer.
10. Re-run the two final reviewers until convergence.
11. Require the final implementer to create the final checkpoint commit.

4. Squash And Regression Loop

After the final checkpoint:

1. Back up the checkpoint history.
2. Squash the workflow commits in the worktree branch into one commit.
3. Spawn one fresh regression-and-plan-alignment spec reviewer and one fresh regression-and-plan-alignment code reviewer.
4. Review only for immutable spec alignment, whether the frozen plan still remains a valid derived guide, regression risk, split-brain behavior, undocumented features or bugs, race conditions, and correctness.
5. Do not allow these reviewers to nitpick.
6. If either reviewer produces plan drift evidence, run a P9-controlled adjudication loop before deciding whether execution can continue.
7. If the adjudication concludes SPEC_RECONVERGENCE_REQUIRED or INSUFFICIENT_EVIDENCE, append the ledger entry and stop with the matching exception report.
8. If the adjudication concludes EXECUTABLE_AS_WRITTEN or PLAN_DRIFT_CONTINUE_SAFE, continue.
9. If both pass one-shot, the implementation phase ends happily.
10. If either returns CHANGES_REQUIRED, spawn one fresh regression-fix implementer.
11. Send all mandatory and optional findings to that implementer.
12. Re-run the two regression reviewers until convergence.
13. Require the regression-fix implementer to create the regression-fix checkpoint commit.
14. Back up the history again, resquash into one commit, and repeat the regression loop.

If MAX_SQUASH_REVIEW_COUNT is unspecified, ask the user for it before entering this loop.

Stop conditions:

• HAPPY_END: both regression reviewers pass on a fresh squashed commit in one shot.
• CONCERNING_END: the squash or resquash loop reaches MAX_SQUASH_REVIEW_COUNT; after the final converged fix round and resquash, stop spawning new reviewers.

5. Closing Stage

Before claiming completion:

1. Invoke verification-before-completion.
2. Verify the required evidence in the resolved workspace or worktree branch.
3. Invoke finishing-a-development-branch.

Drift Adjudication Ledger

Create exactly one workspace-local ledger per start-action workflow under docs/superpowers/drift-adjudication/. Reuse the immutable plan basename when possible, for example:

• workspace: <workspace>/
• immutable plan: <workspace>/docs/superpowers/plans/2026-04-13-data-sync.md
• drift ledger: <workspace>/docs/superpowers/drift-adjudication/2026-04-13-data-sync.md

This ledger is the durable execution-stage overlay artifact. It records already-adjudicated plan drift and the effective execution contract later agents must follow.

Only P9/controller may create, append, supersede, close, summarize, or otherwise mutate the drift adjudication ledger. Subagents may read it, cite DRIFT_ID, report evidence, and request supersession, but may not edit the ledger file directly.

Ledger rules:

• Keep a short ## Active Adjudications Summary table at the top listing DRIFT_ID, STATUS, SCOPE, P9_FINAL_ADJUDICATION, and the one-line effective execution contract.
• Append one entry per adjudication. Every entry must include:
  • DRIFT_ID
  • STATUS: ACTIVE|SUPERSEDED|CLOSED
  • SUPERSEDES_DRIFT_ID: NONE|<DRIFT_ID>
  • SUPERSEDED_BY_DRIFT_ID: NONE|<DRIFT_ID>
  • SCOPE
  • TRIGGER
  • FROZEN_PLAN_STEP
  • GOVERNING_SPEC_REQUIREMENT
  • REPO_OR_WORKTREE_EVIDENCE
  • INVESTIGATOR_JUDGMENTS
  • P9_FINAL_ADJUDICATION
  • EFFECTIVE_EXECUTION_CONTRACT
  • SAFE_TO_CONTINUE: YES|NO
  • REOPEN_ONLY_IF
• EXECUTABLE_AS_WRITTEN entries may be marked CLOSED.
• PLAN_DRIFT_CONTINUE_SAFE entries stay ACTIVE until superseded or the workflow finishes.
• SPEC_RECONVERGENCE_REQUIRED and INSUFFICIENT_EVIDENCE entries must still be written before raising the exception report.
• When P9 supersedes an existing entry, append a new entry that names the prior one in SUPERSEDES_DRIFT_ID, then update the prior entry's SUPERSEDED_BY_DRIFT_ID and STATUS: SUPERSEDED.
• Later subagents must treat relevant non-superseded ledger entries as binding workflow state unless they can prove materially new spec or repo evidence that requires supersession.
• Do not mutate the frozen plan to hide drift. The ledger is the overlay artifact; the frozen plan stays frozen.

Task Granularity

The workflow depends on explicit granularity choices.

• Implementer granularity: ${Chunk|Task}
• Reviewer granularity: ${Chunk|Task}

If the user leaves this ambiguous, ask which granularity to use before execution.

Supported combinations:

1. Implementer Task, reviewer TaskGroup.
2. Implementer Task, reviewer Task.
3. Implementer TaskGroup, reviewer TaskGroup.

Unsupported combination:

• Implementer TaskGroup, reviewer Task.

Checkpoint commit granularity follows reviewer granularity. A checkpoint commit is a real git commit, not a diff snapshot, status report, note, or uncommitted worktree state.

Subagent Prompt Contract

Every subagent prompt must include:

• workspace absolute path
• immutable spec absolute path
• immutable plan absolute path
• drift adjudication ledger absolute path
• current progress state
• assigned scope text verbatim
• explicit reminder to read spec, plan, and drift adjudication ledger in full before working or reviewing
• explicit reminder that the immutable spec is the product truth, the repo or worktree is the executability truth, the drift adjudication ledger is the durable execution-stage overlay artifact, and a proven-unexecutable frozen plan step must be escalated rather than mechanically followed
• explicit reminder that plan drift evidence triggers P9 investigation and adjudication, not automatic termination
• explicit reminder that relevant non-superseded drift-ledger entries are binding workflow state unless superseded by materially new evidence
• explicit reminder that only P9/controller may mutate the drift adjudication ledger; subagents may request supersession but may not edit the ledger directly
• explicit instruction to invoke the role-local skill for the assigned role before acting
• explicit reminder not to leave cleanup for later subagents
• any no-compat / no-legacy rule if that principle applies
• docs rule when docs are touched: YAGNI, Occam's Razor, no historical narration, describe present state only, align format and tone with existing docs

Every subagent prompt must include this explicit compaction-preservation instruction:

If the system interrupts you for compaction, you must add a ##Original MainAgentPrompt section and copy my latest prompt verbatim into it.

Every subagent prompt must also include one explicit compaction-resume instruction:

If you are compacted and lose loaded-skill memory, re-invoke only the workflow skill(s) required for your current role before resuming. Do not re-invoke start-action.

Reviewer Prompt Contract

Reviewer prompts must additionally include:

• You are a reviewer only. Do not modify repo or workspace files.
• Read-only bash verification and probe scripts are allowed and encouraged.
• Do not run destructive commands.
• Re-read the immutable spec, the frozen plan, and the drift adjudication ledger before reviewing the current scope.
• Review immutable spec alignment first. Treat the frozen plan as a derived guide, not co-equal truth.
• If a relevant non-superseded drift-ledger entry already adjudicates the same frozen-plan mismatch and no materially new evidence disproves it, review against the effective execution contract recorded there instead of re-raising the same drift finding.
• If any authoritative review artifact is missing after compaction, broken handoff, or prompt loss, return NEEDS_CONTEXT instead of guessing from partial notes or repo wandering.
• If the drift adjudication ledger is missing after compaction, broken handoff, or prompt loss, return NEEDS_CONTEXT instead of silently re-litigating previously adjudicated drift.
• If the current implementation is spec-correct but a frozen plan step is proven unexecutable or spec-drifting, return plan drift evidence with evidence instead of requesting mechanical re-alignment to the broken step.
• If you believe a relevant non-superseded ledger entry is now wrong, return plan drift evidence with explicit supersession evidence instead of silently ignoring the ledger.
• Return all findings in one pass.

For second and later rounds on the same scope, reviewer prompts must explicitly tell the reviewer to invoke pua and systematic-debugging.

Adjudication Loop

When plan drift evidence appears:

1. P9 pauses the affected scope. Do not let the implementer keep making speculative changes while the drift question is unresolved.
2. Spawn fresh read-only investigation subagents. At minimum, use:
   • one investigation subagent focused on immutable spec plus actual repo or worktree evidence
   • one investigation subagent focused on whether the frozen plan step is still executable as written
3. Investigation subagents may read files and run read-only verification commands, but may not modify repo or worktree files.
4. Ask both subagents to invoke investigate-plan-drift and return one concrete judgment with evidence, not vague risk language.
5. P9 adjudicates using this priority order:
   • immutable spec truth
   • actual repo or worktree executability truth
   • relevant non-superseded drift adjudication ledger entries as already-adjudicated workflow state
   • frozen plan as derived coordination
6. If the adjudication result is EXECUTABLE_AS_WRITTEN, append a CLOSED ledger entry that records the false-positive drift claim, then continue using the frozen plan as written.
7. If the adjudication result is PLAN_DRIFT_CONTINUE_SAFE, append an ACTIVE ledger entry that records the stale plan step, the governing spec requirement, and the effective execution contract, then continue under that recorded understanding.
8. If the adjudication result is SPEC_RECONVERGENCE_REQUIRED, append the ledger entry, then raise SPEC_RECONVERGENCE_REQUIRED.
9. If the adjudication result is INSUFFICIENT_EVIDENCE, append the ledger entry, then raise ADJUDICATION_INSUFFICIENT_EVIDENCE.
10. Later subagent prompts must include the ledger path and any relevant DRIFT_ID values. Do not rely on prompt paraphrase alone.

Implementer Prompt Contract

Implementer prompts must additionally include:

• You own this scope end to end. Do not expect later agents to finish your cleanup.
• Read the drift adjudication ledger before touching code. If a relevant non-superseded entry already defines the safe route, implement against that effective execution contract instead of re-litigating the same stale plan step.
• Do not edit the drift adjudication ledger directly. If you think it must change, return evidence and the relevant DRIFT_ID for P9 to adjudicate.
• Before declaring done, compare your diff against the checkpoint baseline and verify alignment with the task requirements.
• Pass your exact completion claims back so the lead can forward them to both reviewers.
• Do not create a commit until both reviewers converge; after both reviewers converge, create the required git checkpoint commit when the controller requests it.
• If you prove a frozen plan step is unexecutable or spec-drifting, stop and report evidence for P9 adjudication. Do not silently substitute a new route and do not degrade spec compliance just to preserve literal plan alignment.
• If materially new evidence disproves a relevant non-superseded drift-ledger entry, return plan drift evidence with explicit supersession evidence. Do not silently overrule the ledger.

For second and later rounds on the same scope, implementer prompts must explicitly tell the implementer to invoke pua and systematic-debugging.

Frontend Reminder

If a subtask is frontend-related, explicitly instruct the subagent to load relevant frontend skills before acting.

Review Ordering

• Within the main task loop, spec reviewer and code reviewer may run in parallel for the same granularity once the implementer has finished the current scope.
• No checkpoint commit before both are converged.
• During final and regression stages, the paired spec and code reviewers also run in parallel.
• A reviewer that returns empty output has not run for workflow purposes. Do not start a dependent next role, checkpoint, or convergence decision from that non-result; continue that same reviewer thread with exactly continue.
• A reviewer that returns a non-empty invalid, malformed, or nonconforming verdict has not run for workflow purposes. Do not start a dependent next role, checkpoint, or convergence decision from that non-result; send a full corrective reviewer prompt to that same reviewer thread.

Exception State

Allowed hard stop:

• Workspace scaffold or baseline verification reveals a red baseline and the CTO gave no special override.
• P9 adjudication concludes that the immutable spec itself must change before work can safely continue.
• P9 adjudication cannot establish a safe executable path or binding execution overlay from current authoritative evidence.

When this happens, raise an exception report with:

• repo or workspace absolute path
• immutable spec absolute path
• immutable plan absolute path
• drift adjudication ledger absolute path
• current scope
• exact blocked plan step or steps
• adjudication summary
• ledger entry id or ids
• failing baseline commands
• failing output summary
• read-only evidence showing why the step is unexecutable or spec-drifting
• why the workflow cannot safely continue
• explicit statement of which terminal state applies:
  • SPEC_RECONVERGENCE_REQUIRED: the immutable spec must be reconverged first; any later plan or overlay must be derived again from the updated spec before execution resumes
  • ADJUDICATION_INSUFFICIENT_EVIDENCE: authoritative evidence is not yet enough to establish a safe executable path or binding execution overlay

Common Rationalizations

Red Flags

• Reading large amounts of code or editing code yourself instead of dispatching.
• Returning progress before the whole workflow finishes.
• Forgetting to run workspace scaffold and docs copies before execution.
• Selecting the current checkout before reading .gitignore and checking ignored project-local worktree paths.
• Treating a missing .worktrees/ or worktrees/ directory as permission to skip manual worktree creation.
• Letting baseline red tests slide.
• Allowing commits before both reviewers converge.
• Skipping required git checkpoint commits after both reviewers converge because the frozen plan or generic workspace guidance says not to commit unless the user explicitly asks.
• Reusing subagents across different tasks.
• Letting reviewers modify files.
• Forgetting the compaction reminder or the original prompt preservation rule.
• Skipping verification-before-completion or finishing-a-development-branch.
• Forcing spec-correct code back toward a broken plan step instead of returning plan drift evidence for adjudication.
• Resuming a later round without the drift adjudication ledger or treating it as optional context.
• Resuming from compaction or handoff notes with immutable spec, frozen plan, and drift ledger signals but invoking subagent-driven-development, execute-implementation-scope, systematic-debugging, or finishing-a-development-branch before start-action.
• Jumping straight to a terminal adjudication state without running the adjudication loop.
• Keeping an unsatisfiable review loop running after adjudication already established that a frozen plan step is wrong.
• Treating empty subagent output, missing status, malformed status, or invalid verdict as progress.
• Replacing a same-scope implementer, reviewer, final reviewer, regression reviewer, investigator, or fix implementer before the previous same-role thread returns a valid workflow result.
• Sending anything other than exactly continue to a same-role subagent after truly empty output.
• Sending only continue after a non-empty invalid, malformed, or nonconforming role response instead of repairing context with the full same-role prompt contract.
• Implementing, reviewing, fixing, checkpointing, or reporting because the active subagent has not produced a valid result.

Completion

The workflow is complete only when:

1. All task or task-group loops are checkpoint-committed after dual review convergence.
2. The final whole-branch review loop converges.
3. The squash or resquash regression loop reaches HAPPY_END or CONCERNING_END.
4. verification-before-completion is satisfied.
5. finishing-a-development-branch is executed.