### Before filing - [x] I've read `SCOPE.md` and checked `.out-of-scope/`, and this isn't covered by either. ### Skill implement-spec ### What went wrong **What happened** We ran a spec-implementation workflow that launches one subagent per ready ticket, all in parallel, each in its own worktree. There's no limit, so we ended up with 6–7 agents at once. Each one was running its own database and test suite on the same machine. The load average hit ~140. Tests started timing out in unrelated files (passing on a quiet re-run), a suite that normally takes ~4 min took ~19, and agents started reporting flaky failures that weren't real defects. Slow runs also made the agents spend more time re-running things, which made it worse. **What we changed** - Cap at 3 implementer agents at a time; merges are queued one at a time. - Implementers run a light gate (lint, typecheck, their own tests) instead of the full suite. - The merger runs the full suite, so only one full run happens at a time. ### Proposed change The skill says "maximum concurrency" with no ceiling. Might be worth a configurable cap (default ~3) and a note that each implementer multiplies local CPU/DB load, not just token cost.
