菜单
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.
用 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.
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.
Research the web for solutions, competitors, alternatives, or prior art for a decision facing this project — then store the findings in project memory so they survive the session. Use when choosing a library or approach, comparing tools, checking what others do, or evaluating whether to build vs adopt.
| name | handoff |
| description | 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. |
Goal: leave the project state recorded so the next session starts from catch-up, not from scratch. The end-of-session counterpart to catch-up.
git_context for the modified/uncommitted files and recent commits, so the handoff names the exact files touched this session.annotate any fragile spot, constraint, race, or workaround you discovered or introduced this session, on the file it lives in; get_annotations on the touched files to confirm earlier notes still hold (delete_annotation ones a fix made stale).create_checkpoint (type handoff) with what was done, which files changed, why, and the concrete next action. Keep the summary tight (it has a length cap). If the session was a dead end or a direction change, say so and why.Finish: a short handoff note — done / in flight / next step / open caveats — each with a file:line or checkpoint reference, so a fresh session can resume without re-deriving context.