菜单
Find what's underdocumented or hard to retrieve in a project — the topics people search for but don't find. Use when improving docs or the wiki, or when asked what's missing or poorly covered.
用 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 | doc-gaps |
| description | Find what's underdocumented or hard to retrieve in a project — the topics people search for but don't find. Use when improving docs or the wiki, or when asked what's missing or poorly covered. |
Goal: surface where the index (and likely the docs) fail to answer real queries.
search_analytics for queries that returned no results or only low-relevance hits; these are topics people look for but the codebase/docs don't surface well.search / read_relevant on the weak query yourself: is the content genuinely missing, or just poorly named / undocumented?write_relevant "<topic>" for the best insertion point for new docs or a doc-comment.Finish: a prioritized list — the query, whether content is missing vs. undiscoverable, and the suggested place to document it (file:line).