Menu
Trace a bug, error, or regression to its root cause. Use when investigating a failure, a stack trace, unexpected behavior, or "why does X happen".
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.
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.
Based on SOC occupation classification
| name | debug |
| description | Trace a bug, error, or regression to its root cause. Use when investigating a failure, a stack trace, unexpected behavior, or "why does X happen". |
Goal: find the cause, not just the symptom.
search "<error text / behavior>"; if you have a name, search_symbols <name> (exact lookup). read_relevant the suspect code.trace from:<entrypoint> to:<suspect> to see how execution reaches the failure (shortest path is highlighted; a dynamic-dispatch hop ends a chain and is reported as such). usages <symbol> for who calls the suspect.get_annotations (search across notes) — the bug may already be flagged as a caveat.file_history <file> and search_commits "<symptom/area>" to find the change that likely caused it; git_context for recent uncommitted edits.search_conversation "<symptom>" — was this hit or discussed before?annotate the root cause on the file and create_checkpoint what was wrong and how it was resolved.Finish: state the root cause (file:line), the path from trigger to failure, and the fix.