run

A sprint-execution command that runs planned development work in waves, using worker agents in separate working directories and review gates.

In plain words
What is it for?
It runs eligible sprint tasks, coordinates worker branches, and brings completed work through the configured review and merge process.
Why use it?
It organizes parallel implementation while checking repository state and configured review requirements before work begins.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/ushibo/brigade/run
Clone the repo
git clone --depth 1 https://github.com/ushibo/brigade
Per session 20 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 4,687 The whole file, excluding the scripts and references it only reads on demand.
Security scan B 1 finding. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00020 $0.04687
Opus 5 $0.00010 $0.02344
Sonnet 5 $0.00004 $0.00937
Haiku 4.5 $0.00002 $0.00469

Measured yesterday against content hash 77bf180f4a03, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade B, and why

run scanned grade B with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Reads agent configuration directoriesmediumAgent snooping

.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.

> Workers will run in **foreground** mode — you will see their progress live and may be asked to approve some tool calls (Write, Bash for git/test runners). Approve with "Allow for session" on the first call of each kind
commands/run.md · 412 lines

How it starts

The opening of the file, as written. The whole thing — 412 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You are executing the current sprint directly in the top-level conversation. Do not delegate orchestration to manager-agent — Claude Code subagents cannot spawn further subagents, so the top-level session must drive the wave-by-wave execution itself.

Preflight

  1. Verify .planning/tasks/ROLES.md exists. If missing, tell the user to run /brigade:init first and stop.

  2. Verify the working tree is clean (git status). If dirty, ask the user to commit or stash and stop.

  3. Confirm you are on main or master. If not, ask the user to check out the base branch and stop.

  4. Read .planning/config.json if it exists. Parse config.review.mode (default full) and config.review.agents (for mode: custom). Used below to decide which reviewers to spawn at the merge gate.

  5. Tell the user about the permission flow before starting. Print a short notice:

    Workers will run in foreground mode — you will see their progress live and may be asked to approve some tool calls (Write, Bash for git/test runners). Approve with "Allow for session" on the first call of each kind; Claude Code remembers it and subsequent calls will not prompt. The main conversation is blocked while a wave runs — you can move workers to background with ctrl+b if you need the chat free, but then preapprove the required tools in ~/.claude/settings.json first.

    Then proceed.

Step 1 — Find the current sprint and wave

  1. List .planning/tasks/sprint-*/ and pick the highest-numbered sprint as current. Read its _README.md.
  2. Read .planning/tasks/ROLES.md into memory — you will need the role → agent mapping later.
  3. Sync statuses with git history. Run git log --oneline on the current branch. For every task spec in the sprint whose status: is still todo, check whether any commit message contains its task id (e.g. s1.3). If yes, update that task's frontmatter to status: done and mark it done in _README.md. Commit the status updates to the base branch with message chore: sync sprint statuses.
  4. Identify the current wave: the lowest-numbered wave that still has tasks with status: todo. If every task is done, skip to Step 4 "Final verification".

Read the full file on GitHub · 412 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 412 lines · 20 tokens per session scan B 77bf180f4a03

Subscribe to this mod's changes

run is a command published in the GitHub repository ushibo/brigade (1 stars, last pushed 1mo ago), licensed MIT. It adds 20 tokens to every session and 4,687 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it B with 1 finding (reads agent configuration directories). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.