git:20261026.15c1827 to git:20261027.eff440e

---

name: execute-plan

---

# Execute Plan

## Resolve scope

- Track requirements, deviations, acceptance evidence, and remaining work in context; files follow the temporary-file rules below. Do not duplicate requirements for bookkeeping. If revising the saved plan, keep its current requirements, provenance, and immediately following TL;DR accurate; a missing heading alone does not block execution.

## Select the review sequence

Interpret the user's request in context, including ordinary language around the invocation. Do not require fixed argument positions, exact spelling or casing, flags, or a strict argument grammar. Distinguish reviewer preferences from provider names that occur only in plan paths, implementation requirements, or background context.

- With no reviewer preference, or an explicit request for internal review only, use [code-review-loop](../code-review-loop/SKILL.md) only.

- With a requested external reviewer, use only its loop: Codex selects [codex-review-loop](../codex-review-loop/SKILL.md), Claude selects [claude-review-loop](../claude-review-loop/SKILL.md), and Grok selects [grok-review-loop](../grok-review-loop/SKILL.md).

- With both internal and an external reviewer requested, run `code-review-loop` first, then the selected external loop, regardless of their order in the request.

For example, `/execute-plan` uses internal review; `/execute-plan with codex` and `/execute-plan codex` use only Codex; `/execute-plan internal and codex` and `/execute-plan codex and internal` use both. These examples illustrate intent, not accepted syntax limits.

State the selected sequence briefly before implementation. Ask only when the intended sequence or external provider remains materially unclear, such as a request for an unspecified external reviewer or competing providers. Never infer an external reviewer from the executing provider or silently substitute another. Confirm that required skill files are available before implementation; a missing dependency blocks implementation until resolved. Load only selected review-loop instructions when their checkpoint is reached. An external loop may read shared internal instructions for its mechanics; that does not select a separate internal loop invocation.

## Coordinate agents

Keep end-to-end reasoning, dependencies, integration, review assessment, and completion with the main agent. Follow the repository's agent-routing rules. Consider delegation when independent implementation, verification, or context isolation improves the result enough to justify coordination and handoff costs. Keep tightly coupled, sequential, or context-heavy work in one loop, either the main agent or a bounded worker. Complexity, domain labels, and execution stages do not by themselves justify separate agents. Judge the choice by whole-task quality, latency, and regressions; neither delegation nor a fixed agent count is required. Reassess when new independent work appears. Before delegating, apply [Subagent roles and reasoning](references/subagent-reasoning.md). Do not invent tools or change the selected review sequence through delegation.

Choose assignments with clear context and ownership boundaries and few dependencies on other active work. Continue useful non-overlapping work while agents run, and reuse relevant agents and evidence rather than repeating completed work.

Assign disjoint edit ownership where possible. Serialize overlapping edits and operations that share mutable state, such as services, databases, fixtures, or generated outputs. Start dependent work only after its prerequisites are integrated and verified. Await assigned work, inspect and reconcile each agent's changes, evidence, check coverage, and residuals, then verify the combined result. The coordinator owns unfinished or failed assignments; an agent's completion claim does not establish plan completion.

## Implement and verify

Before editing, each implementer, including delegated workers, must independently inspect the current affected code, runtime paths, tests, configuration, and documentation and derive and verify the implementation approach within the plan's commitments. Work out file/function changes, algorithms, schemas, and test mechanics from current evidence. Verify any concrete implementation suggestions in the plan; missing routine detail is execution work, not an incomplete plan.

- Fix root causes and add meaningful regression coverage where practical. Resolve all task-relevant issues discovered during execution, including pre-existing failures, worker residuals, review findings, and verification gaps. Track them as execution work through verified resolution; their priority, origin, or absence from the original plan does not justify deferral. Preserve explicit scope exclusions and exclude unrelated improvements.

- Remove confirmed obsolete, duplicate, dead, or unnecessary compatibility code and related tests/configuration/docs in the changed and directly affected surface. Preserve required behavior, explicit compatibility, and unrelated work; do not invent cleanup or transition machinery.

- Read repository instructions and CI for required checks. Run focused checks during implementation and required gates on the integrated result. For documentation-only work, use document/skill validators, not unrelated application suites. Scale additional checks and local/staging validation to risk and authority.

- Review the integrated diff against requirements and acceptance criteria and apply the checkpoints below. Apply [Check evidence and reuse](../final-pass/references/check-evidence.md) across implementation, loop verification, and final-pass checkpoints; rerun invalidated gates and report reused results with their origin.

Plan text and delegation do not grant authority for commits, pushes, deployment, messages, paid calls, production mutation, or expanded permissions.

## Completion and review checkpoints

This sequence also governs checkpoint links reached through `final-pass` or any selected review loop. Do not add per-phase review loops, intermediate final passes between selected loops, or extra review invocations through those links. Review mechanics and assessment of substantive coverage belong to the selected review skills; do not copy them here, add handoff-format gates, or substitute reviewers. Check evidence can remain valid across checkpoints under the shared reuse policy; an earlier review cannot cover later task edits.

1. Implement each coherent phase and verify its acceptance criteria and integration with completed work. Define phases by coherent deliverables and acceptance checks, not arbitrary batches. Resolve all discovered task-relevant issues within scope; reject unsupported claims with evidence. Run [final-pass](../final-pass/SKILL.md) after **every phase**, including the last, before closing the phase or starting dependent work. Use its standalone check mode: post-loop recovery waits until the selected review sequence returns. Keep all selected reviews explicitly **pending**; phase verification does not establish review completion. Perform its cleanup and required gates each time. Continue phases back to back without a per-phase review loop or routine user handoff.

2. After all phases and their final passes are complete, invoke **each selected review loop exactly once**, in the selected sequence. Each loop covers the **entire current integrated implementation**, including all phases and task-attributable repairs and cleanup. In combined mode, finish the internal loop before starting the external loop; the external loop reviews the resulting state, including internal-loop repairs. Use the original requirements and acceptance criteria, full task surface, and exclusions. One invocation can contain multiple bounded rounds under that skill's contract; it is not one review prompt. Follow each loop's runtime, authority, context, round limits, failure recovery, final read-only audit, and handoff rules without substitution or nested loops. Each selected loop has its own round budget. For internal review delegation, follow the [shared runtime selection policy](../code-review/references/external-runtime.md#select-the-runtime): use fresh T3 tasks when its orchestrator is available, with ACP fallback when unavailable. Without T3, internal review delegation remains optional; use a separate reviewer when independent scrutiny adds value. Keep reviewer assignments read-only and bounded to this target and acceptance criteria. Keep loops, rounds, and remediation sequential; parallel inspections stay within a round and do not add rounds or replace integration review. Retain each loop's status and reconcile its handoff into the caller-owned finding ledger, respecting the next reviewer's context restrictions. A capped or incomplete internal result does not cancel the selected external loop; continue authorized independent work under the stop rules.

3. After the selected sequence returns, run `final-pass` **again**, even if the last phase already passed. Reconcile all selected loops' findings, residuals, failed checks, and missing coverage with the complete implementation. Finish authorized repairs and verification under `final-pass`'s post-loop recovery rules. A cap ends that review invocation, not the execution obligation. Never restart a loop or add disguised rounds to evade its cap. Preserve each loop's actual status and coverage; later repairs do not make an earlier loop a review of the final state. Identify repairs verified without fresh review; direct inspection cannot create a clean loop result.

For a single-phase plan, the order is still implementation, phase `final-pass`, selected review sequence, then final `final-pass`. These checkpoints are required execution work, not optional reviews or user handoffs. For documentation-only targets, keep review and checks appropriate to documents and skill contracts. A blocked required phase check prevents advancing dependent work; finish independent authorized work under the stop rules below.

Close execution only when every requirement has acceptance evidence or justified supersession, task-relevant issues are resolved, required checks pass, every selected loop has returned, and final-pass has established any missing coverage with evidence. Do not relabel actionable work as a residual risk, known failure, optional follow-up, or future phase to claim completion. Report the selected sequence, each loop's actual reviewed state, coverage and terminal status, executed and reused checks, and any concrete blockers or unreviewed repairs. Deferred review is never completed review. Preserve the full-completion and blocker rules through handoffs and compaction.

## Finish

Check every plan item and requirement for acceptance evidence, unresolved findings, cleanup, and required checks. Within the current session, continue through phases, milestones, handoffs, review, remediation, and compaction without asking whether to continue or giving a partial final response. Size, complexity, risk, elapsed effort, and fixable check failures do not create session boundaries.

Stop with work remaining only when the plan explicitly sets a session boundary consistent with user direction, the user directs it, or a concrete blocker requires missing authority, input, or external change. Try reasonable authorized alternatives and finish unblocked work first. Report the blocker evidence, remaining work, and what is needed. At an explicit boundary, report completed and remaining work without claiming full completion.

Lead with the outcome, then material deviations, check results, and blockers or unverified behavior. Use short, plain prose without stock headings or repeated summaries. Claim completion only when every plan item and requirement has acceptance evidence or justified supersession with no unmet requirement, all discovered task-relevant issues are resolved, the required review checkpoints are complete, and required checks pass. Save an execution report only if requested.

## Temporary files

Keep scratch in context unless files serve a concrete agent need; never create them solely for user presentation. Track task-owned paths; remove them after use, including failure or abandonment, and verify cleanup before returning. Retain files only for active agent continuation with a cleanup owner and removal point; report retained paths or cleanup failures. Preserve requested deliverables (including `.local/` plans), pre-existing files, and unrelated work; never delete shared directories wholesale.