// This skill should be activated when a task involves significant complexity — multiple components, cross-cutting concerns, unfamiliar codebases, architectural decisions, or multi-step implementations. It suggests the BRAINS workflow to the user without auto-invoking it.
| name | suggest |
| description | This skill should be activated when a task involves significant complexity — multiple components, cross-cutting concerns, unfamiliar codebases, architectural decisions, or multi-step implementations. It suggests the BRAINS workflow to the user without auto-invoking it. |
| user-invocable | false |
Assess incoming tasks for complexity signals and suggest the BRAINS workflow when warranted. Never auto-invoke BRAINS — only recommend it to the user and let them decide.
Flag the task as BRAINS-worthy when two or more of these signals are present:
When complexity warrants BRAINS, present a brief, non-intrusive suggestion:
This looks like it could benefit from a structured approach. The BRAINS workflow
can help with [specific complexity identified — e.g., "exploring the design space
before committing to an architecture" or "ensuring the security implications are
covered"].
/brains:brains <topic>
This starts phase 1 (interactive research + questionnaire + ADR). On ADR
approval it chains into /brains:map (phase 2: plan + beads tasks), and then
/brains:implement (phase 3: teammate-executed implementation with per-phase
nurture and secure review).
Or just proceed directly if you prefer.
Tailor the suggestion to the specific complexity detected. Do not use generic language — name the specific signals observed.
/brains:document, the abbreviated doc-only fast path, instead of the full pipeline. It applies to changes within the eligibility ceiling (≤ 4 target documents, no code files); see /brains:document for the exact spine. Suggest it advisorily; do not auto-invoke.Never auto-invoke any BRAINS skill. The user decides whether to use the workflow. The suggestion is advisory only.
This skill should be used when the user asks to "run the brains pipeline", "start the brains workflow", "plan and implement from scratch", "do an ADR", "start with brainstorming", or invokes "/brains:brains". Phase 1 of the BRAINS pipeline: interactive research, question generation, questionnaire, architecture synthesis, and ADR production. Supports --single, --parallel (default), and --debate modes, and an optional --autopilot flag that auto-chains into hands-off map + implement. Chains into /brains:map at the user gate.
This skill should be used when the user asks to "document mode", "edit only docs", "just update the docs", "fast-path a doc change", or invokes "/brains:document". Canonical entry point for BRAINS document mode: an abbreviated spine for document-only changes that skips planning, teammate orchestration, nurture, and secure. Runs an eligibility gate, lightweight research, the full 2-4 question questionnaire, a slim ADR, inline document edits, direct star-chamber council review (replacing nurture+secure), and an inline commit. Supports --single, --parallel (default), and --debate modes for the review phase, plus --autopilot and --lean.
This skill should be used when the user asks to "set up brains", "configure brains", "install brains dependencies", "set up multi-LLM", "configure star-chamber for brains", "change brains defaults", "set up kroki", "enable diagram rendering", or invokes "/brains:setup". Guides the user through installing dependencies, configuring LLM providers, setting default modes for each BRAINS skill, and optionally starting a local Kroki container for diagram rendering.
This skill should be used when the user asks to "nurture", "review and fix", "improve code quality", "add tests", "fix remaining bugs", "polish the implementation", "check for completeness", or invokes "/brains:nurture". Reviews implementation for completeness, then fixes issues including bugs, missing features, and lack of tests. Supports --single (default), --parallel, and --debate modes for the review phase. When invoked by a phase-3 teammate with --scope phase-N, scopes the review to changes in that plan-phase, commits code and updates .gitignore, reflects any half-complete state in docs, and files follow-up beads tasks for the next phase or cleanup.
This skill should be used when the user asks to "implement the plan", "execute the plan", "start implementation", "build the tasks", "run the teammates", or invokes "/brains:implement". Phase 3 of the BRAINS pipeline: spawns a teammate Claude Code instance per plan-phase via agent-teams (preferred) or tmux (fallback), waits on beads state, handles task failures with two-strike-plus-human-in-loop flow. Supports --single, --parallel (default), and --debate modes for nurture/secure review within each plan-phase, plus an optional --autopilot flag that runs hands-off across phases until a needs-human ticket or direct user intervention stops it. Also supports --resume to pick up after a pause.
This skill should be used when the user asks to "map out the plan", "create the implementation plan", "outline the tasks", "plan it out", "sketch the implementation", or invokes "/brains:map". Phase 2 of the BRAINS pipeline: high-level plan generation (no implementation specifics), topic-slug derivation, optional branch creation, beads task creation with brains:-prefixed labels, and user approval gate. Supports --single, --parallel (default), and --debate modes for plan review, plus an optional --autopilot flag that skips user gates and auto-chains into /brains:implement --autopilot. Chains into /brains:implement at the user gate.
