Skip to content

Solo mode and team mode

The only difference is enforcement. Two hooks are off in solo and on in team. Here is exactly what each one refuses.

4 min read

PagesSolo mode and team mode

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.

SoloTeam
Rules, skills, agents, solution docsAll of themAll of them
/ce-brainstorm, /ce-plan, /ce-work, /ce-code-review, /ce-compoundAvailableAvailable
block-destructive, env-leak-detector (two scripts), enforce-typecheck, auto-lint, enforce-doc-metaOnOn
plan-gateOffOn
enforce-git-trackedOffOn
Hook scripts from the stack68

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-brainstorm for something vague, to get it to a shape worth planning.
  • /ce-plan writes a plan into docs/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-work builds against the plan. plan-gate now allows the edits.
  • /ce-code-review before the PR, /ce-compound after. What you learned becomes a solution doc in docs/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