# Team Patterns

## Model selection

Default model is Opus 4.6 (200K context). For heavy sessions (workshops,
large reviews, milestone planning), switch to extended context on-demand:

- `/model sonnet[1m]` — Sonnet 4.6 with 1M context window
- `/model opus[1m]` — Opus 4.6 with 1M context window
- Cost: 2x input + 1.5x output for tokens beyond 200K (Tier 4 required)

## Large content pushes

When producing many files (wiki pages, content batches, bulk docs):
1. **Lore librarian** agent (read-only): ingests all source material, answers focused context queries from writers, tracks cross-file consistency
2. **Multiple writer** agents (parallel, by domain): each gets a task slice, writes directly to disk using the Write tool — one file at a time, write often, no text accumulation
3. **Reviewer** agents (blocked until writing done): check voice consistency, attribute uniformity, style

Key: writers use Write tool directly (no transcription bottleneck), librarian catches contradictions early, split work by domain not volume.

## Team monitoring (stuck agent detection)

When leading a team (workshop, batch, or any multi-agent session):

**Agent heartbeat rule** — include in every agent spawn prompt:
> If you have been working on a single task for more than 15 minutes
> without making progress, message the team lead with what is blocking
> you. Do not keep retrying the same approach silently.

**Team lead proactive checks:**
- If an agent has not sent a message in ~20 minutes, ping them for a status update.
- **Bottleneck detection:** if other agents are idle and waiting on one agent's output, that agent's silence is a red flag — check on them immediately, do not wait for the next natural message.
- When checking on a stuck agent, offer to reassign the task or pull in another agent to help.

## Agent verification — don't duplicate the push gate

The pre-push hook (`.config/hooks/pre-push`) is the source of truth for
verification and **runs on every push the lead makes**: when `server/` changed —
`cargo fmt --check`, `cargo clippy --all-targets -- -D warnings`, and `cargo test`;
when `client/` changed — the full gdUnit4 suite via `tests/run-godot` (T-1065);
when `tooling/` changed — `make test-tooling` (plus `cargo deny`, ruff, JSON
validation, systems.db stamp). There is no CI (no
`.gitea`/`.github`/`.forgejo` workflows) — the push gate is the only automatic
verification, so it is deliberately comprehensive.

Therefore, when spawning implementation agents, do **not** tell them to run
`cargo fmt`, `cargo clippy`, or `cargo test` pre-emptively — the push gate enforces
all three, so it is pure duplication. Worse, an agent running a *weaker* check (e.g.
plain `cargo clippy` without `-D warnings`) reports a false "clean". Let agents write
code; the gate is authoritative.

On a gate failure at push: fmt auto-fixes (`cargo fmt`); clippy is a quick lead patch;
a `cargo test` failure is a real regression — fix it, or SendMessage the still-alive
agent to fix it in-context. Net: agents verify nothing the gate already covers, and the
lead lets the gate catch fallout on push.