菜单
Assess the blast radius of a change and review a diff — what it touches, what could break, which tests to run, and the prior decisions behind it. Use before a refactor, rename, or signature change, and when reviewing a pull request or your own uncommitted diff.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Rebuild a flow-first project wiki using the mimirs wiki MCP tool. Use when the user asks to generate, rebuild, refresh, or write the wiki for a codebase.
Build an accurate mental model of an unfamiliar codebase, feature, or area before changing it — where it lives, how it connects, what it does, and why. Use when asked how something works, where something is, when onboarding to a repo, or before editing code you don't know. For a cross-cutting question that needs answering from many sources, use research instead.
Wrap up a work session so the next session (or another agent) can pick up cleanly — what was done, what's in flight, what to watch out for. Use when ending a session, switching tasks, or asked to hand off, wrap up, or save state for later.
Design an implementation plan before writing code — where the change lands, what it will touch, what could break, and the steps in order. Use when asked to plan a feature, scope a change, or figure out how to approach an edit before making it. To assess a change that already exists (a diff, refactor, or rename), use review instead.
Answer "why" and "when" questions about a project's decisions — the intent behind a past choice, when it was made, what was tried before and rejected. Use when asked why something was decided, what the rationale was, or before reversing or redoing earlier work. For why the code mechanically behaves a certain way use research; for why it breaks use debug.
Answer a hard, open-ended question about how the project works or is built by synthesizing every source — code, structure, git history, prior decisions, discussion, caveats — and verifying each claim against the source. Use for deep cross-cutting questions that span more than one area. Narrower siblings — a single area's structure is explore, the rationale behind one past decision is recall, a failure's root cause is debug.
| name | review |
| description | Assess the blast radius of a change and review a diff — what it touches, what could break, which tests to run, and the prior decisions behind it. Use before a refactor, rename, or signature change, and when reviewing a pull request or your own uncommitted diff. |
Goal: know the full impact before and after changing code — no surprise breakage.
git_context(include_diff: true) for the modified files and the diff.impact <symbol> (transitive callers as a pruned tree + the tests to run). Widen with usages <symbol> (every call site) and dependents <file> (file-level importers). Pass file to impact to disambiguate a name defined in several places.affected for the changed set (CLI: git diff --name-only | mimirs affected --stdin). Run those before claiming the change is done.get_annotations on the touched files: fragile code, constraints, "don't refactor until X".search_checkpoints "<area>" (prior decisions) and search_commits "<area>" (why it changed before), so you don't undo a deliberate choice.impact / affected; annotate any new caveat you introduce; create_checkpoint the decision and what changed.Finish: a risk summary — callers affected, tests to run, caveats, prior decisions — each with a file:line citation.