witch-delegation

Files (3)

• SKILL.md
• dispatch-envelope.md · references/
• review-contracts.md · references/

SKILL.md (first lines)

# Witch Delegation

Execute approved work through fixed Witch-owned lanes. The controller owns routing, dispatch context, verification, the repair ledger, and the decision to ship.

## Fixed lanes

Work lanes are `witch-routine`, `witch-complex`, `witch-researcher`, and `witch-security`. Review lanes are `witch-task-reviewer`, `witch-re-reviewer`, and `witch-final-reviewer`.

Never substitute a generic subagent for a Witch lane. Do not override the selected agent profile's model or reasoning effort in a dispatch. Do not automatically promote work to another lane after a failure or an unfavorable review.

## Ordered procedure

1. Begin only with an approved design and an approved plan.
2. Decompose the plan into bounded tasks with explicit ownership and proof.
3. Call `witch_route` before every implementation or research work dispatch. Record the route output and decisive reason. Security-sensitive work routes to `witch-security`; research that does not mutate the worktree routes to `witch-researcher`; all other work follows the tool's fixed selection between `witch-routine` and `witch-complex`.
4. Fill every section of the [Dispatch Envelope](references/dispatch-envelope.md), then dispatch the selected work lane without model, reasoning-effort, or permission overrides.
5. Verify the returned diff, owned-file boundaries, and test evidence as controller. Do not treat an implementer's report as proof.
6. Dispatch a fresh `witch-task-reviewer` using the closed [Review Contracts](references/review-contracts.md).
7. On `repair`, send the bounded findings to the same implementation lane, then dispatch a fresh `witch-re-reviewer`. Repeat only within the repair breaker. Never automatically promote the repair to a different work lane.
8. When the task verdict is accepted or all load-bearing findings are closed, record the task, route, evidence, review verdicts, repairs, and residual risks in the ledger.
9. After every task is complete, dispatch a fresh `witch-final-reviewer` over the whole change set. Final-review repairs return to their original implementation lane and require a new fresh final review.
10. Ship only on `FINAL VERDICT: ship`. Stop when the repair breaker trips, when approval is required, or when the final verdict is `redesign`.

The complete sequence is: approved design → approved plan → task decomposition → `witch_route` → Dispatch Envelope → selected work lane → controller diff/test verification → `witch-task-reviewer` → bounded same-lane repair + `witch-re-reviewer` → ledger completion → fresh `witch-final-reviewer` → ship.

## Breaker

Two unsuccessful repair rounds for the same load-bearing finding trip the breaker. Stop delegation, preserve the evidence and open finding in the ledger, and report the block to the user. Do not route again or change lanes as an automatic escalation.

From muratmirgun/witch, Apache-2.0.

More from muratmirgun/witch