メニュー
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.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SOC 職業分類に基づく
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/DojoGenesis/plugins --skill audit-sweep-dispatchコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
Run a bounded kata roll over the project's bring queue — start a session with an explicit target (reps or minutes), surface and stage exactly one bring per tick, log the outcome only on the human's word, then advance. Use when the user says "start a roll", "roll for N reps", "do a 25-minute roll", "tick", "next rep", "resolve this tick", "skip this tick", or "pause/resume/end the roll".
Set up the kata roll in a project that already runs (or is starting) the bring loop — confirm bring/ exists, explain where the roll's own ledger lives, walk through the opt-in timer, and make the two-plugin coexistence with bring-loop explicit. Use when the user says "set up kata-harness", "install the roll plugin", "add rolls on top of bring-loop", or asks how the timed roll relates to their daily bring.
Produces markdown memory artifacts (conversation summaries, seed files, philosophical reflections, doc updates) and a dated compression log by distilling a long conversation into its essential decisions and learnings. For the lighter, routine end-of-session wrap-up, use `session-compression` instead — this skill is for a long conversation that needs the fuller multi-artifact treatment. Use when: "compress this context", "distill this conversation", "create a memory artifact", "condense this history", "extract key wisdom before handoff".
| 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 | dispatch-coordinate |
| version | 1.0.1 |
| tags | ["audit","dispatch","sweep","triage","agents"] |
| 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"}] |
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.
/health-audit or any audit that produces RED/YELLOW/GREEN findingsReceive the audit findings and sort into four buckets:
[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.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 |
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.
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.
Group the substantial YELLOW findings into waves by file independence:
internal/client/, internal/commands/, internal/providers/ can all run in parallel because each writes to its own *_test.go.Wave plan format:
Wave 1 (3 agents, concurrent):
- Agent A: internal/client — add missing test coverage
- Agent B: internal/commands — add edge case tests for /init
- Agent C: ci.yml + installer.go — fix security lint finding
Wave 2 (2 agents, after Wave 1 verified):
- Agent D: internal/providers — add provider failover tests
- Agent E: internal/telemetry — add span coverage
Dispatch Wave 1 agents using parallel-dispatch conventions:
After all agents in a wave complete, verify each independently before launching the next wave:
git status — confirm the expected files were changedgrep for expected patterns (new test function names, fixed import paths)Do not trust agent self-reports. An agent that reports "complete" with no files changed in git status has not completed.
Produce a final dispatch report:
| Item | Routing | Status | Verification |
|------|---------|--------|-------------|
| Build fix: import path | RED → main thread | DONE | go build green |
| Makefile TODO marker | Trivial → main thread | DONE | in-thread |
| internal/client coverage | Wave 1 Agent A | DONE | go test: 78%→91% |
| internal/commands coverage | Wave 1 Agent B | DONE | go test: 65%→83% |
| ci.yml security lint | Wave 1 Agent C | DONE | lint clean |
| internal/providers tests | Wave 2 Agent D | DONE | go test: 4 new cases |
| internal/telemetry spans | Wave 2 Agent E | FAILED | no files changed — re-dispatch |
Example 1: Post-audit dispatch for dojo-cli sweep (Apr 10)
Audit produced: 1 RED (import path), 4 YELLOW substantial (test coverage across 4 packages), 3 YELLOW trivial (Makefile comment, TODO.md, improvement-plan markers).
Routing:
Result: 2-wave dispatch, 5 agents total, zero file conflicts, all verified green.
Example 2: Gateway audit with architectural RED
Audit found: 1 RED (missing D1Syncer injection causing nil panic at startup), 2 YELLOW substantial (new handler stubs in handle_documents.go), 1 YELLOW trivial (stale port reference in README comment).
Routing:
Note: Even though Wave 1 was just 1 agent, the wave structure is still correct — the D1Syncer RED had to be resolved first or the agent's new handlers would have panicked at test time.
git status. Re-dispatch with more explicit instructions including the exact line numbers to change.git status and the build command. Agents report "done" on partial work more often than you expect.git status + build/test command — not agent self-reportssystem-health): Produces the RED/YELLOW/GREEN findings that this skill routes. The natural upstream trigger for audit-sweep-dispatch.agent-orchestration): The dispatch mechanism used for Wave 1 and Wave 2 agents — handles file manifests, agent prompts, and per-track verification.agent-orchestration): Use before this skill when the audit output is large enough that the wave structure itself needs architectural design.agent-orchestration): Provides per-agent status tracking during long multi-wave sweeps.