Menu
Compact the current conversation into a handoff document for another agent to pick up.
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
Drive a goal to a merge-ready endpoint by orchestrating the offload architect loop: run contextual plan reviews, dispatch a configured builder harness slice-by-slice, wait for each slice via a backgrounded bridge (no Claude-side polling), judge raw gates plus an independent `review` pass per slice, and run a final integration `review`. STOPS at the edge of merge by default and hands to the human — only merges when the goal text explicitly authorizes it. You stay the ARCHITECT and never write implementation code. Use when the user says "complete", "drive this to done", "take this to merge-ready", "run the whole loop", or invokes /complete.
Make this Claude session the ARCHITECT and offload implementation to a configured builder harness (codex, claude, opencode, pi, grok, or a custom command) you can watch. Reads the session handoff, arbitrates the builder's disagreements, judges raw gate results against frozen criteria plus an independent `review` pass on each slice, specs the next one-PR slice, and emits + dispatches a builder block. The architect never writes implementation code. Use when the user says "offload", "hand this to codex", "hand this to a builder", "architect mode", "have codex build this", or invokes /offload.
Systematic debugging with root cause investigation. Phases: context detection, investigate, analyze, hypothesize, implement, verify. Iron Law: no fixes without root cause. Supports quick-pass for obvious bugs and full investigation for mysteries. Evidence log tracks what's been checked and ruled out. Use when asked to "debug this", "fix this bug", "why is this broken", "investigate this error", or "root cause analysis". Proactively suggest when the user reports errors, unexpected behavior, or is troubleshooting why something stopped working.
Deep plan review with four modes: SCOPE EXPANSION (dream big), SELECTIVE EXPANSION (hold scope + cherry-pick expansions), HOLD SCOPE (maximum rigor), SCOPE REDUCTION (strip to essentials). Supports Standard (per-section) and Batched (grouped) pacing. Detects review context (git/PR, plan document, or hybrid). Challenges premises, maps failure modes and concurrency risks, reviews architecture/security/performance/cost/deployment, evaluates API contracts, and produces structured outputs with error registries, diagrams, and a go/no-go readiness verdict.
Designer's eye plan review — interactive, like the deep and eng reviews. Rates each design dimension 0-10, explains what would make it a 10, then fixes the plan to get there. Covers information architecture, interaction states, motion/micro-interactions, user journey, AI slop risk, content/copy quality, design system alignment, responsive/a11y, perceived performance, theming, and unresolved decisions. Supports Standard (per-pass) and Quick-pass (grouped) pacing. Detects review context (git/PR, plan document, or hybrid). Produces a go/no-go design readiness verdict. Works in plan mode. For live site visual audits, use /design-review. Use when asked to "review the design plan" or "design critique". Proactively suggest when the user has a plan with UI/UX components that should be reviewed before implementation.
Developer experience plan review for developer-facing products (APIs, CLIs, SDKs, libraries, platforms, docs). Investigates developer personas, benchmarks against competitors, designs magical moments, traces friction points, then scores 8 DX dimensions 0-10. Three modes: DX EXPANSION (competitive advantage), DX POLISH (bulletproof every touchpoint), DX TRIAGE (critical gaps only). Use when asked to "DX review", "developer experience audit", "devex review", or "API design review". Proactively suggest when the user has a plan for a developer-facing product.
| name | handoff |
| description | Compact the current conversation into a handoff document for another agent to pick up. |
| argument-hint | What will the next session be used for? |
| model | sonnet |
| effort | low |
Write a handoff document summarising the current conversation so a fresh agent can continue the work. Create the target path with f=$(mktemp -t handoff) && mv "$f" "$f.md" && echo "$f.md" so it ends in .md on both macOS and Linux (read the file before you write to it).
If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.
The handoff is read by another agent, so its shape is fixed. Produce exactly these eight sections, in this order, with these headings verbatim. Lead with intent and next steps, not narrative history — a fresh agent should scan top to bottom and start working.
# Handoff: <short title> — one line naming the work.## Goal — what the next session is trying to accomplish, in 1–2 sentences. If args were passed, this reflects them.## Current state — what's done and working right now. Bullets, past tense.## Next steps — the concrete actions to take next, ordered, each an imperative ("Wire up X", "Run Y"). The most important section: make it actionable from a cold start.## Open questions / blockers — unresolved decisions, things waiting on someone, known risks.## Key context — the non-obvious things: decisions made and why, gotchas, dead ends already ruled out. Skip anything a fresh agent could read straight from the code or the linked artifacts.## Pointers — paths and URLs to the artifacts that hold the detail: PRDs, plans, ADRs, issues, branches, key files (path:line). Reference them; don't copy their contents in.## Suggested skills — which skills the next session should use, if any, and for what.None. under it rather than padding with filler or inventing items to fill space. An empty Open questions is fine; a fabricated one is not.