jpmschweitzerandClaude Opus 4.8
c318cea6db
Add `cargo test --quiet` to the pre-push Rust block (sharing clippy's target/ guard) so the suite runs automatically on every push touching server/. Nothing ran the tests before — pre-push did only fmt/clippy/deny and there is no CI — so a Rust regression could reach main unverified. Document the resulting agent-spawn rule in team-patterns.md: don't have implementation agents pre-run fmt/clippy/test pre-emptively, since the push gate now enforces all three. The gate is authoritative; the lead patches any fallout at push. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.9 KiB
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):
- Lore librarian agent (read-only): ingests all source material, answers focused context queries from writers, tracks cross-file consistency
- 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
- 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 Rust
verification and runs on every push the lead makes when server/ changed:
cargo fmt --check, cargo clippy --all-targets -- -D warnings, and cargo test
(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.