Menu
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.
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.
Based on SOC occupation classification
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.
| name | wiki |
| description | 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. |
Use the wiki MCP tool as the source of truth. This skill is only a workflow
wrapper; do not invent a separate wiki structure.
The generation prose — discovery rules, the source-first writing contract, the
self-check, and the per-page prompts (flow, screen, overview, mechanism) — is served from
markdown, using packaged defaults unless a project overrides them. To customize
it for a project, run wiki(eject) once: it writes the defaults to
.mimirs/wiki/*.md for you to edit, and a file there overrides the packaged
default. Edit instructions in .mimirs/wiki/, never the generated wiki/ output.
The wiki is flow-first. Create one page for one concrete trigger:
Do not bundle all API endpoints into one page. Do not bundle all messages into one page. Do not create broad architecture, module, entity, glossary, or generic data-flow pages unless the human explicitly asks for those.
The sanctioned exception for shared internals is a mechanism page
(kind: "mechanism", slug mechanisms/<name>): one page per internal subsystem
that three or more flows call but that is nobody's entry point — ranking,
caching, graph traversal, or similar. Flow pages link to it instead of each
re-explaining the same internals.
If many flows share files, keep separate pages and connect them with related flows.
index_files() if the project index is empty or stale.wiki(shape).wiki/_discovery.json
(flows first, then the overview second pass, then the mechanism third pass).wiki(validate-discovery).wiki/_discovery.json and validate again.wiki(write).wiki(discovery) and split the work by page slug.wiki(write:page:<slug>).wiki/.wiki(validate-pages) and fix any broken relative .md links it reports.wiki(changelog) and follow the returned prompt: it diffs the pending wiki/ changes and has you prepend one entry to wiki/CHANGELOG.md — a curated summary of the behavior changes for an incremental update, or a single line for a full regeneration. Then commit the pages and the changelog together.When the wiki already exists and the code or instructions have changed, prefer an incremental update over a full rebuild:
index_files() if the index is stale.wiki(update). It diffs the source and instruction changes since the wiki
was last generated (never the wiki/ output) and returns the changed files plus
the page index.wiki(write:page:<slug>) for only those pages and rewrite them. Leave untouched
pages alone. If the signal says too much changed, do the full rebuild instead.wiki(validate-pages), then wiki(changelog), then commit.Each flow may include stateChanges for project items whose state changes
during the flow. Use this for concrete items such as orders, jobs, files,
index rows, cache entries, sessions, messages, or checkpoints. Record from,
to, a plain-language description, and source evidence when the code proves
the change.
Each page should have:
kind, usually matching the referenced flow kind, such as
tool, command, route, message, job, or scheduleflowIds itemroutes/post-checkout or messages/order-createdAvoid broad slugs such as api, endpoints, messages, events,
data-flows, architecture, modules, or entities.
Mechanism pages are the exception to the one-flow rule: kind is
"mechanism", the slug lives under mechanisms/, flowIds is optional and
may list several flows that use the mechanism, and primaryFiles needs only
the owning module.
When a flow depends on concrete caller-provided values or external
conditions, add an inputs array naming what the caller, environment,
schedule, message, config, or file system provides. Omit inputs when there
is no meaningful input.
When a flow has concrete outputs or visible side effects, add an outputs
array naming what the flow returns, writes, updates, starts, publishes, logs,
or otherwise changes. Omit outputs when there is no meaningful output. Do
not put request parameters, command flags, or tool arguments in outputs.
Those are inputs.
Source-first rule: discovery is a map, not page content. Do not paste
discovery summaries, file lists, or mustCover wording into a page. Reopen the
source and turn each required topic into an explanation of verified behavior:
what starts the flow, what code runs, what data moves, what state changes, what
can fail, and what the caller or user observes.
For each page:
primaryFiles, flow files, flow
evidence, and stateChanges evidence before writingsequenceDiagram with autonumberInputs section when the page has inputsOutputs section when the page has outputsState changes section when the flow has stateChangesmustCover as the list of required topics for this page; every item
must be explained in the page body from source-backed behaviorsrc/server.ts:42Key source files when several files matterBefore finishing, check every citation, named symbol, diagram step, input,
output, state change, failure case, example, and mustCover item against the
source. If a section is compact or dry, reopen the code and add the missing why,
data movement, branch, state change, or user-visible result.