Implement Next
Purpose
Advance exactly one ready task from the TASKS.md ledger through a single implementation cycle, using its persisted issue brief as context. One invocation advances at most one task; it never iterates. Repeat the command for the next task.
Preconditions
TASKS.md exists and is an index-only ledger whose rows link to issue briefs.
- If
TASKS.md is missing or contains no ready task, stop and report the ledger state; do not invent work.
Flow
- Read
TASKS.md and select the first task in state ready.
- Stop at a
human-gate task and explain the approval it needs; do not proceed past it.
- Skip
blocked and sequenced tasks; they are not ready.
- If no
ready task exists, stop and report.
- Mark the selected task
in-progress in TASKS.md through the client's write-approval flow.
- Load the linked issue brief and run
subagent-driven-change with the brief as Fresh Context. Its owner runs code-quality-reviewer before change-risk-reviewer; initiate or resume the closed change-risk handoff and report its current state, but do not independently invoke another review, redefine budgets, or reset counters.
- Mark the task
done only after the owner returns a validated terminal CLEAN handoff and required tests run green. Validate the closed ChangeRiskOrchestrationStateV1 record; its snapshot matches the current snapshot (modulo docs/review-learning/) and its terminal status is CLEAN. Do not infer completion from free-form prose or an unvalidated status. The next task requires a new invocation.
- If the validated handoff reports
NO_PROGRESS or NEEDS_HUMAN_REVIEW, report that outcome and its required escalation; do not mark the task done or start another review. Keep the task out of done until a human resolves the escalation.
Failure Path
Stop and report BLOCKED when any of these holds:
implementer returns BLOCKED or NEEDS_CONTEXT,
- a review finding cannot be resolved within the brief's scope,
- GREEN is unreachable within the brief's declared seam.
On failure, mark the task blocked in TASKS.md with a one-line reason; if the declared seam was wrong, include why it failed. Then stop. Do not touch the next task, do not edit the brief, and do not continue to another task. A human decides whether to edit the brief, re-grill, or split the task, and flips the state back to ready.
Output
Report the selected task, the state transitions applied, the subagent results, the tests run, the change-risk handoff status when applicable, and the final state (done or blocked with its one-line reason).
Safety
- Do not upload source code.
- Do not read or print secrets.
- Do not iterate across tasks; one invocation advances at most one task.
- Do not self-approve; all writes, commits, and destructive steps go through the client's write-approval flow.
- Do not edit issue briefs or advance a task that failed.
- Do not propose
bypassPermissions, tool pre-approval, dependency auto-installation, hosted execution, or remote MCP behavior.
1---2name: implement-next3description: Use after synthesis to dispatch the next ready task from the TASKS.md ledger through one subagent-driven implementation cycle, one task per invocation.4---56<!-- Generated by Agent Profile Compiler. Do not edit by hand. -->78# Implement Next910## Purpose1112Advance exactly one ready task from the `TASKS.md` ledger through a single implementation cycle, using its persisted issue brief as context. One invocation advances at most one task; it never iterates. Repeat the command for the next task.1314## Preconditions1516- `TASKS.md` exists and is an index-only ledger whose rows link to issue briefs.17- If `TASKS.md` is missing or contains no `ready` task, stop and report the ledger state; do not invent work.1819## Flow20211. Read `TASKS.md` and select the first task in state `ready`.22 - Stop at a `human-gate` task and explain the approval it needs; do not proceed past it.23 - Skip `blocked` and `sequenced` tasks; they are not ready.24 - If no `ready` task exists, stop and report.252. Mark the selected task `in-progress` in `TASKS.md` through the client's write-approval flow.263. Load the linked issue brief and run `subagent-driven-change` with the brief as Fresh Context. Its owner runs `code-quality-reviewer` before `change-risk-reviewer`; initiate or resume the closed change-risk handoff and report its current state, but do not independently invoke another review, redefine budgets, or reset counters.274. Mark the task `done` only after the owner returns a validated terminal `CLEAN` handoff and required tests run green. Validate the closed `ChangeRiskOrchestrationStateV1` record; its snapshot matches the current snapshot (modulo `docs/review-learning/`) and its terminal status is `CLEAN`. Do not infer completion from free-form prose or an unvalidated status. The next task requires a new invocation.285. If the validated handoff reports `NO_PROGRESS` or `NEEDS_HUMAN_REVIEW`, report that outcome and its required escalation; do not mark the task `done` or start another review. Keep the task out of `done` until a human resolves the escalation.2930## Failure Path3132Stop and report `BLOCKED` when any of these holds:3334- `implementer` returns `BLOCKED` or `NEEDS_CONTEXT`,35- a review finding cannot be resolved within the brief's scope,36- GREEN is unreachable within the brief's declared seam.3738On failure, mark the task `blocked` in `TASKS.md` with a one-line reason; if the declared seam was wrong, include why it failed. Then stop. Do not touch the next task, do not edit the brief, and do not continue to another task. A human decides whether to edit the brief, re-grill, or split the task, and flips the state back to `ready`.3940## Output4142Report the selected task, the state transitions applied, the subagent results, the tests run, the change-risk handoff status when applicable, and the final state (`done` or `blocked` with its one-line reason).4344## Safety4546- Do not upload source code.47- Do not read or print secrets.48- Do not iterate across tasks; one invocation advances at most one task.49- Do not self-approve; all writes, commits, and destructive steps go through the client's write-approval flow.50- Do not edit issue briefs or advance a task that failed.51- Do not propose `bypassPermissions`, tool pre-approval, dependency auto-installation, hosted execution, or remote MCP behavior.