harness-helplisted

# /harness-help You don't remember every skill, so ask. Most work travels one **main flow**; everything else is standalone. Each skill below is documented in its own `skills/<name>/SKILL.md` — this router only says *when to reach for which*. ## The main flow: idea → shipped 1. **`/spec <slug>`** — turn a fuzzy request into `spec.md` + `plan.md` under `.agent/plans/<slug>/`, then route to plan approval (ExitPlanMode). Add `--interview` when the request is fuzzy enough that a wrong guess would commit the spec to the wrong shape, or `--score-candidates` when the field of problems/approaches is wide enough that the pick should be scored, not asserted. Approval is what unlocks editing — `spec-gate` stops asking once the plan-approval flag exists. 2. **`/supervise <slug>`** — run the approved plan wave by wave, dispatching specialists per the delegation contract and auditing after each wave. `--goal-mode` for budgeted, resumable runs. 3. **`/verify-completion <claim>`** — before accepting any "done": a fresh context re-checks the claim mechanically, then a refute-by-default judge. `/supervise` calls this at its completion step; reach for it directly whenever a builder's word is the only evidence. 4. **`/wrap`** — commit + PR with the safety gates (gitleaks, risk areas) intact. `--auto-push` / `--auto-merge` are opt-in escalations. A single small edit needs none of this — just make the edit; the gates scope trivial work out by design. ## Stan