Agent SwarmTemplates

Swarm Docs

Skill
v1.0.0

docs.agent-swarm.dev index: general docs, guides and playbooks, when to offer a playbook or guide to a person, and how to fetch a page. Load on demand: when no existing skill, workflow, schedule or memory covers a person's request, or they ask where something is documented.

docs
playbooks
guides
lead

Template Content

Swarm docs

docs.agent-swarm.dev documents Agent Swarm: general docs, guides, and playbooks. A playbook is a tested way to run the swarm for one job (on-call, PR review, DORA metrics). Its page lists the agents, workflows, schedules and scripts to set up. The index below is generated from the docs frontmatter and ships with this release, so you can read it offline.

When to load this skill

Load it on demand. Load it when a person asks for something that no skill, workflow, schedule or memory of yours covers, or asks where something is documented. When you already know how to handle the ask, handle it and leave the docs out.

Offer a page (lead)

Follow these rules when you reply to a person.

  1. Offer only in a reply to a person's request (Slack, DM, dashboard, email). Never offer in a heartbeat, schedule, workflow step, worker follow-up, or task output.
  2. Offer only on a clear match with an entry's when line, and never on a not when match. With two candidates, offer the better one. Never offer a list.
  3. Make at most one offer per reply. Offer a page at most once per thread, and never again after a no.
  4. Skip the offer when the setup is already in place (list-workflows or the schedules list shows it), when one of your skills already covers the ask, or when the person already chose an approach.
  5. Put the offer in one sentence at the end, with the title and the link: "This matches the Open Oncall playbook. Want me to set it up that way?" For a setup request, wait for the answer before you build. For a question, answer it and add the link without asking.
  6. On yes, delegate to a worker: "Follow <page URL>. Read the page with the swarm-docs skill." Name the template when the entry has one.

Entries marked "reference" are never offered. Read them when a task touches their topic.

Read a page (any agent)

Fetch the page as markdown: curl -fsSL https://docs.agent-swarm.dev/llms.mdx/docs/<slug>, where <slug> is the path after /docs/ in the index link. Follow the page; it names the agents, templates, schedules and scripts to create.

  • A 404 means the slug changed after this release. Fetch https://docs.agent-swarm.dev/llms.txt and find the page by title.
  • When the site is unreachable (an offline or air-gapped install), say so in one line, give the page URL, and ask the requester to attach the page. An operator can host docs-site/ from the agent-swarm repo as a mirror and edit this skill to point at it; the edit survives reseed.
  • A template entry names a template that ships with the swarm (templates/<id> in the agent-swarm repo). Prefer it over writing the setup from scratch.
<!-- docs-index:start --> <!-- Generated by `bun run build:docs-index` from the docs frontmatter. Do not edit by hand. -->

Playbooks

  • Playbooks. Reference.
  • The rulebook our lead agent wrote for itself. Reference.
  • Feature Development. When: Someone wants feature requests from Slack or Linear turned into reviewed pull requests end to end.
  • Lead Prospecting. When: Someone wants prospects found and outreach drafted on a schedule, with a person approving before anything sends.
  • Content Generation. When: Someone wants blog posts, social posts, comparison pages or release notes written on a regular cadence.
  • UX Command Center. When: Someone wants regular UX audits of their product and proposals for usability fixes.
  • Proactive Customer Support. When: Someone wants an agent per key customer that remembers the account and prepares briefings or value reports.
  • Observability Alert Management. When: Someone wants Datadog, Sentry, New Relic or SigNoz alerts filtered for noise, plus recurring production health audits. Not when: Alerts that page a person and should be investigated and fixed as they fire; offer Open Oncall instead.
  • Code Health. When: Someone wants a recurring report on code hotspots, churn or technical debt in a repository. Template: community/code-health-reports.
  • DORA Metrics. When: Someone wants deploy frequency, lead time or other DORA metrics reported on a schedule. Template: community/dora-metrics.
  • Reports from Multiple Sources. When: Someone wants business questions answered across their warehouse, analytics, billing and other data, with charts.
  • Self-Documenting & Release Reports. When: Someone wants docs kept current, release notes written from commits, or release videos made.
  • Open-Prompt Showreel Videos. When: Someone wants a motion-graphics or showreel video made from a prompt. Template: community/open-prompt-showreel.
  • Email Domain Health. When: Someone wants the domains they send email from watched for SPF, DKIM, DMARC or blocklist problems.
  • Open Oncall. When: Someone wants alerts from PagerDuty, Datadog, Sentry or a webhook investigated and fixed, with a person approving each fix. Not when: A one-off question about a single incident.
  • PR Review. When: Someone wants every pull request reviewed automatically before a person looks at it.
  • Linear Delivery Loop. When: Someone wants agents to take Linear issues through implementation, CI and review to merged pull requests, with a person approving each one. Template: community/linear-delivery-loop.
  • Slack Reply Gate. When: Someone wants Lead to stop answering or waking on Slack thread banter, reactions, or messages meant for other people. Not when: Someone wants to route Slack messages to a specific agent or channel, which is a pre.slack.route extension.
  • Hot Patterns. Reference.
  • Pattern: Litmus Tests (LLM-as-Judge Quality Gates). When: Someone wants one agent to check another agent's output against a rubric before it ships.
  • Pattern: Drain Loops (Stacked PRs + Merge Loop). When: Someone wants a large change split into small stacked pull requests and merged in order.
  • Pattern: HITL Gates (Human-in-the-Loop Approval). When: Someone wants a workflow to wait for a person's approval before it sends, merges, deletes or posts.
  • Pattern: Per-Customer Working Directories. When: Someone wants agents to keep long-lived notes per customer or account.
  • Pattern: No-op When Nothing Changed. When: Someone wants a scheduled job that stays silent when nothing changed.

Guides

Other docs

<!-- docs-index:end -->