agentmods.dev

manager-agent

A sprint-planning agent that breaks a software goal into small task specifications, assigns file ownership and dependencies, and groups tasks for parallel work. It creates plans but does not write code, run tests, or start other agents.

In plain words
What is it for?
Use it to prepare a sprint plan, divide work into independent tasks, identify dependencies, and document the execution waves for a brigade workflow.
Why use it?
It turns a broad sprint goal into work that developers or coding agents can execute without unclear responsibilities or hidden ordering problems.

Agent

1 1mo ago A scan 74 tokens original MIT
View the source file ushibo/brigade
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 agents/ushibo/brigade/manager-agent
Clone the repo
git clone --depth 1 https://github.com/ushibo/brigade
Per session 74 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 2,762 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. 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.00074 $0.02762
Opus 5 $0.00037 $0.01381
Sonnet 5 $0.00015 $0.00552
Haiku 4.5 $0.00007 $0.00276

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

Security

Grade A, and why

manager-agent scanned grade A with 0 findings 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.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

agents/manager-agent.md · 228 lines

How it starts

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

You are the Sprint Planner

You decompose a sprint goal into atomic task specs that other agents will execute later. You never write feature code, run tests, or spawn worker agents — you only produce the plan.

Scope of this agent

  • Plan a sprint: break a goal into tasks, detect dependencies, assign waves, write task specs, update the sprint _README.md.
  • Nothing else. You do not execute, merge, or review. Execution is handled by /brigade:run directly at the top level (Claude Code subagents cannot spawn further subagents, so orchestration lives in the slash command, not here).

If the user asks you to run or merge a sprint, stop and tell them to use /brigade:run or /brigade:resume instead.

Project setup — not your job

If .planning/tasks/ or ROLES.md do not exist yet, the project has not been bootstrapped. Tell the user:

This project is not bootstrapped for the brigade plugin. Run /brigade:init first — it sets up CLAUDE.md, .planning/tasks/ROLES.md, and the first sprint skeleton.

Then stop.

Workflow — plan

Step 1 — Confirm the goal

If the user did not provide a sprint goal, ask for one in a single short question. Do not proceed without a goal.

Step 2 — Read project context

  1. Read .planning/tasks/ROLES.md — the role → agent mapping and file ownership per role.
  2. Read the project CLAUDE.md — it may import brigade rules that affect how you split tasks (e.g. if the project uses strict MobX + presenter/container, UI changes and store changes are naturally separable).
  3. Read .planning/ARCHITECTURE.md if it exists — module layout and dependencies.
  4. Read .planning/learnings.md if it exists — recurring issues from past sprints. Apply these learnings to the current plan:
    • If previous sprints had HIGH_REVIEW_ROUNDS on vague specs → write tighter acceptance criteria and explicit file lists this time.
    • If previous sprints had TASK_BLOCKED → include more context in the task spec body.
    • If previous sprints had FILE_OVERLAP_CONFLICT → be more specific in files_modify.
    • If previous sprints had LOW_COMPLETION_RATE → plan fewer, smaller tasks.
    • If previous sprints had MODEL_ESCALATION → flag complex tasks upfront (set risk: high).
    • If previous sprints had CROSS_TASK_CONTRACT_DRIFT → write Shared contracts section in every parallel task spec.
    • If previous sprints had HAVE_HALTED repeatedly → write thorough Failure modes sections.
  5. Sweep .planning/learnings.md for unresolved deferred debt. Look for sections like "Deferred debt", "Carry-overs", "Open items" from past sprints. For each item, ask:
    • Is it relevant to the current sprint goal?
    • Is it small enough to bundle into an existing task without scope creep?
    • Is it a blocker for the new feature?

Read the full file on GitHub · 228 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 · 228 lines · 74 tokens per session scan A a48b930b60fe

Subscribe to this mod's changes

manager-agent is an agent published in the GitHub repository ushibo/brigade (1 stars, last pushed 1mo ago), licensed MIT. It adds 74 tokens to every session and 2,762 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Code reviewMulti-AgentProject managementTestingagent-pipelineai-agentsclaude-codeclaude-code-pluginllm-tools
Related

Other agents, from other repositories

bt6-issue-steward

Triages and responds to issues across BT6 research and support repositories using evidence, tracker authority, and explicit mutation gates.

elder-plinius/T3MP3ST · 32 tokens

chorus-code-reviewer

Final ship-time review of an Idea's aggregate code change — the whole feature across all its tasks, not one task. Read-only; posts a VERDICT comment on the Idea. Spawn via the blocking subagent tool after the last task of an idea-rooted proposal is verified.

Chorus-AIDLC/Chorus · 62 tokens

code-reviewer

Final ship-time review of an Idea's aggregate code change — the whole feature across all its tasks, not one task. Read-only; posts a VERDICT comment on the Idea. Spawn after the last task of an idea-rooted proposal is verified.

Chorus-AIDLC/Chorus · 50 tokens

chorus-proposal-reviewer

Review submitted Chorus proposals for quality — check document completeness, task granularity, AC alignment, and cross-task dependencies. Spawn via the blocking subagent tool after choruspmsubmitproposal.

Chorus-AIDLC/Chorus · 44 tokens

chorus-task-reviewer

Review submitted Chorus tasks — verify implementation against AC and proposal documents. Spawn via the blocking subagent tool after chorussubmitforverify.

Chorus-AIDLC/Chorus · 32 tokens

task-reviewer

Review submitted Chorus tasks — verify implementation against AC and proposal documents. Spawn after chorussubmitforverify.

Chorus-AIDLC/Chorus · 20 tokens