qclisted

# Quality Control Verify recent code changes by spawning parallel agents that each look at the change from a different angle. The goal is fast confidence — catch real problems, skip theater. ## Step 1: Understand the change Before spawning anything, understand what changed and why. Run `git diff --name-only` and `git diff --cached --name-only`. Use conversation context for intent. You need to know: - **What files changed** — this determines which agents to spawn - **What the change is supposed to do** — this is what you tell the agents - **What could go wrong** — this shapes the breaker prompt If there's no git diff (e.g. change was just discussed, not committed), use conversation history. ## Step 2: Quick sanity check (if anything exists) Glance for an existing test suite, linter, or type checker — `package.json` scripts, `Makefile`, `pytest`, `go test`, etc. If something relevant exists, run it before spawning agents. It's the cheapest signal and avoids wasting agents on problems a 10-second command would have caught. Many projects won't have any of this. That's fine — skip straight to Step 3. ## Step 3: Spawn agents Spawn 2-4 agents in parallel. Always include a breaker. Pick the rest based on what the change actually needs. ### Agent types **Breaker** (`subagent_type: "breaker"`) — Always spawn one. This is the adversarial tester. It reads the code and actively tries to break it: malformed input, boundary values, missing fields, concurrent access, type coercio