warren: Skill for Claude Code

Protocol: Warren Dogfood Dispatch Pipeline

You run a themed slice of the seeds backlog end-to-end through the live warren instance: audit → ordered dispatch list → sequential runs → PR shepherding → tracker closure. Every run on the public instance is also demo content, so prefer dispatching warren runs over doing the work locally — including for repairs. The pipeline was proven 2026-07-28 (deletion pass: 9 issues, 15 runs, PRs #650–#658, plan pl-3a79 closed).

0. Inputs (ask if not given)

• Focus theme + priority band — e.g. "P0/P1 deletion-focused", "security leaks", "docs drift". This drives the audit lens.
• Agent + model/provider — ALWAYS stop and ask the operator (AskUserQuestion) which model + provider to use for all tasks in the session, even when every other input was given. Recommended default: provider openrouter, model moonshotai/kimi-k3, on the pi harness (the only harness that can reach OpenRouter; it is also the project defaultRole). Offer the anthropic tiers (src/registry/builtins/model-tiers.ts) as alternatives — for hard or large refactors use claude-opus-5 (Opus 5; pass it as an explicit modelOverride — do NOT rely on the opus tier's default, which still pins the older claude-opus-4-8). Dispatch with explicit providerOverride + modelOverride matching the answer.
• Dispatch mode — sequential one-at-a-time (default, what the operator chose last time) vs parallel. Sequential means: next issue run dispatches only after the previous run is TERMINAL; repair runs are exempt and may overlap.
• Blocked issues — skip them, or dispatch their blockers first (last time: blockers first).

Report your understanding and the candidate list BEFORE dispatching anything. Dispatching costs real money and opens real PRs.

1. Phase 1 — Audit & prioritize (subagent)

Spawn a subagent that invokes the seeds-issue-audit skill, with an extra deliverable bolted on: a DELETION-DISPATCH-LIST-style section for the focus theme — every still-open, in-theme issue with LIVE blocker resolution (a closed blocker doesn't count; re-check each edge) and a serial dispatch order, blockers first, sequenced so each run can build on the previous merge. Require the exact line format <order>. <id> — <title> — <UNBLOCKED | blocked-by: ids> so you can dispatch straight off it.