mimirs

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.

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.

Get oriented on a project's current state when starting or resuming work — what's changed, what's in flight, and the recent decisions. Use at the start of a session, when returning to a repo after a break, or when asked "where were we" or "what's the status".

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".

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.

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.