| name | create-subagent |
| description | Roster ArmY sub-agents from a natural-language description. Use when the user wants to create, add, rename, or reconfigure ArmY sub-agent roles (e.g. "create an intern using SW 1.7 from Devin", "add a UI designer on Fable low with the frontend skill"), or when another skill needs a role registered in SUB_AGENTS.md. |
| allowed-tools | ["read","edit","grep","glob","exec"] |
| permissions | {"allow":["Exec(bun run src/cli.ts detect)","Exec(bun run src/cli.ts list)","Exec(bun run src/cli.ts doctor)"]} |
Turn the user's spoken roster — a list of roles like "an intern using SW 1.7 from Devin, a manager using Fable low" — into concrete agent entries in SUB_AGENTS.md. The roster is confirmed role by role before anything is written.
1. Ground the roster in reality
Run bun run src/cli.ts detect --json (or army detect --json) and read the current SUB_AGENTS.md frontmatter. This gives you the installed harnesses, their real model IDs, and their mapped thinking levels.
Resolve each spoken role against that output:
- Harness — the CLI named ("from Devin" →
devin) or the harness whose catalog contains the spoken model.
- Model — fuzzy-match the spoken name to a detected model ID ("Sol" →
gpt-5.6-sol, "SW 1.7" → the closest sw/swe ID). Only IDs from detection or the existing config are candidates; when nothing matches, carry the mismatch into the confirmation step as an open question.
- Thinking — the spoken effort ("low", "high") mapped through that harness's
thinking table; default when the harness maps none.
- Extras — skills or instructions the user attached ("with the frontend skill") become part of the role's Markdown instruction section.
- Escalation — slot the role into the existing ladder (
intern → jr-dev → sr-dev → manager, ui-designer → manager) unless the user placed it elsewhere.
Done when: every spoken role has a proposed {name, harness, model, thinking, escalateTo, instructions} tuple, each model/thinking value traceable to detection output or flagged as unresolved.
2. Confirm each role with the user
Present each proposed role through the ask-user-question tool, one question per role (batch up to 4 per call). Each question shows the resolved tuple and offers: accept, pick an alternative candidate (when the fuzzy match was ambiguous), or adjust. Unresolved models from step 1 are asked here, never guessed.
Done when: every role in the roster has an explicit user answer — accepted, amended, or dropped.
3. Write SUB_AGENTS.md
SUB_AGENTS.md is the single source of truth for the schema — mirror the structure already in it rather than inventing fields. For each confirmed role:
- add or update its entry under
agents: in the YAML frontmatter (description, harness, model, thinking, surface, timeoutSeconds, verification, escalateTo);
- add or update its matching
## role-name Markdown section with the role instructions, written in the same voice as the existing sections;
- keep untouched roles byte-identical.
Done when: every confirmed role appears in both the YAML and a matching Markdown section, and no unconfirmed role was written.
4. Verify
Run bun run src/cli.ts list — it loads and validates the config (missing verifications, missing escalation targets, and cycles are rejected at load). Show the resulting table to the user.
Done when: list exits zero and every confirmed role appears in its output.
