---
name: wise-implement-plan-auto
description: >-
  Autonomously implement a written implementation plan (a `PLAN-*.md`
  produced by ticket-auto / ticket-plan) in the current git working
  tree — the plan's task waves are phase gates, each task
  in a wave is handed to a fresh-context executor agent running in
  parallel, and every task lands as one atomic commit with per-task
  verification (type-check / lint / tests). NO prompts. Invoked as
  `/wise-implement-plan-auto` (bare alias) or
  `/wise:wise-implement-plan-auto` (canonical). Use when the user says
  "implement the plan", "execute PLAN-*.md", "build out the plan
  autonomously", or types `/wise-implement-plan-auto`.
argument-hint: "[<plan-file-path>] [--on <harness>[:<model>[:<effort>]] | --on ask]"
allowed-tools: Read, Edit, Write, Task, Agent, TeamCreate, TeamDelete, SendMessage, Monitor, TaskCreate, TaskList, TaskGet, TaskUpdate, TaskOutput, TaskStop, TodoWrite, Bash(git:*), Bash(npm:*), Bash(make:*), Bash(go:*), Bash(python3:*), Bash(cd:*), Bash(bash:*), Bash(cat:*), Bash(head:*), Bash(grep:*), Bash(test:*), AskUserQuestion
---

# /wise-implement-plan-auto — execute a plan, autonomously

## Why this skill exists

`ticket-plan` and `ticket-auto` produce a `PLAN-*.md` but no skill
*executes* one. `/wise-implement-plan-auto` is that executor — a
phase-gated model: parse the plan's task waves, dispatch one fresh-context
executor agent per task in parallel, commit each task atomically,
verify as it goes. It is the reusable building block the `ticket-auto`
workflow's implement phase follows.

## Arguments

Read `$ARGUMENTS`. The first whitespace-separated token, if present,
is the path to the `PLAN-*.md` to implement. When absent, look for a
single `PLAN-*.md` at the git toplevel and use it; if there are zero
or several, stop and ask the user to name one.

## Run on another harness (`--on`)

If `$ARGUMENTS` contains `--on <harness>[:<model>[:<effort>]]` (or
`--on ask` / a bare `--on`), do
NOT run the procedure below in this conversation. Strip the `--on`
tokens (everything left is `SKILL_ARGS`), then read
`${CLAUDE_PLUGIN_ROOT}/references/dispatch.md` and follow it with:

- `SKILL_MD` = `${CLAUDE_PLUGIN_ROOT}/skills/wise-implement-plan-auto/SKILL.md`
- `SKILL_ARGS` = the remaining tokens

`--on ask` (or a bare `--on`) picks harness, model and effort through
one composite `AskUserQuestion` before any child spawns — the ONE
sanctioned prompt in this skill: it happens at invocation time, so the
dispatched run itself stays decision-free.
The reference probes the harness login, validates model and effort
against the engine catalog, and runs the procedure as a headless child
via `engine.sh dispatch`; you only relay its result. Without `--on`,
this section does not apply.

## Procedure

### 1. Resolve the worktree + plan

```bash
git rev-parse --show-toplevel
```

Use the toplevel as `worktree`. Resolve `plan_path` from `$ARGUMENTS`
(or the discovery rule above).

### 2. Follow the shared fragment

Read `${CLAUDE_PLUGIN_ROOT}/workflows/ticket-auto/prompts/implement-plan.md`
and follow it end to end with `plan_path`, `worktree`, `project.kind`
(infer from the worktree's manifest if unknown), and `SUPERVISE=yes`.
The fragment processes waves in order, dispatches the wave's executors
per task (persona: this skill's `agents/executor.md`) — **supervised**
background teammates a leader loop nudges if one hangs or goes idle
mid-task — then simplifies (per-task, scoped to the task's files via
`references/simplify-pass.md`) and commits each task sequentially, and
verifies per task. (To fall back to plain blocking `Task` executors,
pass `SUPERVISE=no` / set `WISE_WORKER_*` env to tune the watchdog.)

### 3. Relay the result

The fragment's final line is
`IMPLEMENT: waves=<w> tasks=<t> done=<d> failed=<f>`. Summarise for
the user — waves run, tasks done, tasks failed (with which ones) —
and remind them nothing was pushed (commit/push is a separate step).

## Guardrails

- Never call `AskUserQuestion` mid-run — the only prompt is the
  argument-resolution stop in §Arguments when the plan is ambiguous.
- One atomic commit per task; never bundle tasks.
- Executors edit files; only this skill simplifies (per-task, scoped)
  and commits, serially — never let parallel subagents race the git
  index. The heavier high-depth code-review branch gate is a separate,
  later pipeline step, not this skill's job.
- Never `git push` — that is the caller's step.
- A failed task does not abort the run.
- Never invoke another wise action skill.