Full Setup
You installed the plugins. Nothing has touched your project yet — the plugins ship skills, and eleven of those skills are installers. Each one analyses this repo and writes real artifacts into it: agents, hooks, generated skills, a task board, project rules.
That is the whole meaning of the -setup suffix. A skill ending in -setup installs a mechanism you
use afterwards instead of the skill; a skill without the suffix is a recurring tool that is correct
to run over and over (/brewcode:convention, /brewtools:text-optimize, /brewdoc:publish).
One setup per session, run by hand. This is the most important line on this page.
Every -setup skill is an interactive generator. Three properties make it unsuitable for
automation, and all three hold for every one of them:
- It asks you real questions. Which domains your team should cover, which model each agent gets, whether an existing artifact is replaced or kept. Those answers cannot be guessed from the repo, which is why there is no unattended flag anywhere in this suite.
- It spawns many subagents. A single
installfans out a dozen readers across your codebase. Two setups in one session compete for the same context window: the second one’s questions get answered against the first one’s stale findings. - It creates a lot. Agents, hooks, generated skills, rules, config and state — real files in your repo, which you want to read and commit deliberately, not discover later in a diff.
So run them one at a time, each in its own fresh session, and always by typing the command
yourself. Batching is not faster; it produces worse artifacts that you then have to upgrade by
hand.
This is also why all 28 skills in the suite carry user-invocable: true and
disable-model-invocation: true. The model never sees their descriptions and can never reach for
one on its own — a setup runs only when you type /plugin:skill.
Start here: the dashboard
/brewcode:setup-status is read-only. It probes this project for the anchor artifact of every setup and prints the exact command for the rows that need one.
/brewcode:setup-statusIt writes nothing, spawns nothing, and has no --run mode by design — see the warning above. Treat it
as the entry point: run it first, then work the list it hands you, top to bottom, one per session.
Filter it to one plugin or one row when you only care about a slice:
/brewcode:setup-status brewtools
/brewcode:setup-status semble-setupSix verdicts, and the order between them matters:
| Verdict | Meaning |
|---|---|
n/a | the plugin that owns this row is not installed. Never missing |
disabled | you turned it off on purpose. All eleven setups leave a probeable off-switch — a live config flag or an entry-file rename — see below |
missing | anchor and every secondary absent, in both the live and .disabled spelling |
partial | anchor missing but some secondary present (or the reverse), a toggle left half-applied, an unresolved {PLUGIN_VERSION} placeholder, or the wrong skill’s generated_by wrote the file |
stale | all present, but a version signal disagrees, or an absence signal fires (a team without trace-ops.sh, a board without the task-spec skill), or semble’s wiring signal fires. A version or byte signal takes one of four qualifiers: (X -> Y) — the stamp is behind or ahead of the plugin, (legacy stamp) — a retired stamp spelling survives, (legacy, unstamped) — no stamp in any carrier, (bytes drifted) — the stamp matches but a cmp pair differs. An absence signal or semble’s wiring signal prints a bare stale and names the missing artifact in the Found column |
installed | anchor and every secondary present, version stamp matches the plugin, every cmp pair agrees |
installed (version unknown) is retired: every anchor in the roster now carries a real version stamp,
including teams-setup and task-board-setup, which used to ship unstamped. What remains as an edge
case, not a seventh state, is version unknown (plugin asset missing) — the plugin cache is missing
the asset a cmp needs to compare against, so the byte check could not run at all. That is never
reported as stale.
disabled outranks missing, partial and stale, and that ordering is the point. Five setups
disable by parking the anchor file itself — superreview-setup disable renames SKILL.md away, so
checking presence first would report missing (“never installed”) for something the user turned off
on purpose. think-short-setup disable renames its prompt file away, so the secondary legitimately
goes missing; calling that partial would send you to re-install a mechanism that is working exactly
as you configured it. Equally, a disabled row is never reported as installed — the files are there
but the mechanism is inert, so the row’s command column offers enable.
All eleven setups leave a probeable off-switch, under exactly two mechanisms: a live config flag
(semble, agent-deadline, agent-return, agent-router, manager, docsync — the reader
re-checks the key on every invocation) or entry-file parking (teams, superreview,
task-board, think-short, memory-sync — the one filename discovery keys on is renamed
<name>.disabled and back, body byte-identical, nothing deleted).
The eleven setups
| Skill | Plugin | What it installs |
|---|---|---|
teams-setup | brewcode | .claude/teams/*/team.md plus 5-20 project agents in .claude/agents/*.md, and .claude/agents/intent-guard.md |
semble-setup | brewcode | the semble_code MCP server (user scope), .claude/rules/semble-first.md, five hook files in .claude/hooks/ (semble-session, semble-prefetch, semble-stats, semble-reminder, semble-subagent) wired as six settings.json entries (SessionStart, UserPromptSubmit, PostToolUse, PostToolUseFailure, PreToolUse on Bash|Grep, and an unmatched SubagentStart, each timeout: 5 seconds), the .claude/semble/ directory (state.json; the hooks later add reminder.json and telemetry.jsonl there at runtime — .gitignore gets the whole directory), the repo-root .sembleignore, and the <!-- BEGIN brewcode:semble --> managed block in CLAUDE.md |
superreview-setup | brewcode | a project /superreview skill at .claude/skills/superreview/ with its references/ and a .template-baseline/ copy, plus .claude/agents/intent-guard.md |
task-board-setup | brewtools | .claude/features/board.md and the board tree, .claude/agents/task-tracker.md, the task-board and task-spec skills under .claude/skills/, .claude/rules/tasks.md, .claude/features/PROGRESS.md |
think-short-setup | brewtools | terse-mode hooks in .claude/hooks/ (or ~/.claude/hooks/ for global scope): think-short-session, think-short-prompt-counter, think-short-subagent, think-short-prompt.md |
agent-deadline-setup | brewtools | .claude/hooks/agent-deadline-guard.mjs + agent-deadline-cleanup.mjs, budget config at .claude/agent-deadline.json |
agent-return-setup | brewtools | .claude/hooks/agent-return-contract.mjs + agent-return-guard.mjs + agent-return-budget.mjs, threshold config at .claude/agent-return.json |
agent-router-setup | brewtools | .claude/hooks/agent-router.mjs, config at .claude/brewtools/agent-router.json |
manager-setup | brewtools | the hard-wall guard .claude/brewtools/manager/hardmode-guard.mjs, its state.json, and a PreToolUse registration in .claude/settings.local.json. The ++m / ++a / ++rr / ++r codeword layer is a plugin hook and needs no install |
memory-sync-setup | brewdoc | a project /memory-sync skill at .claude/skills/memory-sync/ with references/memory-guide.md, agent-audit.md, hard-sync.md |
docsync-setup | brewdoc | doc-staleness hooks docsync-track.mjs, docsync-watch.mjs, docsync-gate.mjs in .claude/hooks/, plus .claude/docsync/config.json and state.json |
Scope
All eleven write into the project, not your home directory — with three deliberate exceptions.
think-short-setup, agent-deadline-setup and agent-return-setup accept a global argument
that installs into ~/.claude/ instead. semble-setup registers its MCP server at user scope and
may ask to run a machine-level brew install for uv, which is exactly why it never installs
without being asked.
Recommended order
The order below is derived from what reads what. Every setup after the first inventories artifacts the earlier ones produced, so running them backwards means the later analysis sees an empty project.
- semble-setupfirst
Semantic code search over the whole repo. Every setup that follows fans out subagents to read your codebase, and they all get faster and more accurate once semantic search is wired. It is also the only one that may touch the machine, so get its question out of the way first.
/brewcode:semble-setup installBare
/brewcode:semble-setupreports status and installs nothing — the wordinstallis what consents to the machine-level step. - teams-setup
Produces the agent roster in
.claude/agents/. Three later setups read that roster:task-board-setupinventories it to build the domain table for its board,agent-router-setuproutes generic spawns to the experts in it, andmemory-sync-setupaudits it. An empty roster makes all three degrade quietly./brewcode:teams-setup install backend “Kotlin + Spring services, Postgres, Testcontainers integration tests — one agent per bounded context”The team name and the free-text brief are both optional, and both are worth giving: the brief is what the analysis phase reconciles against your actual code before it proposes a roster. To drop a team later, name it —
/brewcode:teams-setup uninstall backend, orpurge backendto take the archive and trace files with it. - task-board-setup
Deploys the board, the
task-trackeragent, and the generated/task-specskill.superreview-setupthen uses the board as its intent source and preferstask-trackeras its scope agent, so the board must exist first./brewtools:task-board-setup install . “one lane per service, keep the existing docs/roadmap.md as the backlog source”The path argument targets another repo when you need it;
.or nothing means the current one. The trailing directive steers the module split. - convention and rulesnot setups — recurring tools
Optional but strongly recommended before the next step.
/brewcode:conventionwrites.claude/convention/and/brewcode:ruleswrites.claude/rules/.superreview-setupbuilds its rule-pointer table from exactly those two directories; without them the generated review skill degrades to aCLAUDE.md-only preflight./brewcode:convention full /brewcode:rules “derive rules from the last 200 commits, one file per domain, no duplicates of CLAUDE.md” - superreview-setup
The heaviest reader of the lot: rules, conventions, the agent roster, the board, and your project invariants all feed the generated
/superreviewskill. Run it once everything above exists, and it produces a review skill that actually knows this project./brewcode:superreview-setup install “EXTENDED depth — add domain-expert fan-out and adversarial validation; gate on the Gradle build and Detekt”The prompt is where depth is chosen: say
EXTENDEDfor the domain-expert fan-out, or leave it out for the defaultQUICK. - memory-sync-setup, then docsync-setup
/memory-synckeeps everything auto-loaded into context honest — nestedCLAUDE.mdfiles, rules, conventions, agents, skills. It wants the full surface to be present, which it now is.docsync-setupthen tracks staleness of the docs themselves. Two separate sessions — each asks its own questions./brewdoc:memory-sync-setup install “treat docs/ as out of scope; audit the agents in .claude/agents on every run”/brewdoc:docsync-setup install “track README.md, docs//*.md and .claude/rules/; stale after 30 days” - The hook layer, in any ordercheap, opt-in
manager-setup,agent-router-setup,agent-deadline-setup,agent-return-setup,think-short-setup. These copy a hook and register it — no repo analysis, no long question chain, nothing downstream depends on them. Pick the behaviours you want.agent-router-setupis the one exception to “any order”: it names the experts it redirects to, so it is worth more afterteams-setup./brewtools:manager-setup install level balanced /brewtools:agent-router-setup install level fast /brewtools:agent-deadline-setup install project 20 /brewtools:agent-return-setup install project 1000 2500 /brewtools:think-short-setup install projectEach extra argument is the decision worth making up front: the wall’s strictness, the router’s tier (
fastis deterministic Node and free;strictadds an LLM judge), the subagent deadline budget in minutes, the return-size pass/file thresholds in est-tokens, and whether terse mode is scoped to this project or to~/.claudefor every project you open.
Mode vocabulary
Every setup speaks the same seven verbs, in this order of escalation:
| Mode | What it does |
|---|---|
status | read-only report: what is installed, what drifted from the plugin templates. Writes nothing |
install | full generation — the interactive path with subagents and questions |
upgrade | re-sync an existing install against the current plugin version, keeping your customizations |
enable | re-arm an installed-but-off mechanism |
disable | turn it off, leave the files in place |
uninstall | remove the artifacts and the registration |
purge | uninstall plus the state, config, and any local overrides |
No argument resolves to status when the mechanism is already installed and install when it is
not, so a bare invocation on a fresh repo sets things up and a bare invocation on a configured repo
just reports.
The one deliberate exception
/brewcode:semble-setup always defaults
to status, installed or not. It is the only setup whose install can reach outside the project
and write to the machine (brew install uv), and a bare invocation must never trigger that. To
install it, say so: /brewcode:semble-setup install.
All eleven implement the full seven verbs — the five setups that previously lacked enable/disable
gained them in v5.1.0. The on/off state uses the same two mechanisms described above.
teams-setup enable/disable is a real rename of every roster member to <name>.md.disabled,
documented in its own SKILL.md.
| Skill | Modes it accepts |
|---|---|
semble-setup | all seven, plus reindex, optimize, resume |
superreview-setup | all seven, plus a free-text fine-tune prompt and an optional scope |
teams-setup | all seven — each taking an optional team [name] |
task-board-setup | all seven, plus an optional target repo path and a free-text directive |
think-short-setup | all seven, plus project / global scope and a free-text intent |
agent-deadline-setup | all seven, plus project / global and a minutes budget |
agent-return-setup | all seven, plus project / global and a pass/file threshold pair |
agent-router-setup | all seven, plus level fast / level strict |
manager-setup | all seven, plus level strict / level balanced and edit |
memory-sync-setup | all seven, plus a free-text fine-tune prompt |
docsync-setup | all seven, plus sync, reread, frontmatter |
Getting back out of the manager wall
manager-setup’s HARD wall is the one setup that can block the command you would normally use to turn
it off. While armed, it denies Write, Edit and Bash in the main session — and the obvious
disarm command is itself a Bash call. Before v5.0.0 that made the wall a trap: the documented exit
was blocked by the thing it was meant to exit.
The wall now exempts exactly one command shape, and install / upgrade copy the helper into your
project so the path needs no resolution:
node /abs/path/to/project/.claude/brewtools/manager/manager-state.mjs set hard=false/brewtools:manager-setup disable runs exactly that for you.
Existing installs must run upgrade once
A project set up before v5.0.0 has no manager-state.mjs in it, so the disarm command fails with
Cannot find module. Run /brewtools:manager-setup upgrade once after updating brewtools — it
backfills the helper, re-registers the guard, and leaves hard and level exactly as they were,
so an armed wall stays armed and a disarmed one stays disarmed.
If the wall is already armed and blocking you, delegate it: subagents are never walled, so
Task a subagent to run /brewtools:manager-setup upgrade in this project.
The exemption is deliberately narrow. It applies only when the command starts with node , the first
argument is that exact helper path, and the rest is the helper’s own CLI. Any shell operator, any $
expansion, any node eval flag turns it off — so no BT_ROOT= prelude, no && echo, no || echo,
no test -f. That narrowness is the fix for the second half of the problem: the old exemption matched
loosely enough to be a code-execution hole.
After the setups
Re-run /brewcode:setup-status any time. It also catches drift: when you update the plugins, the
hooks and templates a setup copied into your project fall behind the new versions. The dashboard
reports those rows as stale and hands you the upgrade command for each.
Drift is worth taking seriously, because a stale hook can fail silently rather than loudly.
think-short-setup spent several releases quietly injecting nothing in any project that had also
installed agent-router-setup or agent-deadline-setup, while its own status block still read
3/3 enabled. setup-status plus a periodic upgrade is what catches that class of failure.
setup-status
The read-only dashboard in full: what it probes per row, how it decides stale vs partial.
Quick Start
The 15-minute path if you only want the board, conventions, and a deep-review skill.
Installation
Marketplace commands, requirements, updating, and troubleshooting.
Latest Release
Download, changelog, and installation instructions.
View on GitHub
Source code, README, and configuration files.