brainerd-init
Brainerd Init
Initialize Brainerd in the current repo and route to the correct harness-specific setup path.
Detect the harness first
- If the active session exposes Pi Brainerd tools, or you are in Pi, use the guarded
/brainerd-initcommand surface. Do not use the shell wrappers in that branch. - If
CODEX_THREAD_IDis present, use the Codex wrapper:
./scripts/brainerd-codex.sh init
- If
BRAINERD_CLAUDE_SESSION_IDorBRAINERD_CLAUDE_TRANSCRIPT_PATHis present, use the Claude wrapper:
./scripts/brainerd-claude.sh init
- If none of those signals match, stop and report that harness detection failed. Do not guess.
Workflow
- Run the matching init path for the detected harness.
- Review the bootstrap preview before writing it.
- Apply the optional bootstrap note only when the user explicitly wants it.
- Keep edits limited to
brain/and the managed Brainerd block inAGENTS.md. - On the Claude branch, keep
CLAUDE.mdas a thin shim and preserve Claude imports underbrain/imports/claude/.
Guardrails
- Do not edit arbitrary repo files outside
brain/and the managed Brainerd block inAGENTS.md. - Stop if the managed Brainerd block is duplicated or malformed.
- End with a short summary of what was created and whether bootstrap was previewed or applied.
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.
10brainerd
>
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
>-
6