Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Seed a freshly-scaffolded brain with real project knowledge — on an existing (brownfield) project read the code, docs, and git log to draft the six root pages and capture key historical decisions; on a near-empty (greenfield) project interview the user. Every write goes through the `brain` CLI. Run it after brain-setup.
.claude/skills/mindmuxai-brain-bootstrap/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-11 | ✗→✓ | ▲ Improved | 10% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 58% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 25% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 25% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 19% | 0% |
brain-setup scaffolds an empty brain — six root-page templates plus an empty pages/. This skill fills it with real, durable project knowledge for the first time. It is the bridge between "a brain exists" and "the brain is worth reading".
You gather information by reasoning over the project itself — reading code, docs, and git log, or interviewing the user — but you never write the brain by hand. Every landing of knowledge is a brain CLI subcommand.
> NEVER hand-edit any file under the brain directory. All reads and writes MUST go through the brain CLI. Manual edits are unsupported and illegitimate. There is no validator and nothing at the file layer can catch a bad manual edit; correctness is guaranteed only by going through the CLI, so a hand edit silently breaks the brain's invariants.
The exact command surface (update-root / create-page / update-truth / reindex / ls …) and the page-category taxonomy live in the brain-page skill — read it before creating or modifying any page. Resolve <brain-page-bundle> to wherever that skill is installed (in the brain.md source repo, skills/brain-page/); define the shell function brain() { node <brain-page-bundle>/bin/brain.mjs "$@"; } (a function is portable across bash and zsh, unlike BRAIN="node …"; $BRAIN …, which only word-splits in bash) and run everything from the project root.
Inspect the project to decide which path you are on:
git log history. There is something to read; go to Brownfield.When it is genuinely mixed (a little code, a little history), prefer Brownfield for whatever can be inferred, and fall back to interview questions for the parts the code can't tell you.
Gather from three sources, then synthesize (do not transcribe):
package.json, pyproject.toml, go.mod, Cargo.toml, …). This is your strongest evidence for architecture and stack.README, docs/, CONTRIBUTING, design notes. Good for stated intent, goals, and naming.git log — read the commit messages (git log --oneline -n 200 and spot-read full messages for the interesting ones). Mine them for the real decisions that were made over time.Write each with echo "<body>" | brain update-root <slug> (body on stdin). Lean on mermaid blocks (graph / sequenceDiagram / mindmap / gantt) to keep them visual.
architecture — layers, modules, boundaries, a mermaid graph. Inferable from code — write it with confidence.stack — domain / choice / rationale table from the dependencies and how they're used. Inferable from code.flow — the end-to-end path of a typical request/operation, a mermaid sequenceDiagram. Inferable where the entry points and call paths are clear.mindmap — main feature branches from the project root, a mermaid mindmap. Inferable from the module/feature layout.background — why the project exists / goals / non-goals / target users. Often NOT inferable from code — see the guardrails.roadmap — milestones, a mermaid gantt. Usually NOT inferable from code — see the guardrails.For each genuine decision you can see in the history or the code (e.g. "switched from X to Y", "adopted pattern Z", a deliberate constraint), create a decision page and fill in its understanding:
brain create-page --id <kebab-id> --category decision --title "<one-line decision>" --source "git log / code"
echo "<what was decided, the alternatives, the rationale, the blast radius>" | \
brain update-truth --id <kebab-id> --summary "captured from project history" --source "git log"Link related pages and the relevant root area with [[page-id]].
git log → real decisions only. Distill the commits that represent actual choices or turning points. Do not produce a commit-by-commit changelog; routine "fix typo / bump dep" commits are noise.architecture and stack can be inferred from code and dependencies. background and roadmap usually cannot — for anything you can't ground in evidence, mark it low-confidence and ask the user to confirm, or leave it as an explicit open question. Never fabricate goals, history, or plans.There is nothing to read, so switch to an interview. Ask open-ended questions and let the answers drive what you seed. Cover at least:
From the answers:
background (goal / target users / non-goals) with update-root background — this is the primary greenfield deliverable.stack and/or roadmap as early sketches with update-root. Mark them as provisional. Leave the others as their templates until there's something real to say — don't invent architecture/flow/mindmap for code that doesn't exist yet. brain reindex brain list-pages
brain CLI — never hand-edit a brain file. From here, ongoing knowledge capture flows through the brain-page and brain-ingest skills.Write the body of root pages, compiled_truth, and timelines in the user's working language; keep technical identifiers (ids, slugs, field names, paths) verbatim.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 9,071 | 10,526 | +16% | 1 | 1 | 0% | 1,584 | 1,894 | +20% | 0 | 0 | — |
case-02 | fail→fail | 7,639 | 12,237 | +60% | 1 | 1 | 0% | 1,356 | 2,215 | +63% | 0 | 0 | — |
case-03 | fail→fail | 10,127 | 10,448 | +3% | 1 | 1 | 0% | 240 | 1,935 | +706% | 0 | 0 | — |
case-10 | pass→pass | 27,082 | 12,100 | -55% | 1 | 1 | 0% | 3,079 | 2,986 | -3% | 0 | 0 | — |
case-11 | fail→pass | 12,857 | 9,382 | -27% | 1 | 1 | 0% | 2,108 | 2,314 | +10% | 0 | 0 | — |
case-23 | fail→fail | 17,594 | 21,558 | +23% | 1 | 1 | 0% | 2,640 | 4,760 | +80% | 0 | 0 | — |
case-22 | fail→fail | 15,574 | 31,351 | +101% | 1 | 1 | 0% | 2,186 | 4,872 | +123% | 0 | 0 | — |
case-09 | pass→pass | 22,067 | 14,930 | -32% | 1 | 1 | 0% | 2,618 | 3,389 | +29% | 0 | 0 | — |
case-04 | pass→pass | 14,512 | 11,381 | -22% | 1 | 1 | 0% | 2,618 | 2,776 | +6% | 0 | 0 | — |
case-05 | fail→pass | 10,343 | 5,808 | -44% | 1 | 1 | 0% | 1,623 | 2,571 | +58% | 0 | 0 | — |
case-06 | fail→pass | 15,030 | 8,057 | -46% | 1 | 1 | 0% | 1,692 | 2,120 | +25% | 0 | 0 | — |
case-07 | fail→pass | 16,526 | 11,537 | -30% | 1 | 1 | 0% | 2,216 | 2,771 | +25% | 0 | 0 | — |
case-08 | fail→pass | 15,317 | 4,437 | -71% | 1 | 1 | 0% | 2,132 | 2,528 | +19% | 0 | 0 | — |
case-12 | fail→pass | 16,286 | 9,495 | -42% | 1 | 1 | 0% | 2,047 | 2,316 | +13% | 0 | 0 | — |
case-13 | fail→pass | 22,931 | 3,958 | -83% | 1 | 1 | 0% | 2,579 | 2,423 | -6% | 0 | 0 | — |
case-14 | fail→pass | 14,490 | 3,673 | -75% | 1 | 1 | 0% | 1,697 | 2,338 | +38% | 0 | 0 | — |
case-15 | pass→pass | 12,779 | 9,240 | -28% | 1 | 1 | 0% | 1,157 | 2,257 | +95% | 0 | 0 | — |
case-16 | pass→pass | 14,529 | 9,284 | -36% | 1 | 1 | 0% | 2,093 | 2,410 | +15% | 0 | 0 | — |
case-17 | pass→pass | 16,631 | 8,394 | -50% | 1 | 1 | 0% | 1,974 | 2,075 | +5% | 0 | 0 | — |
case-18 | fail→fail | 11,513 | 10,319 | -10% | 1 | 1 | 0% | 1,916 | 2,326 | +21% | 0 | 0 | — |
case-19 | fail→fail | 12,556 | 5,993 | -52% | 1 | 1 | 0% | 2,078 | 2,655 | +28% | 0 | 0 | — |
case-20 | fail→pass | 17,115 | 7,691 | -55% | 1 | 1 | 0% | 1,674 | 3,063 | +83% | 0 | 0 | — |
case-21 | fail→fail | 3,091 | 15,895 | +414% | 1 | 1 | 0% | 538 | 3,561 | +562% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 23 cases were attempted, and 21 counted toward the lift figure. The other 2 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +39 percentage points is the difference between those two pass rates over the 21 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.