`##agent spawn-all`: hire a whole team from a folder of markdown

One folder of .md files, one command, a full roster of specialist agents. Onboarding a team is now a git clone.

Yesterday's post showed that in rysh, one agent is one markdown file (https://rysh.ai/blog/agents-from-a-markdown-file). Today: what happens when you stop thinking in files and start thinking in folders.

##agent spawn-all ./agents

That's the whole command. rysh parses every .md file in the directory and spawns an agent from each one. A folder becomes a team.

The team-in-a-folder pattern

Here's what a repo's agents/ directory tends to grow into once this exists:

agents/
├── code-reviewer.md     # correctness-first, quotes exact lines
├── test-writer.md       # table-driven tests, hates mocks it didn't need
├── docs-agent.md        # keeps README and docs honest against the code
├── release-notes.md     # reads merged PRs, drafts human release notes
├── refactor-scout.md    # flags duplication, proposes consolidations
└── oncall-helper.md     # reads logs and configs, drafts incident notes

Each file: YAML frontmatter (name, description, optionally model) on top, the system prompt below. Files without frontmatter still work — the whole file becomes the system prompt and the filename becomes the agent's name.

Run spawn-all and every one of them comes up as a headless worker in your session — no PTY, no window clutter, each with its own execution loop and standing orders. Then:

##agent list

That's your roster. Address anyone on it by name from any pane:

@test-writer the new codec paths need coverage
@release-notes draft notes since v0.1.24
@@refactor-scout deactivate     # bench the noisy one for today

Onboarding is a git clone

Here's where this stops being a convenience and starts being a team practice.

Because the team is a folder, and the folder lives in the repo, joining a project means inheriting its agents:

git clone git@github.com:yourorg/yourservice.git
cd yourservice
rysh
##agent spawn-all ./agents

New teammate, day one, has the same reviewer with the same standards, the same test-writer with the same conventions, the same docs agent that knows the README's structure. Not "here's our prompt library in Notion, copy-paste what you need" — the working configuration, versioned, identical for everyone.

And when someone improves an agent — tightens the reviewer's standards, teaches the test-writer the team's fixture conventions — that improvement ships as a pull request. Everyone's roster upgrades on the next pull. Agent quality compounds the way code quality does, because it's stored the same way. (More on that in https://rysh.ai/blog/agents-live-in-git.)

Managing the roster

A team you can hire in one command needs day-two operations, and they're all there:

##agent list                       # who's on the roster, who's active
@@docs-agent deactivate            # benched: stays defined, ignores prompts
@@docs-agent activate              # back in
@@code-reviewer stop               # cancel its current task, keep the agent
##agent delete refactor-scout      # actually gone
##agent register-output code-reviewer   # its replies → this pane's chat stream

That last one matters for sanity at team scale: each rysh pane keeps separate output streams per mode, so agent replies land in a chat stream — never spliced into your shell output. Six agents reporting doesn't mean six windows or one unreadable scroll; it means you decide which pane is the newsroom.

deactivate earns its keep faster than you'd think. Not every agent should run every day. The release-notes agent matters on release day; the oncall-helper matters when things are on fire. A roster with a bench is a roster you can afford to keep broad.

Why per-repo teams beat one super-agent

The tempting alternative is one generalist agent with a 4,000-line system prompt that knows everything. Teams that try it learn the same lesson prompt-writers keep relearning: instructions dilute each other. The reviewer's "be ruthless about correctness" and the release-notes agent's "be warm and readable" do not want to live in one prompt.

Small, single-purpose agents with short, sharp standing orders — one per file — are easier to write, easier to review in a PR, and easier to blame when behavior drifts. The folder is the org chart. spawn-all is just the hiring paperwork.

The honest part

rysh runs on Claude — you bring your own Anthropic key — and it's self-hostable on your own infra. spawn-all doesn't conjure a senior team out of thin air: six mediocre prompts spawn six mediocre agents, very efficiently. What it changes is the economics of iteration — when improving an agent is editing a file, and distributing the improvement is git push, your prompts actually get better over time instead of rotting in a dashboard.

Hire in one command. Improve by pull request. That's the loop.

rysh is in private beta. If your repo deserves its own agent team, we're onboarding design partners — free access, direct line to the founder: https://rysh.ai/design-partner

Related: Autonomous agents from a markdown file · Your agents live in git: skill files are source code