Menu
Leave the current worktree and clean it up. Use when the work in a worktree is merged or abandoned and the session should return to the original directory.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Prove whether a skill-pack change made agents better at writing code. Use when a single passing eval doesn't prove anything and you need multi-run pass@k evidence, when grading coding tasks with hidden tests the agent cannot see, or when comparing outcomes across skill-set versions.
Create design documents (WHICH/WHERE) for approved specs. A design is a max-200-line architectural sketch — components, interfaces, data flow, and key decisions with trade-offs — that gives reviewers a high-leverage point to redirect architecture before the full plan is written. Design is approved when `wiki/STATUS.md` shows the spec row at `design approved` — written there by a human signal that `kata-dispatch` or the active agent propagates.
Write implementation plans (HOW/WHEN) for approved designs. Translate an approved design into concrete steps, file changes, sequencing, and risks for a trusted agent to execute. Plan is approved when `wiki/STATUS.md` shows the spec row at `plan approved` — `staff-engineer` writes this row after a clean panel review (plans may be approved by agents).
Grade a single artifact (spec, design, plan, or implementation diff) against quality criteria and return findings by severity. Use when another skill spawns a fresh sub-agent for an independent review of its work. This skill never spawns sub-agents — it produces findings only — which structurally prevents the spec/design/plan/implement review loop from recursing.
Write specifications (WHAT/WHY) for features, changes, and improvements. Spec is approved when `wiki/STATUS.md` shows the spec row at `spec approved` — written there by a human signal (label, comment, APPROVED review, or in-session message) that `kata-dispatch` or the active agent propagates. Use when proposing changes, capturing findings as actionable specs, or evaluating spec quality. Pair with the `kata-plan` skill for the HOW side.
Merge gate for open pull requests. Verify contributor trust, classify PR type, rebase on main, fix mechanical CI failures, gate on `wiki/STATUS.md` approval state, and merge passing PRs. Sole external merge point.
| name | leave-it |
| description | Leave the current worktree and clean it up. Use when the work in a worktree is merged or abandoned and the session should return to the original directory. |
Exit the current worktree session and remove it.
git status --short — confirm the working tree is clean.MERGED, or the change is on origin/main.ExitWorktree with action: "remove" and discard_changes: true.
Steps 1–2 are the real safety check: a squash merge always leaves the
pre-squash commits behind on the branch, and the tool may be unable to
verify worktree state at all, so a plain remove refuses even when
everything has landed. If step 1 or 2 fails, stop and confirm with the
user, or preserve the worktree with action: "keep".