Mode is one field in your selection. It changes one thing: whether two guard hooks are installed. Every rule, skill, agent and solution doc, and the whole Compound Engineering loop, is the same in both.
| Solo | Team | |
|---|---|---|
| Rules, skills, agents, solution docs | All of them | All of them |
/ce-brainstorm, /ce-plan, /ce-work, /ce-code-review, /ce-compound | Available | Available |
block-destructive, env-leak-detector (two scripts), enforce-typecheck, auto-lint, enforce-doc-meta | On | On |
plan-gate | Off | On |
enforce-git-tracked | Off | On |
| Hook scripts from the stack | 6 | 8 |
The Neon battery adds guard-neon-sql in both modes.
The list of team-only hooks is not a doc. It is the modes: [team] line in each
hook's own frontmatter. The resolver counts hooks from the same field, so the
builder's hook counter drops the moment you pick solo. What the counter says is
what the repo ships.
Solo is the default. The first thing a solo founder does with a new repo is push a change. A gate that demands a written plan before the first commit is a gate that gets deleted.
What plan-gate enforces
plan-gate is a PreToolUse hook on Edit, Write, MultiEdit, NotebookEdit and
Bash. Before the agent can write under src/, a plan in docs/plans/ has to
say it is approved. Approval is a field, not a vibe. Plans are markdown with
frontmatter, and the template ships as:
---
title: ""
status: draft
approved: false
---
## Problem
## Approach
## Files
## Verification
## Risks
status: draft means no code. A human sets status: approved and
approved: true. That is the approval step, and an agent should never do it on
its own. A plan that says status: approved but still has approved: false is
treated as not approved, because a contradiction should never fail open.
status: in-progress keeps the gate open while you work. Set status: done
when the work lands, or an old plan keeps the gate open for work nobody agreed
to.
What it does not do:
- It doesn't block reading or searching, from the tools or the shell. Commands
that don't write under
src/run too. Looking around is free, and should be. A plan written without reading the code is worse than none. - It doesn't block writes outside
src/. Docs, tests, config and the plan file stay editable, so the loop can run. - It doesn't check that the plan matches the change. Nothing can. It checks that someone stopped and wrote down the problem, the approach, the files, the verification and the risks before the first line of code.
That last point is the whole value. AI-assisted teams don't fail on bad code. They fail on code nobody can review: a big diff with no written reasoning behind it. A plan file makes the reasoning reviewable before the diff exists.
Shell writes count too. The hook catches redirects, tee, touch, rm, cp,
mv, sed -i and perl -i into src/, and follows cd. It is a strong
guardrail, not a sandbox: a script that writes files from inside node -e is out
of its sight.
What enforce-git-tracked enforces
A PreToolUse guard on git commit. It refuses a commit while untracked files
exist. On a shared repo, a half-committed feature (the route committed, the new
lib/ file forgotten) costs someone else an afternoon. Solo, you notice within a
minute and nobody else is blocked, so it's off.
The plan loop in practice
Team mode is built around the Compound Engineering commands, not paperwork:
/ce-brainstormfor something vague, to get it to a shape worth planning./ce-planwrites a plan intodocs/plans/.- A human reads it and approves it. This is the review that matters. Arguing about an approach in a plan is cheaper than in a pull request.
/ce-workbuilds against the plan.plan-gatenow allows the edits./ce-code-reviewbefore the PR,/ce-compoundafter. What you learned becomes a solution doc indocs/solutions/, so the next person doesn't rediscover it.
docs/plans/README.md in the generated repo says which mode you are in and what
that means, so a new contributor learns it from the repo, not from a colleague.
Choosing, and changing your mind
Pick solo if you are one or two people who already trust each other's commits. Pick team if more than two people share the repo, if you are handing the code to someone else, or if a merged PR has ever surprised you.
Switching later is not a migration. The mode lives in agentic.config.json.
Change it, regenerate, and diff. The only differences are the two hook scripts,
their entries in .claude/settings.json, the hooks README, the counts in
CLAUDE.md and README.md, the note in docs/plans/README.md, and
agentic.config.json itself. Or copy the two scripts from a team-mode repo
into .claude/hooks/ and wire them up by hand.
Either way, run the self-test after to confirm the guards are live:
bun run verify:hooks