# Using throng from Claude Code

throng is registered as an MCP server (see .mcp.json, or run `claude mcp add throng --scope user -- throng mcp`). It runs swarms of coding agents on a repo and verifies every result with the repo's real build and tests.

## Typical flow
1. `throng_swarm` with the repo path and a goal ("make every test in tests/stats.rs pass"). Pick the agent count and model.
2. `throng_status` with `wait_seconds` to block until it finishes, instead of polling.
3. `throng_result` for the final status, the engine's verification and the full patch.
4. `throng_apply` only if the user wants the change. It refuses if the files it touches were edited since the swarm started.

## Other tools
- `throng_verify`: run the repo's tests through the cached engine. Useful on its own: it answers instantly for code it has already seen and re-runs only the test binaries a change can affect. Use it instead of a cold `cargo test` when several agents are checking the same code.
- `throng_improve`: rounds of plan, work, verify, reflect. `ambition` is fix, grow or both.
- `throng_knowledge`: what earlier swarms learned about this repo, with each lesson's measured effect.
- `throng_agent`: one agent's full transcript. `throng_stop`, `throng_env`: stop a swarm; see what this machine has.

## Rules
- Never apply a result the user did not ask for.
- A swarm result is only "done" when `throng_result` shows the engine verified it. Report the pass count, not the agents' own claims.
- If a check fails, read the failing test names and output from the result before retrying with a narrower goal.
- On a machine someone is also using (games, video), cap build parallelism (for Rust: `CARGO_BUILD_JOBS=4`) and keep agent counts low.