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 skills/khaledsaeed18/dotclaude/parallel-agentsnpx skills add KhaledSaeed18/dotclaude --skill parallel-agentsgit clone --depth 1 https://github.com/KhaledSaeed18/dotclaudeWhat 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.00068 | $0.00881 |
| Opus 5 | $0.00034 | $0.00441 |
| Sonnet 5 | $0.00014 | $0.00176 |
| Haiku 4.5 | $0.00007 | $0.00088 |
Grade A, and why
parallel-agents 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 3d 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 — 50 lines — stays where its author put it; the contents beside it link to each section on GitHub.
When you have several independent problems, investigating them one after another wastes time that could be spent in parallel. Hand each one to its own subagent with precisely the context it needs, let them work at once, then pull the results together. Each subagent should get exactly what you construct for it — never your whole session history — so it stays focused, and so your own context stays free for coordination.
When this applies — and when it doesn't
Dispatch in parallel when the problems are genuinely independent: different test files failing for different reasons, separate subsystems broken on their own, distinct bugs that can each be understood without the others. The test is whether fixing one could change another. If it can't, and they touch different code, they can run concurrently.
Don't reach for this when:
- The failures look related — fixing one might fix the rest. Investigate together first.
- You'd need the full system in view to understand any of it.
- You don't yet know what's broken (exploratory debugging — find the shape of the problem before fanning out).
- The tasks share state or would edit the same files; concurrent agents there collide.
The pattern
1. Split into independent domains. Group the work by what's actually broken — "tool approval flow", "batch completion", "abort handling" — such that each group can be fixed without reference to the others.
2. Write a focused task per domain. Each subagent prompt needs three things:
- Scope — one file or subsystem, named exactly. "Fix
agent-tool-abort.test.ts", not "fix the tests." - Context — the concrete failures: paste the error messages and failing test names, not a vague "the race condition."
- Constraints and expected output — what it may and may not change ("fix the tests only, don't touch production code"), and what to return ("a summary of the root cause and the changes you made").
3. Dispatch them concurrently. Launch all the subagents in one batch so they run at the same time rather than in sequence.
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.
- 3d ago First seen · 50 lines · 68 tokens per session scan A 5cd5c5f669ca
parallel-agents is a skill published in the GitHub repository KhaledSaeed18/dotclaude (4 stars, last pushed 8d ago), licensed MIT. It adds 68 tokens to every session and 881 once invoked, about $0.0003 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-31.
Other skills, from other repositories
release
Cut a new playback-mcp release — version bump, changelog, dev-to-main PR, tag, and npm publish via CI. Use when asked to plan or ship a new release/version.
pr
Open a pull request from dev into main for this repo, following the repo's checklist and template. Use when asked to open/create a PR, or as part of the release flow.
pyenv-native
Manages Python runtimes and project venvs via pyenv-native and pyenv-mcp. Use when installing Python, fixing which-python/venv issues, setting .python-version, pip env problems on Windows/Linux/macOS, or when MCP pyenv-native tools are available.
rpg
Build and query semantic code graphs using RPG-Encoder. Use BEFORE grep/cat/find for any question about code structure, behavior, relationships, impact, dependencies, or cross-file patterns.
src
use when generating a doc the user will read and share — specs, roadmaps, pr explainers, research reports, plans, strategy docs. trigger words: "glyph," "spec," "roadmap," "explainer," "report," "plan," "save as a doc.".
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.