/execute

description: Execute implementation plan from /lets:plan - inline in native plan mode, or delegated to named implementer subagents you review and correct
argument-hint: "[task-id|plan-path] [--status] [--step|--straight|--auto|--implementers] [--parallel] [--pipelined] [--gate per-commit|high-only|at-end] [--solo]"

Execute Plan

Load an implementation plan and execute it - inline, in Claude Code's native plan mode, or delegated: each commit-point chunk goes to a named implementer subagent, its diff is reviewed - by you or, under the gate policy you approve at Start, by the team's check - and corrections go back to that same agent. The plan provides the roadmap; the gates are plan mode (inline) or Step 5-D's Start, review and run-review gates (delegated).

**Plan is a roadmap, not a script.** Read real files before every change. Adapt cosmetically (a renamed variable, a line that moved). Anything that changes the plan's APPROACH is a **deviation** - see the Deviation gate in Step 5 - and STOPS the run; a silently adapted plan is a new, unapproved plan.

**Another agent instead of this session:** `/lets:handoff --execute --send [<tab>]` hands the plan to an agent tab of this worktree (Codex, Antigravity, Claude) as a self-contained brief; its commits come back UNVERIFIED for `/lets:review --branch`.

> **IMPORTANT:** If the spec below invokes any deferred tool (e.g. `AskUserQuestion`), you MUST load and call it as specified. Never skip the call, never substitute a default answer of your own — the tool invocation is part of the contract. This is critical.

--auto mode

`/lets:execute --auto` runs the approved plan **autonomously**: skip the per-step "review before moving on" gate and commit at each plan commit point through `Skill(skill: "lets:commit", args: "approved=plan-files")` WITHOUT re-asking (matches the established "autonomous commits during execute after plan approval" preference). `--auto` is execution-speed for an *already-approved* plan — it does NOT bypass the hard-stops.

**`--auto` = run under AUTO MODE** (see `.claude/rules/lets-rules.md` `## AUTO MODE`) — do NOT restate the contract here. What still applies under `--auto`: push / PR / close (tracker `close`) / external stay gated; a 3×-fail halts; fabrication halts; and **`--auto` on `$LETS_MERGE_BRANCH` REFUSES** (Step 1) rather than auto-entering trunk-mode. When a hard-stop is hit, write the `blocked` marker and fire the execute-blocked notify (Step 6 / the gate-notification block) so an unattended session surfaces instead of stalling.

Parse `--auto` from the argument (it composes with a plan path; it is mutually exclusive with `--status`).

Pipeline-state marker (under `--auto`)

A spawned autonomous session records its phase in a **per-task** marker file so N parallel worktrees don't clobber each other and the gate-notify (Step 6) can tell autonomous from interactive runs. **Per-task filename** (NOT a shared `pipeline-state` — `.lets/` is a symlink shared across worktrees): `.lets/cache/pipeline-state-<task-id>`, single line `<task-id>|<phase>|<iso>`, phase ∈ `planning | gate-clarify | gate-approve | executing | blocked | done`. Write helper (run at each transition; only under `--auto` — interactive execute writes no marker, so it triggers no notify):

LETS_PROJECT_ROOT=$(git rev-parse --show-toplevel); mkdir -p "$LETS_PROJECT_ROOT/.lets/cache"
printf '%s|%s|%s\n' "{TASK_ID}" "{PHASE}" "$(date -u +%Y-%m-%dT%H:%M:%SZ)" > "$LETS_PROJECT_ROOT/.lets/cache/pipeline-state-{TASK_ID}"

`execute --auto` writes `executing` when implementation starts (Step 5), `blocked` on a hard-stop (with the notify), `done` on completion (Step 6). **Keep in sync:** the same contract + helper live in `plan-workflow.md` (which writes `planning`/`gate-clarify`/`gate-approve`).

**Execute-blocked notify.** On a hard-stop under `--auto` (3×-fail / fabrication / a gated op reached / `$LETS_MERGE_BRANCH` refused), after writing the `blocked` marker, fire the **marker-gated gate-notification** so an unattended session surfaces instead of stalling. Use the authoritative snippet documented in `plan-workflow.md` "## Gate notifications" (don't re-paraphrase), incl. its single-quote rule for substituted values: `lets notify --cwd "$LETS_PROJECT_ROOT" --title 'Execute blocked — needs you' --body '<reason>' --json 2>/dev/null || true` (launcher-neutral — dispatches on `LETS_LAUNCHER`), guarded by the `pipeline-state-{TASK_ID}` marker existing. Best-effort — the run also halts visibly in-band. With the blocked marker, also mirror it onto the Orca card:

[ "{LETS_LAUNCHER}" = "orca" ] && lets orca card --phase blocked --comment '{reason}' --json 2>/dev/null || true

Step 1: Active Task Detection

**Positional argument** — if it is a path (ends in `.md` or contains `/`), it is a **plan-path**: bind `{PLAN_ARG}` to it (Step 2 consumes it and skips slug derivation) and skip the task resolve-and-claim below. Otherwise treat it as a `<task-id>`.

Use the **detect-task** skill to find the active task: `Skill(skill: "lets:detect-task")`. If not on a feature/worktree branch and no in-progress task found - ask user which task to execute.

If invoked with an explicit `<task-id>` argument and it is not already the active/in-progress task (e.g. a spawned `execute --auto <id>` in a fresh worktree), resolve-and-claim it per the **detect-task** *explicit task-id argument* convention before resolving the plan - don't re-paraphrase the logic; that section is the single source of truth (incl. the AUTO-MODE entry-claim carve-out). `--orc` is stripped per that convention before the task-id test.

**If on `$LETS_MERGE_BRANCH`** — `/lets:execute` usually expects a feature branch.

**Under `--auto`: REFUSE, do NOT show the soft-gate.** Autonomous editing of the merge-branch must never be auto-authorized — trunk-mode is a deliberate human opt-in (via the take-task picker), and an unattended session cannot answer an `AskUserQuestion`. Writ