Implement And Review

Build one task to its acceptance contract with the exact approved implementation and review routes. The next consumer is implement-tasks or the user. A worker result is evidence for integration. It must not mark a task queue complete. The parent marks a task complete only after integration checks pass with no unresolved acceptance or blocking defect.

The routing plan is a binding record, not a suggestion. It selects the implementation and review seat, runner, model, effort, mode, and any approved fallback. Read shared/references/implementation-routing-plan.schema.json and shared/references/task-shaped-model-routing.md before dispatching work.

Authority

The user request to implement authorizes edits inside the accepted task, its stated verification, and reversible worktree isolation. It does not authorize a commit, push, merge, pull request, deployment, external message, or destructive cleanup. A routing-plan approval authorizes only the recorded routes. Commit-based integration needs separate explicit authority.

Before Writing Code

1. Read the task, acceptance contract, and active project conventions. Inspect the relevant code and tests.
2. Confirm the task input files still match the routing plan hashes. The launcher enforces this before it writes files, creates worktrees, or starts a worker.
3. If the task came from implement-tasks, use its approved plan. For a standalone task, prepare the same model summary, show it to the user, and wait for approval or changes before starting a worker.
4. Start with one track. Add a second track only when their scopes and contracts are independent. Worktree isolation is reversible and needs no separate approval. Commit-based integration remains separately authorized.

Never call models-consensus from this skill. A user who wants more opinions invokes that workflow separately.