agent-roster
Skill2 starsChanged 34 days agoMITView on GitHub
Load BEFORE spawning subagents, splitting a task into parts, using the Agent/Task tool, or getting work reviewed. It shows which other coding agents and models are on this machine (Claude Code, Codex, Cursor, Antigravity/Gemini, Jules, local models), their logins and quota left, and the user's routing rules, so you pick the right worker and tier instead of defaulting to copies of yourself. Also use when choosing a model, asking for a second opinion, or when the user mentions other agents, subscriptions or usage limits.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- demirelo/agent-rostertheir own version, first seen Nov 8, 2026
- wjgoarxiv/litopencodetheir own version, first seen Oct 13, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- wjgoarxiv/litopencode★ 2same name
- demirelo/agent-roster★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 17
If no snapshot appears above (your agent doesn't run inline commands), run probe.mjs, which sits in the same directory as this SKILL.md:
- Distinctive: line 27
Read the snapshot and roster.
- Distinctive: line 47
If the roster is wrong (plan changed, a CLI was added or broke), fix it and tell the user.
- Distinctive: line 53
When routing goes wrong (the user corrects a pick, a handoff fails, or the snapshot misreported something), including when the user tells …
- Very specific: line 68
If feedback.mjs says feedback is off, don't offer.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agent roster
Shows what agents and model subscriptions are available here, what state they are in, and how to hand work to each, whichever agent you are.
Live snapshot
!node "${CLAUDE_SKILL_DIR}/probe.mjs"
If no snapshot appears above (your agent doesn't run inline commands), run
probe.mjs, which sits in the same directory as this SKILL.md:
node <this skill's directory>/probe.mjsIt prints live status, then the user's roster (or an example if they haven't written one).
How to use it
- Read the snapshot and roster. Live status (logins, quota windows, versions) beats the curated notes.
- Identify yourself: your model, not just the harness, its vendor, and its tier (frontier or fast). The snapshot's "invoked from" names the harness only.
- Pick a target from the roster's routing table for this task. Recommend; don't default to your own vendor. For reviews prefer another vendor; if none is usable, use a separate stronger reviewer and say it isn't independent.
- Respect the user's usage rules in the roster. If a plan is heavy (many subagents, top models at max effort, a lot of unapproved quota), say what, why and the rough scale, and ask first.
- Hand off with a recipe from
handoff.md(same directory). This skill picks who does the work. If another installed skill covers how to do it (a code-review procedure, a parallel-dispatch or planning workflow), load that one too and follow it with the worker chosen here. - Afterwards, tell the user who did what and how it went, and add one line to the roster's Track record.
- If a pick went wrong (the user corrected it, a handoff failed, or the user reports an earlier recommendation failed): after fixing the routing, offer once to send feedback. See Feedback below; it's one line, not a pitch.
If the roster is wrong (plan changed, a CLI was added or broke), fix it and tell the user. If there's no personal roster yet, offer once to create it from the example.
Feedback
When routing goes wrong (the user corrects a pick, a handoff fails, or the snapshot misreported something), including when the user tells you an earlier recommendation failed, first fix the routing, then offer once per session in one line, e.g.:
Want me to send a note about this misroute to the agent-roster maintainers? It includes your routing table and track record (emails and paths scrubbed). Yes / not now / never.
- Yes:
node <dir>/feedback.mjs "<one sentence: what went wrong, what should have happened>", thennode <dir>/feedback.mjs --send. Tell the user what was sent and give the issue link (or the prefilled link it prints). - Never:
node <dir>/feedback.mjs --off, then stop offering. - Not now: drop it for this session.
If feedback.mjs says feedback is off, don't offer. Don't offer for problems
on the user's side (a CLI not logged in, a quota running out); those aren't
routing defaults.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.