菜单
Audit a repository's state and condense scattered notes into a phased ROADMAP.md. Invoke explicitly.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
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.
Work a multi-phase plan to completion with subagents, checkpoint commits, and questions back to the user. Invoke explicitly with a plan document.
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.
| name | audit-project |
| description | Audit a repository's state and condense scattered notes into a phased ROADMAP.md. Invoke explicitly. |
| argument-hint | [optional focus, e.g. 'test quality' or 'duplication'] |
| disable-model-invocation | true |
Take stock of a repo and turn whatever notes are lying around into a plan that
/orchestrate can execute. Optional focus: $ARGUMENTS.
This is read-and-write-one-file work. Do not start implementing.
Fan out with subagents; these are independent and each one would otherwise flood the conversation.
docs/ drafts, notes/, ADRs
without a decision, stale plan files under docs/**/plans/, commented-out code.Weigh candidates on what the user actually optimizes for: KISS, UX and DX, performance where it is measurable, and removing things over adding them. A phase that deletes code is worth as much as one that adds a feature.
Separate what is genuinely broken from what is merely unfinished, and both from what was abandoned on purpose. Say when something looks abandoned rather than assuming it is a gap.
Write to the repo root. Problem first, then what was considered, then the phased plan — lead the reader to the conclusion.
Phases are ordered by dependency, then by value. Each phase gets a one-line goal, the concrete work items, and how to tell it is done. Keep it reaction-sized; a roadmap nobody reads is worse than none.
Note explicitly what you decided to leave out and why.
Use AskUserQuestion on what the audit surfaced and the user has to decide: which phases matter, anything that looks abandoned and might just be deleted, and any fork you found where the repo could go two ways.
Do not commit. Do not begin implementing. Hand back the roadmap and the questions.