Roster
Use when a goal or plan is about to fan out to concurrent agents but names no lanes — no answer to who runs what, in what order, verified how — or when orchestration is requested while the intent itself is still vague.From its SKILL.md
npx -y skills add saadshahd/moo.md --skill rosterAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
2.7 KB, 556 tokens by cl100k_base, as published. Nobody here has run it
The stage before dispatch: elicit until the intent is solid, then project it onto the board as a flow roster — lanes, edges, acceptance — complete enough that a dispatcher re-derives nothing.
1. Intent check (skip when handed a solid plan)
Solid = you can state the goal, constraints, verification, non-goals, and risky surfaces from what the human gave you, without inventing any of them. Anything you'd have to invent, elicit:
- Interview one question at a time — each answer reshapes the next question, so batching an interview wastes the reshaping. Stop when answers stop changing the roster.
- Ask for what only the human holds: risk tolerance, deadlines, what must not change, how they'll judge done.
- A hole in intent becomes an open question on the board, never an assumption.
2. Cut the roster
- Lanes — disjoint scopes. A scope that overlaps everything (sync, codegen, formatting) is a lane behind a blocking edge, never a concurrent one.
- Edges — blocked-by dependencies, explicit per lane, never implied in prose.
- Acceptance per lane — one check the lane's handoff can be verified against.
- Model per lane — the tier each lane runs on: top tier only where the lane designs or adjudicates; polish, cleanup, mechanical execution, and standing seats run cheaper.
- The steward — merge/verify, ticket triage for mid-flight discoveries, and fleet-burn watch are a standing lane, not lead work. Expect tickets to appear mid-flight; the roster names who absorbs them so the lead never does.
- The serial rest — what stays with the lead or the human: gates, anything whose next step depends directly on a result, edits too small to brief.
Concurrency cap, waves, and spawn mechanics belong to the dispatch stage — never in the roster.
3. Project onto the board
With solo MCP: the plan goes to a scratchpad with scannable headings — Goal, Current understanding, Lanes and flow, Verification, Risky files, Decisions, Open questions — and each lane becomes a todo carrying its objective, owned scope, a pointer to its scratchpad section (never a copy), its acceptance check, blockers, and tags. Without solo: a plan file plus the task tracker, same shape.
A cold agent must be able to run the roster from the board alone.
4. Gate
Present to the human: the lanes, the edges, what stays serial, and every open question. The human locks the roster; an answer arriving at the gate goes onto the board first. No dispatch here.