wise-implement-plan-auto · diff
git:20260725.7dfa442 to git:20260906.8b0eb38
22 added, 2 removed. Audit A to A.
---
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>]"
- 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:*)
+ 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.