| name | audit-sweep-dispatch |
| description | Routes health-audit findings to the correct execution path — main thread, foreground fix, or parallel agent waves. Use when health-audit findings need to be sorted by effort and dispatched as agent waves. |
| model | sonnet |
| category | agent-orchestration |
| version | 1.0.0 |
| tags | ["audit","dispatch","sweep","triage","agents"] |
| triggers | ["route health audit findings","dispatch audit findings as agent waves","sort audit by effort","triage health findings"] |
| tier | 1 |
| agents | ["primary"] |
| tool_dependencies | ["file_system"] |
| inputs | [{"name":"findings","type":"array","description":"Health-audit findings with severity (RED/YELLOW/GREEN) and effort estimate","required":true},{"name":"build_commands","type":"string","description":"Build and test commands to use for verification (e.g. \"go build ./... && go test ./...\")","required":false}] |
| outputs | [{"name":"dispatch_report","type":"text","format":"markdown-table","description":"Summary of what was fixed in-thread, dispatched to agents, and deferred"}] |
Audit-Sweep-Dispatch Skill
Philosophy
A health audit is a pre-sorted dispatch plan. GREEN findings need no action. RED findings block all other work. YELLOW findings split cleanly: trivial ones are faster to fix in-thread than to delegate, substantial ones parallelize across packages. The value of this skill is recognizing which bucket each finding belongs in and routing it correctly — not treating every finding as equally deserving of an agent.
The hardest mistake to catch is dispatching an agent for a 4-line edit. The second hardest is fixing a RED item in a side thread while kicking off Wave 1 in parallel. This skill encodes both rules mechanically.
When to Use
- After running
/health-audit or any audit that produces RED/YELLOW/GREEN findings
- When a sweep produces more findings than you can hold in working memory
- When a codebase has both quick wins (trivial) and real work (substantial) mixed in the same audit output
- When you want parallel coverage raises without merge conflicts
Workflow
Phase 1: Triage
Receive the audit findings and sort into four buckets:
- GREEN — Passing, no action. Acknowledge and move on. Do not dispatch agents for things that already pass.
- RED / P0 — Blocking. Fix in the main thread foreground before anything else is dispatched. These are the findings that break builds, fail security checks, or block Wave 1 from running at all.
- YELLOW / Trivial — Doc changes, comment fixes, marker updates,
[DONE] stamps, single-line tweaks. Fix directly in the main thread. Rule: if the fix is under 10 lines and touches only one file, it is trivial. Never launch an agent for a trivial fix.
- YELLOW / Substantial — New test files, new config, multi-line code changes, coverage additions, handler rewrites. These go to agents.
Output a triage table before dispatching anything:
| Finding | Severity | Effort | Routing |
|---------|----------|--------|---------|
| Missing test coverage in internal/client | YELLOW | Substantial | Agent Wave 1 |
| Stale TODO marker in Makefile | YELLOW | Trivial | Main thread |
| Build fails: wrong import path | RED | Substantial | Foreground now |
Phase 2: RED Fixes First
Fix all RED findings in the main thread before dispatching any agents. Verify each RED fix with the full build/test command before proceeding. Do not start Wave 1 until the build is green.
Phase 3: Trivial Sweep (Main Thread)
Work through the trivial YELLOW items directly. These are faster to do than to explain to an agent. Keep a running checklist. When all trivials are done, commit or stage them if appropriate.
