Squad Run
Execute squad backlog items through a fixed multi-agent pipeline instead of one-off manual coding in chat.
Overview
squad-run is an agent skill most often used in Build (also Ship review and testing) that executes squad tasks through a six-agent, seven-column orchestration loop triggered by /squad-run.
Install
npx skills add https://github.com/steloit/squad-skills --skill squad-runWhat is this skill?
- Seven-column squad pipeline with six roles: Planner, Critic, Builder, Shield, Inspector, Ranger
- Auto-triggers on task IDs with implement/build/do phrasing or yes/ok after a proposed task
- Forbids manual implement-then-patch workflow—must invoke /squad-run for governed state
- Single-step execution loop with shared squad context from sibling squad skills
- Confirmation capture after Claude proposes a specific task number must route to squad-run automatically
- 6 specialized agents (Planner, Critic, Builder, Shield, Inspector, Ranger)
- 7-column pipeline
Adoption & trust: 1 installs on skills.sh.
What problem does it solve?
You have numbered squad tasks on a board but the coding agent keeps implementing outside the pipeline and breaking status and review gates.
Who is it for?
Indie builders using the squad board who want automatic routing from “implement #123” or “yes” confirmations into the full agent pipeline.
Skip if: One-off scripts with no squad task IDs, repos without the squad shared context stack, or work you intentionally want to hack without board state.
When should I use this skill?
User says /squad-run, implement/build/do task NNN, next task/continue on squad work, or confirms yes/ok/go/do it after Claude proposes implementing a specific squad task.
What do I get? / Deliverables
A task moves through governed agent steps with code review and safety roles, with /squad-run as the single execution entry instead of ad-hoc patches.
- Pipeline-step execution for one squad task
- Board-aligned status transitions
- Agent-mediated implementation and review artifacts
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build agent-tooling because the skill’s core job is orchestrating implementation agents against squad tasks. squad-run is pipeline control for your AI squad—planner-to-ranger steps map to how indie builders run agentic delivery tooling.
Where it fits
User says implement task #215 and squad-run pulls board context then advances Builder with Planner output.
Inspector and Critic agents run as part of the same /squad-run pass before a task is marked done.
Shield-oriented checks in the pipeline gate risky changes before merge during squad execution.
User says continue or next task to resume the orchestration loop on the following todo without manual state edits.
How it compares
Structured multi-agent workflow with board state—not a single-purpose code generator or a lint-only checker.
Common Questions / FAQ
Who is squad-run for?
Solo builders and small teams running Steloit squad tasks who need Planner-through-Ranger execution with board-aligned status updates.
When should I use squad-run?
Use it in Build when implementing a squad task ID; in Ship when Inspector and Shield gates matter; and whenever you confirm yes/ok/go after Claude names a specific task to implement.
Is squad-run safe to install?
It orchestrates agents that may edit code and call squad APIs—check the Security Audits panel on this page and your squad endpoints before granting network or repo access.
SKILL.md
READMESKILL.md - Squad Run
## Auto-Trigger Rules **ALWAYS invoke this skill (without waiting for `/squad-run`) when:** 1. User mentions a squad task ID and requests implementation: - "implement task #NNN" / "build task NNN" / "do NNN" / "run NNN" - Any message pairing a task number with implement / build / work on / do 2. Claude has proposed implementing a specific squad task and the user confirms: - Pattern: Claude says "Shall I implement task #NNN [title]?" → User replies "yes", "ok", "go", "do it" - This confirmation **must** trigger `/squad-run <ID>` automatically — do not implement manually 3. User says "next task" / "continue" when a task is in progress: - Fetch board context first, identify next todo task, then run it **When auto-triggered**: extract task ID and call `/squad-run <ID>` — never implement code manually and patch squad state afterward. > Shared context: read `../squad/shared.md` for pipeline levels, status transitions, API endpoints, error handling, and agent context flow. > Safety principles: read `../squad/principles.md` — **mandatory, not optional.** > Schema: read `../squad/schema.md` for full DB schema, column descriptions, and JSON field formats. ## Commands In Codex environments, this skill may be invoked directly as a slash command text such as `$squad-run <ID>` or `$squad-run <ID> --auto`. ### `/squad-run step <ID>` — Single Step Execute only the next pipeline step then exit. Same logic as `/squad-run` but no loop. ### `/squad-run <ID> [--auto]` — Run Full Pipeline **Default**: pause for user confirmation at Plan Review and Impl Review approvals. **`--auto`**: fully automatic (circuit breaker still fires). #### Orchestration Loop (Level-Aware) ``` Per-step contract (every agent step): record → gate → commit → side-effects. The agent records its verdict (approved/reject | pass/fail + comment) by POSTing the matching verdict endpoint; it does NOT move status. The orchestrator then: (1) reads the recorded verdict, (2) gates (default mode: the card SITS in its review state until the user signal; `--auto` skips the human gate only), (3) commits the move via the generic `PATCH /api/task/:id` to the verdict-correct next status with `current_agent:null` (re-issuing a move that is already applied is a safe no-op), (4) runs side-effects (git commit + note) AFTER the move. L1 Quick: todo → orchestrator PATCH {status:impl, current_agent:Builder} → Worker(builder) implements → orchestrator PATCH {status:done, current_agent:null} → side-effects (commit + note) L2 Standard: todo → [orchestrator: todo→plan, current_agent=Planner] → Plan Agent(planner) @plan → orchestrator PATCH {status:impl, current_agent:null} (skip plan_review) impl → Worker(builder) + TDD Tester(shield) → orchestrator PATCH {status:impl_review, current_agent:null} impl_review → Inspector returns verdict → orchestrator records → [user confirm] → orchestrator PATCH {status: done | impl, current_agent:null} → side-effects after done L3 Full: todo → [orchestrator: todo→plan, current_agent=Planner] → Plan Agent(planner) @plan → orchestrator PATCH {status:plan_review, current_agent:null} plan_review → Critic returns verdict → orchestrator records → [user confirm] → orchestrator PATCH {status: impl (approve) | plan (reject), current_agent:null} (reject re-dispatches Planner with <critic_feedback>; plan→plan re-entry is idempotent) impl → Worker(builder) + TDD Tester(shield) → orchestrator P