autodev + ad-wrap-up: Claude Code skills for plan/build/test/review in an isolated worktree

ad-wrap-up-SKILL.md

name	ad-wrap-up
description	Wrap up an approved autodev run — final test pass, lint, commit the worktree diff, merge the autodev branch, reconcile task lists, update the wiki, then clean up the worktree, branch, and run notes. Use after the user approves work presented by the autodev skill ("wrap it up", "merge the autodev work", or immediately on approval at the end of an autodev run).

Autodev Wrap-Up

Closes out an approved autodev run. Do not invoke on unapproved or rejected work. No /simplify here — the work already passed an adjudicated code review and a judge acceptance; rewriting it post-acceptance would make the merged code differ from what was accepted.

Locate the run

• Worktree: <repo>/.claude/worktrees/<slug>, branch autodev/<slug>, run notes <repo>/.claude/autodev/<slug>/.
• Resolve the main repo root (from inside the worktree: parent of git rev-parse --git-common-dir). The project's identity — wiki task list name, wiki-update context — always derives from the main root's basename, never the worktree folder (which is named after the task).

Steps — in the worktree

1. Re-run the tests (the plan's test commands, or the project's standard suite). Exit code is the only truth. Red → stop and report; never merge failing work.
2. Lint if the project has a linter configured. Fix lint findings only; if anything changed, re-run the tests.
3. Docs — update relevant /docs files if the run made architectural changes worth recording.
4. Commit everything on the autodev branch with a message summarizing the task. Then verify git status --porcelain is empty — never proceed with a dirty worktree.
5. Reconcile the project's wiki task list — same two-way procedure as the close-out skill: read ~/.obsidian-wiki/config, load $OBSIDIAN_VAULT_PATH/projects/<project-name>/tasks.md if it exists, compare ## Next, ## Inbox, and ## Deferred against what this run actually did. Completed items → confirm with the user, then /task-done. New follow-ups, TODOs, or discovered issues → confirm, then /task-inbox. Skip silently if no task file exists.

Steps — in the main checkout

6. Merge. Require the main checkout clean (git status --porcelain); if dirty, stop and ask the user. Then git merge autodev/<slug> on the base branch. On conflict: abort the merge, report, and ask — never resolve conflicts unilaterally.
7. Wiki-update. Run /wiki-update from the main root so the merged work is distilled.
8. Cleanup (only after a successful merge):
   • git worktree remove "<worktree-path>" — without --force; if git refuses, something is uncommitted, so stop and report rather than forcing.
   • git branch -d autodev/<slug> — lowercase -d; it only deletes merged branches, which is the safety check.
   • Delete the run notes: rm -rf "<repo>/.claude/autodev/<slug>".

Report

End with a short summary: test result, lint result, commit hash, merge result, tasks reconciled, wiki updated, cleanup done. Every line states what actually happened — a skipped step is reported as skipped, never silently dropped.

autodev-SKILL.md

name

autodev

description

Autonomously plan, build, test, review, and present a coding task in an isolated git worktree. Use when the user hands over a coding task ("autodev this", "run autodev", "have autodev build X"), including under /loop for long autonomous runs. The session drives the process on a flat-rate model and narrates visibly; every real judgment call (plan approval, review adjudication, final acceptance) goes to a one-shot Fable subagent with a small distilled input.

Autodev (hybrid: flat-rate driver, Fable judge)

Two roles, strictly separated:

• You (the driver) follow this process: coordinate subagents, run commands, narrate each step briefly so the user can watch. You do NOT make the judgment calls.
• Fable subagents (the judge) decide everything that matters: whether the plan is sound, which review findings are real, whether the finished work matches the promise. One-shot, no tools, small distilled input, structured verdict out.

Cost guard

If this session itself is running on Fable (a metered model), STOP before launching: tell the user the driver re-reads the whole context every tool call (a prior run cost $6.35 in driver overhead alone) and suggest /model opus first. Proceed only on their say-so.

Economy rules

• Driver: delegate repo exploration and coding to subagents; read their conclusions, not the files. Run cheap deterministic commands (tests, git diff --stat) yourself — short output, ground truth.
• Judge: never send Fable raw code, whole files, or transcripts. It gets the task sentence plus exactly one distilled artifact: a one-page plan, a findings table, or a diff stat + test tail. This keeps total judge spend near $1, where the engine proved it lives.

Size the task first — and say which size you chose

• small — one obvious change, low blast radius: worktree → implement → test → acceptance → present.
• medium — multi-file, or any real design choice: add a plan (judge-approved before implementing) and one code review (judge-adjudicated) after tests pass.
• large — architecture, migrations, unfamiliar subsystem: add a scout brief before planning and two parallel plan reviewers whose findings the judge weighs; suggest /loop if the user is stepping away.

If a wrong guess about intent (not implementation) would waste the run, ask the user one plain-English question before starting.

Protocol

1. Worktree — all work happens in an isolated worktree; the user's checkout is never touched. Use the native worktree tool if available; otherwise git worktree add "<repo>/.claude/worktrees/<slug>" -b autodev/<slug> and add .claude/worktrees/ to .git/info/exclude if missing. Keep run notes (plan, verdicts) in <repo>/.claude/autodev/<slug>/ so an interrupted run can be picked up.

2. Scout (large) — an Explore subagent produces a compact brief: relevant files, patterns, constraints.

3. Plan (medium+) — an Opus subagent drafts a short plan with explicit test commands, ending with a user-verification list: the commands a human runs to see the change working and what they should see for each. Present surfaces this list verbatim (updated only if reality diverged). Then a Fable subagent judges it: send the task + the plan, ask for approve / must-fix list. Must-fixes go back to the planner; if the judge rejects twice, take it to the user. Never implement an unapproved plan.

4. Implement — a Sonnet subagent codes in the worktree per the plan/task. It must not commit; the diff is the deliverable. For small tasks (no plan), its result must include user-verification steps (command + expected outcome) for Present.

5. Test — YOU run the test commands in the worktree with Bash. The exit code is the only truth; never accept a subagent's claim that tests pass. On failure, send the output tail to a coder subagent to fix; after 3 failed rounds stop and rethink rather than grinding.

6. Review (medium+) — a code-reviewer subagent reads the full diff and emits a findings table. A Fable subagent adjudicates: send the task + findings table, ask which findings are real and which are noise, with reasons. Real ones → coder fixes → re-run tests yourself. You never dismiss a finding on your own authority.

7. Acceptance (all sizes) — a Fable subagent gets the task + git diff --stat + the final test output tail: does the work match the promise? Concerns → one coder fix round → re-judge. Rejected twice → present honestly to the user as not accepted, with the judge's reasons.

8. Present — a hand-off the user can act on in under a minute, in this order:

   1. What changed — one or two plain-English sentences.
   2. Where it lives — the worktree path on its own line, plus a copy-paste command to open it (open <path> for Finder; the .xcodeproj/.xcworkspace for app builds) — or offer to build & run it for them.
   3. Test it yourself — the user-verification list from the plan (or the coder, for small tasks): copy-paste commands and what the user should see for each. Cover the behaviors most at risk, not just the happy path.
   4. Status — one line each: tests, judge verdicts (expand only a non-clean one), diff stat, any decisions made on the user's behalf.

   Then ask approve / feedback / reject and stop. Feedback routes back to step 4. Approve → invoke the ad-wrap-up skill (final tests, lint, commit, merge, task/wiki sync, cleanup). Reject → delete nothing; give the user the discard commands.

   No process narration: never quote skill rules, explain scheduling or why you stopped, or describe notification mechanics. The presentation is about the work, not the run.

Waiting on subagents

Result notifications can arrive tagged with the wrong task ID (e.g., a judge's verdict labeled with the reviewer's ID). Don't let a mislabeled envelope stall the run:

• Identify a returned result by its content, not its label. If what arrived answers the question you dispatched (a verdict, a findings table, a plan), treat it as that subagent's output even when the envelope names a different task. This is about attributing results correctly — it never licenses you to skip the judge.
• Never conclude a subagent is "still running" from silence. Before waiting any further, check its actual status (TaskList / TaskOutput). A "No task found" error means it already finished — its result was delivered earlier, possibly mislabeled; match it against what you've received instead of waiting.
• Cap every wait. A one-shot judge returns in a few minutes; if it has been longer than that, status-check immediately rather than continuing to wait.

Escalation

Answer for yourself only what the plan or brief states explicitly, and disclose it at presentation. Everything else that blocks progress — product decisions, scope changes, destructive actions, ambiguity the plan doesn't settle — goes to the user.

Under /loop

For long runs with the user away: continue phase by phase across wakeups, leaving a one-line status each turn. If blocked on a user question, park the run safely (worktree and notes preserved), state plainly what is pending, and stop scheduling wakeups until the user returns. If the run is parked at Present, the presentation itself is the status — add at most one line noting the run is parked.

Hard rules

• Never edit outside the worktree. Never commit or merge during the run — that happens only in ad-wrap-up, only after the user approves.
• Never weaken, skip, or delete tests to make them pass — fix the code.
• The driver never overrides a judge verdict; disagreement goes to the user.
• No failure path deletes the worktree or the run notes.
• Report outcomes faithfully: failing tests are failing; an unaccepted run is presented as unaccepted.