Menu
Work a multi-phase plan to completion with subagents, checkpoint commits, and questions back to the user. Invoke explicitly with a plan document.
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
Capture and persist browser screenshots or GIFs for visual review of a web UI. Use when verifying a UI change visually, reviewing a page's design or layout, recording a multi-step interaction (dropdown, hover, form flow), toggling dark mode for a comparison shot, or when a screenshot needs to be written to disk rather than only shown inline.
Run and troubleshoot copier updates in a project generated from one of the user's templates, and maintain the templates themselves. Use when a task mentions copier, copier update, .copier-answers.yml, .rej files after an update, ctt or copier-template-tester, or one of calcipy_template, mdformat-plugin-template, my_go_template, or app-template.
Audit or write an hk.pkl config (jdx/hk git hooks). Use when creating hk.pkl, upgrading the pinned hk version, adding a linter step, or when fixes made by a pre-commit hook are not being staged. Covers version pinning, staging semantics, builtins, and DRY structure.
Query PostHog error tracking and Sentry issues from the command line. Use when asked what errors are happening, which errors are being missed or untriaged, for production error rates or impact by user, or whenever posthog-cli or sentry-cli is mentioned.
Async Python conventions and footguns — asyncio.TaskGroup over gather, event-loop-bound primitives, offloading blocking work to threads or processes, cancellation across the thread boundary, and dedicated executors. Use when writing or reviewing async def, await, asyncio.to_thread, run_in_executor, create_task, async generators, or when diagnosing a stalled event loop, a "bound to a different event loop" error, or latency that only appears under load.
The user's full writing system for prose they author — README and docs text, landing copy, PR and commit descriptions, Linear proposals, design docs, Slack and email messages. Use when drafting or rewriting any human-facing prose, when a draft reads like AI wrote it, when stripping AI slop from documentation, or when relaying research output into a human-facing surface. CLAUDE.md carries the compressed rules; this carries the reasoning, the before/after pairs, and the per-format shapes.
| name | orchestrate |
| description | Work a multi-phase plan to completion with subagents, checkpoint commits, and questions back to the user. Invoke explicitly with a plan document. |
| argument-hint | [@plan-file or phase description] |
| disable-model-invocation | true |
Target: $ARGUMENTS — a plan file (ROADMAP.md, docs/**/plans/*.md), a phase
name, or nothing, in which case find the plan before doing anything else.
This is the standing contract for a long run. It replaces the composite instruction the user would otherwise retype: coordinate subagents, work through each phase in order, commit at checkpoints, and ask rather than guess.
Read the plan, then use AskUserQuestion once to settle anything that would change the work. Do this before the first edit, not after phase one.
Ask about: which phases are in scope for this run, any that are already done or obsolete, a genuine fork in approach the plan leaves open, and whether committing on their behalf is wanted here. Do not ask what you can determine by reading the repo, and do not ask permission to begin.
If the plan is clear and the phases are unambiguous, say what you are about to do in two lines and start. A blocking question with nothing delivered is the failure mode to avoid.
mise run ..., hk check, uv run pytest), never invented ones.Ask through AskUserQuestion, mid-run, when a choice is genuinely the user's: a real fork in design with different consequences, a phase whose premise turned out wrong, or scope that has grown well past what the plan described.
Do everything that does not depend on the answer first, then ask. Do not batch every uncertainty into one interrogation at the end, and do not stall the whole run on a question you could resolve by reading code.
Clean up: no leftover scratch files in the repo, no commented-out code, no half-finished branches of the plan left ambiguous.
Report in plain sentences — what changed, what failed, what comes next. Lead with the lines that change the user's next action. If a phase was skipped or blocked, say so explicitly and why; scaling the work down is the user's call, not yours.