implement-next

name	implement-next
description	Use after synthesis to dispatch the next ready task from the TASKS.md ledger through one subagent-driven implementation cycle, one task per invocation.

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

1. 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.
2. Mark the selected task in-progress in TASKS.md through the client's write-approval flow.
3. Load the linked issue brief and run subagent-driven-change with the brief as Fresh Context: implementer, then spec-reviewer, then code-quality-reviewer.
4. When reviews pass and the required tests run green, mark the task done and stop. The next task requires a new invocation.

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, 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.