# 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.

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:

```md
---
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:

```sh
bun run verify:hooks
```

pnpm:

```sh
pnpm run verify:hooks
```

npm:

```sh
npm run verify:hooks
```



---

Agentic Boilerplate: A Next.js repo your agent already knows. Free during launch, then $99 once.

- Site map for agents: https://agenticboilerplate.com/llms.txt
- Public API: https://agenticboilerplate.com/openapi.json
- Contact: agenticstudio@gmail.com