audit-sweep-dispatch

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:

1. GREEN — Passing, no action. Acknowledge and move on. Do not dispatch agents for things that already pass.
2. 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.
3. 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.
4. 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.