brainerd
Brainerd
Brainerd keeps repo memory in one place: brain/ plus one managed block in
AGENTS.md.
Use when
- The user asks to initialize or repair a repo brain.
- The user asks to remember something durable for this repo.
- The user asks to mine older repo-scoped history for missed durable learnings.
- The user asks to apply or discard a staged rumination preview.
Do not use when
- The repo already has a
brain/and the task only needs an ambient read. Openbrain/index.mdandbrain/principles.mddirectly and continue. - The user wants todo state, secrets, or raw transcript stored.
- The user has not asked to touch repo memory at all.
One move at a time
Choose exactly one action before touching files:
initreflectruminate-previewruminate-applyruminate-discard
If the request is ambiguous between the three rumination actions, ask.
Fast path
- If
brain/index.mdandbrain/principles.mdexist, read them first. - Make the smallest durable change that solves the request.
- Edit only
brain/and the managed Brainerd block inAGENTS.md. - End every action with a visible
Brainerd summary:block, even for previews and no-ops.
Action references
init: references/init.mdreflect: references/reflect.mdruminate-*: references/ruminate.md- layout and hard rules: references/brain-layout.md, references/guardrails.md
More from mylesmcook/mcook-skills
adversarial-review
Use this skill when you need a serious code review, diff review, or implementation-plan review from independent reviewers. In Codex hosts, prefer a fresh Codex subagent for the Codex reviewer; otherwise use the Codex, Claude Code, and Gemini reviewer paths when available. Return a PASS, CONTESTED, or REJECT verdict.
13subagent-driven-development
Use after an implementation plan is approved to execute mostly independent tasks through fresh subagents with scoped context, harness-aware model routing, proportional review gates, and mandatory controller verification.
10simple-code
Reduce incidental complexity in code and design. Use when shaping APIs, module boundaries, refactors, tests, naming, and architecture tradeoffs with a bias toward concrete, local, reversible solutions.
7git-it-out
Use this skill when the user explicitly wants final end-of-session closeout and no more branch or PR limbo: proper verification, proper commits, main/mainline landing, push, repo-native merge/release/deploy/publish steps, tracker updates, Entire/checkpoint handling when configured, and a concise handoff. Reach for it on prompts like 'git it out', 'get it out', 'ship this', 'I'm done', 'I'm going to bed', 'take this off my plate', 'finish the session', or 'get this into production'. Do not use it for greenfield implementation, open-ended debugging, broad refactors, or inventing a release process from scratch.
7laws-of-taste
>-
6simplify
Refine recently changed code for clarity, consistency, and maintainability without changing behavior. Use when the user explicitly asks to simplify, clean up, or lightly refactor touched code, reduce local complexity, remove redundancy, improve naming or structure, or make recent edits easier to read while preserving outputs, interfaces, tests, security, and accessibility.
6