WT Autopilot
autopilot carries one wt work item after the human-reviewed ready
handoff. It does not remove wt's judgment boundary; it moves the boundary to the
ready handoff, then runs the remaining lifecycle — execution, review, landing,
and harness settlement — with automatic reviews, hard stops, and evidence.
TaskDocument나 workflow 골격이 필요하면 wt scaffold <slug> --task /
--workflow로 시드한다. 탐색·사고 산출물은 wt 밖의 일이다 — leaf-work와
.leaf/ workspace를 사용한다.
Lifecycle Reference
Before starting the loop, read references/task-lifecycle.md for
TaskDocument/TaskRun/workflow object model, status boundaries, pass vs cleanup,
and workflow-linked task boundaries. autopilot does not decide readiness
gates itself; route unclear or unprepared work through ready, which owns
that preparation model.
Core Contract
- Handoff first. Do not start unless
ready has produced an approved
launch target: the exact launch command and inspect target, the workflow
landing policy, and the TaskDocument bodies. If that handoff is missing,
provisional, stale, or the intent is still vague or the design open, return to
ready (which routes thinking to leaf-work when needed).
- Autopilot after the handoff. Once the launch target is approved, proceed
automatically: launch and coordinate with
work, then land and settle with
land. Stop only when a hard stop or pre-authorization gap appears.
- Review still happens. Code review, checks, and spec sync are automatic
unless a hard stop or pre-authorization gap appears. Leave the evidence — review
notes, check output, PR/merge links, pass proof — recorded where the lifecycle
skill keeps it.
- Do not duplicate the lifecycle skills. Invoke and follow
ready,
work, and land when their contracts apply. This skill orchestrates
them; it does not rewrite their rules. When moving from one to the next, load
and follow that skill body instead of reimplementing it from memory.
- Carry the original context. Keep the user's original context through every
step. Boundaries stay explicit: preparation is not launch, TaskRun pass is not
landing, cleanup happens only after landing or discard intent is proven, and the
retrospective is written after the work item is closed — not mid-flight.
Start Checklist
Before doing work:
- Read
references/task-lifecycle.md for the object model and status
boundaries.
- Run
git status --short --branch and confirm the worktree/branch state.
- Confirm the
ready handoff exists and is approved: launch command, inspect
target, workflow policy, and TaskDocument bodies are present and internally
consistent.
- Read
references/approval-policy.md when the request involves execution with
external side effects, credentials, cost, security, privacy, or ambiguity
about what autopilot may decide on the user's behalf.
If any start check fails, stop with the smallest needed repair or user question.
Unprepared or vague work returns to ready, not into autopilot.
Workflow
- Consume the handoff. Treat the approved launch target as the current
contract. If execution reveals it is wrong (bad slicing, wrong policy, changed
scope), return to
ready, record why, and do not continue on the old
contract.
- Execute and coordinate with
work. Launch the prepared task or
workflow, capture the inspect target, monitor the run, inspect agent state,
review code, run checks, sync the living spec, and send focused feedback until
the work is acceptable.
- Audit before landing. Do not treat "PR opened" or "files changed" as done.
Map the launch target and acceptance criteria to evidence: review verdict,
check/test output, and unresolved assumptions.
- Land and settle with
land. Respect workflow landing policy, perform
any applicable pass step, land branches in the right order, prove ancestry or
discard intent, clean up with wt done, and record keep/problem/try lessons,
action candidates, harness-tuning records, and expected vs actual duration with
watch-cadence evidence. Write the timing entry even when there was no broader
lesson.
Hard Stops
Stop and ask for explicit user direction when any of these appear without prior
authorization:
- the
ready handoff is missing, stale, contradicted, or not approved;
- an unresolved HITL decision the agent surfaced;
- destructive or hard-to-revert changes;
- credentials, secrets, external accounts, production systems, deployment, or
cost-incurring actions;
- public or external sharing;
- security, privacy, legal, policy, or permission-boundary decisions;
- scope expansion, a split decision, or a changed core of the work;
- merge conflicts owned by the task branch, or unsafe cleanup conditions;
- failed review, failed checks, or a failed completion audit;
- the same failure repeats three times;
- active agent work that still legitimately needs time (wait, do not force).
When progress stops for a reusable reason, write a retrospective to record why,
even though landing did not happen.
Completion Audit
Before reporting completion, show:
- the launch target consumed (launch command, inspect target, workflow policy);
- the current lifecycle step and TaskRun/workspace state;
- review and check verdicts with evidence paths (review notes, check output,
PR/merge or pass proof);
- the landing or discard proof: merge/ancestry evidence, or proven discard intent
plus the
wt done cleanup command;
- the retrospective file path when written, including timing and watch-cadence
evidence;
- hard stops checked and not triggered, or the stop that remains;
- any remaining blocker.
Do not hide unresolved assumptions. If something was delegated to a task agent
rather than human-approved, say where that delegation is recorded.
Anti-Patterns
- Starting before the
ready handoff is approved.
- Treating "no human approval needed" as "no review needed".
- Calling work landed because a PR exists, without a completion audit.
- Absorbing a task-branch merge conflict into the coordinator without the user
asking for it.
- Running cleanup before ancestry or explicit discard intent is proven.
- Writing the retrospective mid-flight instead of after the item is closed.
- Rewriting
ready / work / land contracts inside this skill.
1---2name: autopilot-23description: Use after ready has handed off an approved launch target (launch command, inspect target, workflow policy, TaskDocument bodies), when the user wants the rest of the wt lifecycle — launch, coordinate, review, land, retrospect — to proceed automatically with automatic reviews, hard stops, and evidence. Trigger on "$autopilot", "wt autopilot", "launch target approved, run the rest automatically", or "after ready, carry it the rest of the way". Do not use before the ready handoff, for unclear or unprepared work (route to ready), or for destructive / external / credential / cost / security / privacy-sensitive actions without explicit pre-authorization.4---56# WT Autopilot78`autopilot` carries one wt work item after the human-reviewed `ready`9handoff. It does not remove wt's judgment boundary; it moves the boundary to the10ready handoff, then runs the remaining lifecycle — execution, review, landing,11and harness settlement — with automatic reviews, hard stops, and evidence.1213TaskDocument나 workflow 골격이 필요하면 `wt scaffold <slug> --task` /14`--workflow`로 시드한다. 탐색·사고 산출물은 wt 밖의 일이다 — `leaf-work`와15`.leaf/` workspace를 사용한다.1617## Lifecycle Reference1819Before starting the loop, read `references/task-lifecycle.md` for20TaskDocument/TaskRun/workflow object model, status boundaries, pass vs cleanup,21and workflow-linked task boundaries. `autopilot` does not decide readiness22gates itself; route unclear or unprepared work through `ready`, which owns23that preparation model.2425## Core Contract2627- **Handoff first.** Do not start unless `ready` has produced an approved28 launch target: the exact launch command and inspect target, the workflow29 landing policy, and the TaskDocument bodies. If that handoff is missing,30 provisional, stale, or the intent is still vague or the design open, return to31 `ready` (which routes thinking to `leaf-work` when needed).32- **Autopilot after the handoff.** Once the launch target is approved, proceed33 automatically: launch and coordinate with `work`, then land and settle with34 `land`. Stop only when a hard stop or pre-authorization gap appears.35- **Review still happens.** Code review, checks, and spec sync are automatic36 unless a hard stop or pre-authorization gap appears. Leave the evidence — review37 notes, check output, PR/merge links, pass proof — recorded where the lifecycle38 skill keeps it.39- **Do not duplicate the lifecycle skills.** Invoke and follow `ready`,40 `work`, and `land` when their contracts apply. This skill orchestrates41 them; it does not rewrite their rules. When moving from one to the next, load42 and follow that skill body instead of reimplementing it from memory.43- **Carry the original context.** Keep the user's original context through every44 step. Boundaries stay explicit: preparation is not launch, TaskRun pass is not45 landing, cleanup happens only after landing or discard intent is proven, and the46 retrospective is written after the work item is closed — not mid-flight.4748## Start Checklist4950Before doing work:51521. Read `references/task-lifecycle.md` for the object model and status53 boundaries.542. Run `git status --short --branch` and confirm the worktree/branch state.553. Confirm the `ready` handoff exists and is approved: launch command, inspect56 target, workflow policy, and TaskDocument bodies are present and internally57 consistent.584. Read `references/approval-policy.md` when the request involves execution with59 external side effects, credentials, cost, security, privacy, or ambiguity60 about what autopilot may decide on the user's behalf.6162If any start check fails, stop with the smallest needed repair or user question.63Unprepared or vague work returns to `ready`, not into autopilot.6465## Workflow66671. **Consume the handoff.** Treat the approved launch target as the current68 contract. If execution reveals it is wrong (bad slicing, wrong policy, changed69 scope), return to `ready`, record why, and do not continue on the old70 contract.712. **Execute and coordinate with `work`.** Launch the prepared task or72 workflow, capture the inspect target, monitor the run, inspect agent state,73 review code, run checks, sync the living spec, and send focused feedback until74 the work is acceptable.753. **Audit before landing.** Do not treat "PR opened" or "files changed" as done.76 Map the launch target and acceptance criteria to evidence: review verdict,77 check/test output, and unresolved assumptions.784. **Land and settle with `land`.** Respect workflow landing policy, perform79 any applicable pass step, land branches in the right order, prove ancestry or80 discard intent, clean up with `wt done`, and record keep/problem/try lessons,81 action candidates, harness-tuning records, and expected vs actual duration with82 watch-cadence evidence. Write the timing entry even when there was no broader83 lesson.8485## Hard Stops8687Stop and ask for explicit user direction when any of these appear without prior88authorization:8990- the `ready` handoff is missing, stale, contradicted, or not approved;91- an unresolved HITL decision the agent surfaced;92- destructive or hard-to-revert changes;93- credentials, secrets, external accounts, production systems, deployment, or94 cost-incurring actions;95- public or external sharing;96- security, privacy, legal, policy, or permission-boundary decisions;97- scope expansion, a split decision, or a changed core of the work;98- merge conflicts owned by the task branch, or unsafe cleanup conditions;99- failed review, failed checks, or a failed completion audit;100- the same failure repeats three times;101- active agent work that still legitimately needs time (wait, do not force).102103When progress stops for a reusable reason, write a retrospective to record why,104even though landing did not happen.105106## Completion Audit107108Before reporting completion, show:109110- the launch target consumed (launch command, inspect target, workflow policy);111- the current lifecycle step and TaskRun/workspace state;112- review and check verdicts with evidence paths (review notes, check output,113 PR/merge or pass proof);114- the landing or discard proof: merge/ancestry evidence, or proven discard intent115 plus the `wt done` cleanup command;116- the retrospective file path when written, including timing and watch-cadence117 evidence;118- hard stops checked and not triggered, or the stop that remains;119- any remaining blocker.120121Do not hide unresolved assumptions. If something was delegated to a task agent122rather than human-approved, say where that delegation is recorded.123124## Anti-Patterns125126- Starting before the `ready` handoff is approved.127- Treating "no human approval needed" as "no review needed".128- Calling work landed because a PR exists, without a completion audit.129- Absorbing a task-branch merge conflict into the coordinator without the user130 asking for it.131- Running cleanup before ancestry or explicit discard intent is proven.132- Writing the retrospective mid-flight instead of after the item is closed.133- Rewriting `ready` / `work` / `land` contracts inside this skill.