execute-plan git:20261107.aae9987A

Immutable. This exact content never changes and is served at /api/v1/blob/4f901d8489cf7d7d.

---
name: execute-plan
description: Execute a supplied plan or work resolved from session context with final-pass after every phase, then internal review by default, a requested Codex/Claude/Grok review, or both in that order, followed by a final final-pass. Interpret reviewer preferences from freeform user language.
---

# Execute Plan

Complete the full plan or resolved session scope in one autonomous session unless the agreed scope explicitly specifies multiple sessions or a session boundary, subject to user direction. Verify it against the originating request; adapt stale implementation suggestions with evidence while preserving the agreed architecture, contracts, technical constraints, scope, and acceptance criteria. Autonomy over implementation does not authorize changes to these commitments; resolve conflicts with governing requirements and user direction before affected edits, and continue independent work.

## Resolve scope

- Use the supplied plan text, path, or attachment; otherwise resolve the current task from session context, using the latest applicable user-visible plan and later updates when available. If no complete plan exists, derive an actionable scope and coherent phases from the user's requirements and accepted decisions. State that scope briefly before implementation; do not require a saved plan or ask for one solely because it is absent. Ask only when missing information or competing sources materially change scope, acceptance, or authority and cannot be resolved from context.
- Read the full supplied or applicable plan when present, repository instructions, and worktree state before implementation. Read and apply [Resolve plan requirements](../write-plan/references/requirements.md) to interpret current requirements, accepted or delegated agent contributions, and digests without treating chat noise as scope. Later user instructions control conflicts. Resolve material gaps before affected work. References below to the plan and its items also cover the resolved session scope and its phases; the same acceptance and completion rules apply.
- 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.

## Report progress

Progress reporting is required output for the whole execution. It is not optional narration: concise or terse output styles shorten the message but do not remove the progress marker.

- Before implementation, establish the total number of implementation phases `T`. When the plan numbers its phases and gives effort shares, use them as the baseline and correct them against current evidence. Review loops and the closing final-pass are checkpoints, not extra phases.
- Put a progress marker in **every** user-facing message from the start of execution until the final report: the first message, each status update, each reply to a user question, each message after a wake-up or resumed run, and each message that ends a turn while work continues in the background or in a delegated agent. Use one of these forms, as a prefix or suffix:
  - `Phase N/T: <phase name> · ~P% overall`
  - `Review: <loop name> · ~P% overall`
  - `Final-pass · ~P% overall` for the closing final-pass; a phase final-pass keeps its phase marker
- Write `N/T` exactly in that form, not `N of T`. Combine a completion and the next start into one message, for example `Phase 1/3 complete; starting Phase 2/3: Import validation · ~25% overall`. Add the marker to messages you would send anyway; do not send extra messages only to update it.
- Estimate completed effort across the full execution: implementation, each phase final-pass, every selected review loop, likely repairs, and the closing final-pass. Weight phases by expected effort, and reserve a realistic share for review and completion work. Finishing the last phase does not mean execution is nearly complete. Re-estimate at each message; the value can stay the same, and it can move within a long phase.
- Use rounded percentages and keep the calculation internal. If scope, phase count, process, or remaining effort changes materially, update `T` and `P` and give a short reason. Do not keep a misleading value only to make it increase. Keep the current `T` and `P` through handoffs, resumed runs, and compaction.
- Delegated agents do not report progress to the user; the main agent reports it from their results and activity.
- Report `100%` only when the completion conditions below are met. At a blocker or explicit session boundary, report the current estimate and remaining work without implying completion.

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

Keep handoffs short: give the plan path when available, assigned outcome and ownership, essential constraints, and acceptance criteria. For session-only work, provide a concise scope and requirements brief. Agents read any referenced plan and inspect source and Git themselves; do not inline plans, diffs, file contents, or full conversation history. Inside T3 Code, coordinate agents through T3 delegation; outside T3, use the harness's native controls. Require compact findings or results with check evidence and real blockers. Follow the selected review skill without steering its verdict.

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.

Each checkpoint transition above is a progress update under [Report progress](#report-progress). Loaded `final-pass` and review-loop skills do not replace that marker in your messages.

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 and the final progress marker, 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.