Manager — codeword-triggered Manager mode + HARD delegation wall

sonnet hook

Tip

What is Manager mode? You type a short codeword (++m, ++rr, ++r, or ++a) anywhere in your message and Claude instantly activates a discipline contract — just for that one message. ++m makes Claude a pure orchestrator that delegates all hands-on work — and when you are in plan mode it automatically adds a full task-graph planning pass. ++rr and ++r inject review discipline (anti-regression / two-phase double-check). ++a injects an architecture-first directive — design before code, reuse existing patterns, no over-engineering. No setup required. The codeword is stripped from your message; your actual text is preserved.

What actually happens

You type:

++m refactor the payment module

Claude actually receives (you never see this part — it is injected invisibly by a hook):

[ROLE: MANAGER]

You are a Manager, not an executor. Your only actions: think, plan, build the
TaskGraph, delegate, observe, integrate. You do not write/edit code, run
builds/tests, or hands-on debug. Catch yourself editing a file or running an
impl command -> STOP, spawn a subagent. "Faster to do it myself" is a symptom,
not an argument - delegate anyway.

Protocol, always:
1. Decompose the TASK into a full TaskGraph BEFORE any work (TaskCreate for all).
2. Dependencies via TaskUpdate addBlockedBy/addBlocks - real data-handoffs only.
   No dependency = independent = parallel.
3. Assign owner (TaskUpdate owner), then launch the agent.
4. Status honestly: pending -> in_progress (BEFORE start) -> completed (only truly
   done, green - never "partially").
5. Observe: read reports, validate, integrate. Agent failed -> file a follow-up
   task and re-delegate, never fix by hand.

Sizing before spawning: one subagent = ONE bounded unit - one deliverable,
~<=5 files, ~<=10 steps. Bigger MUST be split into N tasks, fanned out in ONE
message. A big task handed to one agent = an agent gone for an hour: you cannot
observe it, cannot correct it, and it usually drifts off-target.

Every spawn prompt MUST carry, explicitly:
  GOAL     - the overall task and why it exists; the point beyond the file edit.
  ROLE     - what this agent owns; what it must NOT touch.
  SCOPE    - exact paths/commands in bounds + explicit out-of-bounds.
  CONTEXT  - what is already done, by whom, what runs in parallel. Adapt it per
             agent, trimmed to what THIS one needs; never dump everything.
  CONSUMER - who or what uses the result next, and the shape it must fit.
  DONE     - acceptance criteria + the exact report shape you want back.
A bare one-line task is never enough.

Scan ALL available agents; summon only genuine experts - one best-match per task.
Autonomy: finish the job, don't stop halfway, don't ask where you can decide.
Minimize the critical path.

refactor the payment module

Your single line becomes: the full Manager contract (above) + your original request. The codeword ++m is consumed; your text reaches Claude unchanged. Curious how injection works? See Prompt Injection.

Two rules that do the heavy lifting

Bounded units, not one giant agent
One subagent = one deliverable, roughly 5 files and 10 steps. Anything bigger is split into N tasks fanned out in ONE message. A big task handed to one agent = an agent gone for an hour: you cannot observe it, cannot correct it, and it usually drifts off-target.
Six-field brief on every spawn
Each spawn prompt carries GOAL, ROLE, SCOPE, CONTEXT, CONSUMER, DONE. CONTEXT is trimmed per agent — never dump everything. A bare one-line task is never enough.

Field	What it must say
GOAL	The overall task and why it exists; the point beyond the file edit
ROLE	What this agent owns; what it must NOT touch
SCOPE	Exact paths/commands in bounds + explicit out-of-bounds
CONTEXT	What is already done, by whom, what runs in parallel — trimmed to what THIS agent needs
CONSUMER	Who or what uses the result next, and the shape it must fit
DONE	Acceptance criteria + the exact report shape you want back

Codewords

Codeword	Means	What it does
`++m`	Manager	Manager + delegation for the current task — Claude orchestrates, never codes by hand; splits work into bounded units and briefs every spawn with GOAL / ROLE / SCOPE / CONTEXT / CONSUMER / DONE
`++rr`	Regression Review	Regression review with double-check — after each significant phase, run a review focused on no regression + project standard + correctness; two-phase (review → double-check → fix); mandatory final cross-review at task end
`++r`	Review	Review with double-check — after each significant change, run a two-phase multi-agent review (review → double-check → fix); codeword-only, no ambient injection or wall state change
`++a`	Architecture	Architecture-first pass before coding — delegate a design that fits the existing project architecture, patterns and rules; robust, scalable, and simple (no over-engineering); reuse existing patterns first, keep clean seams. Independent group, combines with `++m`/`++rr`/`++r`; same block in normal and plan mode (in plan mode it is written into the plan).

Detection order: within the review group, ++rr is tested before ++r (longest-prefix first). ++m is matched as a standalone token; in plan mode it auto-adds the plan addon. ++a is its own independent group and can combine with either.

Put the codeword anywhere: start, middle, or end of your message. Everything else is passed through unchanged.

Everyday commands

Command	What it does
`/brewtools:manager status`	Show what is currently on — codeword state, wall state, prompt source
`/brewtools:manager on`	Turn on the HARD wall — Claude physically cannot write/edit files in this project until you turn it off
`/brewtools:manager off`	Turn the HARD wall off
`/brewtools:manager edit`	Open the Manager prompt text so you can customize it

The HARD wall

Caution

With the HARD wall ON, Claude in the main chat physically cannot edit files, write, or run mutating commands. It is forced to delegate every hands-on step to a subagent. Subagents have full freedom — they can write, edit, run tests, push commits, anything. Turn the wall on and off with /brewtools:manager on / /brewtools:manager off. It is opt-in and per-project — nothing changes until you enable it.

The wall in action

The wall is ON. You ask:

fix the bug in payment.ts

Claude tries to edit the file directly — and is blocked:

Caution

Edit blocked — Manager HARD wall is ON. The main session cannot edit files, write, or run mutating commands. Delegate this to a subagent.

So Claude does the right thing — it spawns a subagent, which has full access:

Main session: delegate
Claude spawns a developer subagent with the task “fix the bug in payment.ts”.
Subagent: do the work
The subagent edits payment.ts, runs the tests — all tools allowed inside a subagent.
Main session: integrate
Claude reads the subagent’s result and reports back. It never touched the file itself.

What is allowed vs blocked (wall ON)

In the MAIN chat (wall ON)	Allowed?
Read, search, plan, delegate (Task)	Yes
Edit / Write files	No — delegate
Run mutating commands	No — delegate (read-only Bash allowed on the default level)
Anything inside a subagent	Yes — full freedom

This is what “delegate everything” means in practice — the wall makes it physically true, not just a suggestion. For the deep mechanics (tool buckets, strict vs balanced, the agent_id linchpin) see the technical spoiler below.

When to use

Situation	What to type
Delegate one complex task as Manager, just this turn	`do X ++m`
Start a full parallel plan with task breakdown (in plan mode)	`plan Y ++m`
Enforce the delegation rule for a whole project session	`/brewtools:manager on`
Run one task under the wall then auto-revert	`refactor payment service in hard mode`
Run task as Manager without changing any wall state	`build release plan as manager`
Check current state	`/brewtools:manager status`

Technical: how the HARD wall works (tool buckets, strict vs balanced, agent_id linchpin)

The HARD wall is an optional, project-scoped guard that physically blocks the main Claude session from writing or editing files. Subagents always stay fully free — delegation is never blocked.

Install-once + state-gate

/brewtools:manager on copies hardmode-guard.mjs from the plugin cache into <cwd>/.claude/brewtools/manager/hardmode-guard.mjs and registers a PreToolUse * entry in <cwd>/.claude/settings.local.json (personal, gitignored). The guard is registered once; subsequent on calls overwrite it (so plugin updates propagate) without adding duplicates. A /reload or session restart is required after first install.

The guard reads <cwd>/.claude/brewtools/manager/state.json on every PreToolUse call. When hard !== true, the guard exits immediately — no denial. off flips state.hard=false without touching settings.local.json; the guard stays registered but becomes a no-op. This split exists because editing settings while the wall is armed would be blocked — the state flip is self-exempt and always succeeds.

agent_id linchpin — main session blocked, subagents free

The PreToolUse payload carries agent_id / agent_type only for subagent-internal tool calls. Main-session calls have no agent_id. The guard denies mutations only when agent_id is absent. Subagents pass through freely — delegation itself is never blocked.

Re-verified on CC 2.1.195 (2026-06-27) — the discriminator still holds. agent_id / agent_type presence is an undocumented field; re-verify on each major CC upgrade.

Tool buckets

Bucket	Tools	Main session while wall ON
ALWAYS-ALLOW	`Read`, `Grep`, `Glob`, `Task`, `Agent`, `Skill`, `TaskCreate`, `TaskUpdate`, `TaskList`, `TaskGet`, `TodoWrite`, `AskUserQuestion`	Always allowed — delegate / read / track
ALWAYS-BLOCK	`Write`, `Edit`, `NotebookEdit`, `WebFetch`, MCP-write tools	Always denied — hands-on mutation
LEVEL-gated	`Bash`, `WebSearch`, MCP-read tools	Decided by `level` (see below)

Strict vs balanced

Aspect	`strict`	`balanced` (default)
`Bash`	Fully OFF — every command denied	Read-only classifier — allow inspection, deny mutation
Allowed Bash (balanced)	—	`git status/log/diff/show/branch`, `ls`, `cat`, `pwd`, `which`, `echo`, `head`, `tail`, `wc`, `gh ... list/view`, `grep`/`rg`, `find` (no `-delete`/`-exec`)
Denied Bash (balanced)	—	`>`, `>>`, `rm`, `mv`, `cp`, `git commit/push/reset`, `npm install`, `pnpm`, `yarn add`, `pip install`, `mkdir`, `touch`, `chmod`, `sed -i`, `tee`, `kill`, `$(...)`, `node -e`
`WebSearch`	OFF	ON
MCP-read	Explicit-allow list only	Heuristic allow (read-shaped tool names)
MCP-write	Denied	Denied

The balanced Bash classifier is an allowlist of known-safe read-only commands, NOT a shell evaluator. Command substitution $(...) and node -e / --eval are denied even in balanced mode.

Off-switch safety

Guarantee	Mechanism
`/brewtools:manager off` is never blocked	`Skill` tool is ALWAYS-ALLOW; state writer is self-exempt by path anchor
Works even at `level strict`	`writeState` target path (`.claude/brewtools/manager/state.json`) is exempt from Bash denial
Every denied tool call shows the exit command	Deny reason: `Manager HARD wall is ON -- delegate via Task/Agent, or run /brewtools:manager off to exit.`

Technical: prompt resolution + scopes (where the Manager text comes from)

How the codeword injection works

On every user message, manager-prompt.mjs scans the prompt text. It matches ++m as a standalone token, and tests the review group longest-prefix first (++rr before ++r) so ++rr is never mis-matched as ++r. If no codeword is present (and the wall is not armed), the hook exits immediately — no file I/O, zero overhead.

The hook resolves the prompt text for the detected mode (full or planmode) via three-level fallback:

Project override: .claude/brewtools/manager/prompts/<mode>.md
Global override: ~/.claude/manager/prompts/<mode>.md
Plugin default: plugin references/<mode>.md

Project and global overrides survive plugin updates because they live outside the plugin cache.

When the HARD wall is armed, the Manager (full) block is also ambient-injected every turn with no codeword needed — codewords and wall injection are independent channels. On top of that, brewtools’ session-start.mjs reports the armed wall at session start and repeats the same two rules: delegate in bounded units (one deliverable, ~5 files), and brief every agent with goal + scope + what is already done + who consumes the result + acceptance.

Scope table

Thing	Scope	Files
Wall flags `{"{"}hard, level{"}"}`	PROJECT ONLY	`<cwd>/.claude/brewtools/manager/state.json`
Wall registration (guard)	PROJECT ONLY	`<cwd>/.claude/settings.local.json` + `<cwd>/.claude/brewtools/manager/hardmode-guard.mjs`
Soft `mode` field (informational)	project state	same `state.json`
Prompt-text overrides (`edit`/`reset`)	project or global	project: `<cwd>/.claude/brewtools/manager/prompts/<mode>.md` — global: `~/.claude/manager/prompts/<mode>.md`

The wall flags (hard/level) are resolved project-only. Passing --scope global to on/off/level is silently ignored (wall has no global scope); the flag only applies to prompt-text override scope in edit/reset.

Prompt resolution chain

Priority	State source	Prompt override source
1 (highest)	`.claude/brewtools/manager/state.json`	`.claude/brewtools/manager/prompts/<mode>.md`
2	`~/.claude/manager/state.json`	`~/.claude/manager/prompts/<mode>.md`
3 (lowest)	Hardcoded `{"{"}enabled:true, mode:"full"{"}"}`	Plugin `references/<mode>.md`

Global paths (~/.claude/*) are protected from direct Write/Edit tool access (Claude Code v3.4.70+). The skill writes them via bundled Node helpers using atomic lock+tmp+rename.

Plan Mode addon (auto in plan mode)

When ++m is used while the session is in plan mode (permission_mode === 'plan'), the hook injects both the full Manager block and the Plan Mode addon. The addon instructs the model to: write the full TaskGraph in English into the plan before starting; mark tasks with parallel / critical-path indicators; output all task and plan text in English regardless of user prompt language.

Full command and intent reference (all actions, hard-one-shot vs manager-run)

The skill also understands natural-language Russian (e.g. on/off, hard mode, status). The complete RU+EN trigger list lives in the skill’s SKILL.md.

Actions

Action	Command / natural language	Effect
`on`	`/brewtools:manager on`	INSTALL guard + ARM the HARD wall (project). `/reload` on first install only
`off`	`/brewtools:manager off`	DISARM the wall (state flip only — registration kept, guard no-ops)
`uninstall`	`/brewtools:manager uninstall`	DEREGISTER guard from `settings.local.json`, then `/reload`
`level strict`	`/brewtools:manager level strict`	Wall strictness = strict (Bash fully off)
`level balanced`	`/brewtools:manager level balanced`	Wall strictness = balanced (read-only Bash allowed)
`status`	`/brewtools:manager status`	Full explainer: codewords + wall state + effective prompt sources
`edit`	`/brewtools:manager edit`	Copy plugin default into project override for editing
`reset`	`/brewtools:manager reset`	Delete project override, revert to plugin default
`hard-one-shot`	`<task> in hard mode`	Wall ON — run task as Manager — auto-revert wall OFF when done (reverts even on failure or abort)
`manager-run`	`<task> as manager`	Run task as Manager with wall UNTOUCHED (discipline via injected prompt only — no wall toggle)
`inline-run`	`/brewtools:manager <task>`	Prepend Manager block, execute — no state change

Expected `status` output (wall off)

# Manager -- status

## Codewords (ALWAYS active -- hook-driven, independent of this skill)
Type `++m` anywhere   -> injects the Manager (full) block for that one turn.
Type `++m` while in plan mode -> injects the Manager + Plan Mode block for that one turn.
Type `++rr` anywhere  -> injects the Regression Review contract for that one turn.
Type `++r` anywhere   -> injects the Review contract for that one turn.
Type `++a` anywhere   -> injects the Architecture-first contract for that one turn.

--- injected by ++m (full) ---
<full Manager block text>

--- injected by ++m (planmode -- auto when permission_mode === 'plan') ---
<planmode block text>

## HARD wall (this project) -- registered=no  armed=OFF  level=balanced  (state source: default)
Enable:    /brewtools:manager on
Disable:   /brewtools:manager off
Uninstall: /brewtools:manager uninstall
Level:     /brewtools:manager level strict | balanced

`hard-one-shot` vs `manager-run`

hard-one-shot (<task> in hard mode) actually toggles the guard: wall ON — task runs — wall auto-reverts OFF when done, even on failure or abort. The guard never silently persists.

manager-run (<task> as manager) does NOT touch the wall state at all. Manager discipline is enforced via the injected prompt only. Use this when you want Manager behavior without arming or changing the guard.

⚙️

Updating plugins

Use /brewtools:plugin-update to check and update the brewcode plugin suite in one command. See the FAQ for details.

Manager — codeword-triggered Manager mode + HARD delegation wall

Tip

What actually happens

Two rules that do the heavy lifting

Codewords

Everyday commands

The HARD wall

Caution

The wall in action

Caution

What is allowed vs blocked (wall ON)

When to use

Install-once + state-gate

agent_id linchpin — main session blocked, subagents free

Tool buckets

Strict vs balanced

Off-switch safety

How the codeword injection works

Scope table

Prompt resolution chain

Plan Mode addon (auto in plan mode)

Actions

Expected `status` output (wall off)

`hard-one-shot` vs `manager-run`

Think Short

Prompt Injection

Brewtools overview

GitHub source

Updating plugins

Manager — codeword-triggered Manager mode + HARD delegation wall

Tip

What actually happens

Two rules that do the heavy lifting

Codewords

Everyday commands

The HARD wall

Caution

The wall in action

Caution

What is allowed vs blocked (wall ON)

When to use

Install-once + state-gate

agent_id linchpin — main session blocked, subagents free

Tool buckets

Strict vs balanced

Off-switch safety

How the codeword injection works

Scope table

Prompt resolution chain

Plan Mode addon (auto in plan mode)

Actions

Expected status output (wall off)

hard-one-shot vs manager-run

Think Short

Prompt Injection

Brewtools overview

GitHub source

Updating plugins

Expected `status` output (wall off)

`hard-one-shot` vs `manager-run`