Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/dheerg/swarms/create-workflowgit clone --depth 1 https://github.com/DheerG/swarmsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00013 | $0.05702 |
| Opus 5 | $0.00006 | $0.02851 |
| Sonnet 5 | $0.00003 | $0.01140 |
| Haiku 4.5 | $0.00001 | $0.00570 |
Grade A, and why
create-workflow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 415 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/swarm:create-workflow
You are scaffolding a custom swarm workflow. This generates two files in the user's project:
- A mode skill (
.claude/skills/<name>-mode/SKILL.md) — the domain-specific operational spec - A shortcut command (
.claude/commands/<name>.md) — the entry point users invoke
The interaction model is generate first, edit after. Ask the minimum needed to infer the full spec, generate everything, then let the user adjust.
Step 0: Gather
$ARGUMENTS
If $ARGUMENTS contains a name and description (has sentence structure, verbs, or a separator like write-article — takes raw thoughts and produces a polished blog post): extract both and proceed directly to Step 1.
If $ARGUMENTS appears to be a name only (kebab-case identifier, no verb or sentence structure — e.g., write-article): use it as the workflow name. Ask one question (plain text): "What does this workflow do? What does the user get at the end?" Wait for their response. Then proceed to Step 1.
If $ARGUMENTS is empty: ask one question (plain text): "What's this workflow called, and what does it do? (e.g., write-article — takes raw dictated thoughts and produces a polished blog post)" Wait for their response. Parse the name and purpose. Then proceed to Step 1.
Validate: the name should be kebab-case. If not, convert it silently.
Step 0.5: Determine Workflow Type
Before inferring the spec, decide whether this workflow should be a thin wrapper (extension of a built-in mode) or a full custom mode.
Infer the closest built-in mode from the purpose:
- Writing / editing / documentation / narrative →
swarm:writing-mode - Code / engineering / building / debugging →
swarm:code-mode - Anything else (research, synthesis, evaluation) →
swarm:general-mode
Use AskUserQuestion:
- question: "How should this workflow be structured?"
- header: "Type"
- options:
- label: "Thin wrapper over [inferred base] (Recommended)" description: "Inherits phase arc, lead identity, and facilitator from the base. You add intake (Pre-flight actions), an outcomes question, and additive Mode-Specific Rules + Suggest-Members Guidance. Stays in sync with swarm updates."
- label: "Full custom mode" description: "Use when the workflow needs custom phase semantics, a distinct lead identity, or substantial domain governance. More surface to maintain; runs /swarm:update-workflow to stay current on wiring."
- label: "Wrapper — pick a different base" description: "Create a thin wrapper but choose the base mode explicitly."
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 415 lines · 13 tokens per session scan A 77ff2b2ca0c0
create-workflow is a command published in the GitHub repository DheerG/swarms (86 stars, last pushed 1mo ago), licensed MIT. It adds 13 tokens to every session and 5,702 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
prompt
System instructions for writing effective prompts. Apply when generating commands, skills, agents, or any LLM instructions.
full
Run the full hope pipeline — intent, shape, target, freeze as needed — then execute.
token-review
Analyze SDLC token usage from .claude/sdlc/token-log.json (last run) and token-history.jsonl (rolling). Surfaces the biggest cost centers and concrete optimization candidates. Read-only.
start
Activate the SDLC workflow (opt-in), re-enable after suspension, or start a new task when already enabled. On fresh install — auto-detects repo/CI/stack/tracker (≤3 prompts), creates .enabled, takes a one-sentence task description, and auto-generates scope.md and a draft plan. On re-enable — verifies the suspension…
build
Start Phase 4 — implement the approved design with surgical-edit discipline and work-item traceability.
configure
Guided setup for config/tools.json and config/tools.local.json. Replaces manual file editing for first-time setup and common reconfigurations. Auto-invoked on fresh install (Layer 0) and when a command finds its required config missing (Layer 2). Safe to run anytime for proactive changes.