CLAUDE.md · git:20260705.23fdb2d · 2026-07-05 · sha256 fb1908ba25c388eb
CLAUDE.md git:20260705.23fdb2dA
Immutable. This exact content is served forever at /api/v1/blob/fb1908ba25c388eb.
# Claude Code Swarm Mode > **For this repository, [AGENTS.md](./AGENTS.md) is the root engineering contract. Read it before any code change.** The long-form rationale and historical failure map live in [`docs/engineering-invariants.md`](./docs/engineering-invariants.md). When swarm mode is enabled, `AGENTS.md` still applies; swarm-mode instructions add workflow structure, not exceptions to the engineering invariants. Normal behavior is the default. If `.claude/session/swarm-mode.md` exists, swarm mode is enabled for the current session and you must read that file before starting complex work. When swarm mode is enabled: - Quality is the only success metric. - There is no time pressure. - Do not compress a workflow just because the task is large. - Prefer parallel subagents for disjoint investigation and review work. - Keep implementation, validation, and final judgment in separate contexts when possible. - Explorer-style work is for breadth and candidate generation. - Reviewer-style work is for validation of candidate findings or implementation quality. - Critic-style work is for final challenge of reviewer-confirmed findings or high-impact implementation conclusions. - Do not let the same context both invent and approve a finding when a separate verification pass is possible. - No approval without positive evidence of what was checked. - No high-severity finding without exact evidence and, when relevant, runtime-aware verification. - Preserve Claude Code speed by parallelizing broadly and reserving the deepest validation for high-risk or ambiguous work. - Across many different repositories, explore local patterns first rather than assuming one project's conventions apply to another. If `.claude/session/swarm-mode.md` does not exist, behave normally. ## Permanent project directives (do not override) These directives were explicitly requested by the project owner and persist across all sessions, contributors, and agents. They are not workflow preferences — they are correctness gates. 1. **We never defer work.** Optional or background-flavored work is never silently dropped onto a fire-and-forget microtask, a "later" todo, or an untracked follow-up. If a result is needed by a downstream step, test, or user, the work is done as real, reachable, verifiable work — either awaited in-band or scheduled through a real durable task that is tracked to completion. "Defer" is never a synonym for "skip." A deferred task whose output is consumed must be observable and verifiable. 2. **We never ship unwired code.** Every new tool, transition, status, hook, command, agent-map entry, or new code path is wired end-to-end before a change is considered complete: export → plugin registration → tool/agent map entry → help/docs surface → test coverage. Dead exports, orphan transitions, unregistered tools, status enums with no producer/consumer, and untested branches count as unwired code and are blockers — not polish items for a later PR.