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/joris887/exosuit/parallel-worknpx skills add joris887/exosuit --skill parallel-workgit clone --depth 1 https://github.com/joris887/exosuitWhat 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.00082 | $0.02003 |
| Opus 5 | $0.00041 | $0.01001 |
| Sonnet 5 | $0.00016 | $0.00401 |
| Haiku 4.5 | $0.00008 | $0.00200 |
Grade A, and why
parallel-work 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 — 202 lines — stays where its author put it; the contents beside it link to each section on GitHub.
parallel-work
Manage parallel development streams. Each stream is an isolated copy of the project (a git worktree) on its own branch, so multiple Claude Code sessions can build different stories at the same time without touching each other's files.
When Parallel Work Makes Sense (and When It Doesn't)
Parallel work is opt-in, never required. The default workflow is one branch, one story at a time — that keeps the user fully aware of every change.
Good fit:
- Stories are self-contained: no dependencies on each other, no shared hot files
- Each story is a complete outcome on its own (outcome over output)
- The user is comfortable reviewing several streams of change
Bad fit — advise sequential work instead:
- Stories depend on each other (one needs the other's code or schema)
- Stories touch the same files or the same module's core
- The stories are parts of one mechanism (they should be ONE story, not parallel streams)
The start command checks this before creating anything (see below). When in
doubt, recommend sequential: merging conflicting parallel work costs more than
it saves.
Commands
Status (default, or "status"/"list")
Run the status script:
bash "${CLAUDE_PLUGIN_ROOT:-.claude}/skills/parallel-work/scripts/worktree-status.sh"
Show all active streams with their branches, their parent (from
git config branch.<name>.exosuitParent), and ahead/behind counts vs the parent:
### Active Streams
| Path | Branch | Parent | Ahead/Behind parent |
|------|--------|--------|---------------------|
| [path] | [branch] | [parent or "-"] | [+N/-M] |
**Options:**
- `/parallel-work start` — create new parallel streams
- `/merge-up` (inside a stream) — publish its work to the parent
- `/merge-down` (inside a stream) — pull the parent's accumulated work in
- `/parallel-work cleanup` — remove finished streams
Start — Create Parallel Streams
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 202 lines · 82 tokens per session scan A edda93cdc89d
parallel-work is a skill published in the GitHub repository joris887/exosuit (4 stars, last pushed 13d ago), licensed MIT. It adds 82 tokens to every session and 2,003 once invoked, about $0.0004 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
issue-triage
Issue triage: audit open issues, categorize, detect duplicates, cross-ref PRs, risk assessment, post comments. Args: "all" for deep analysis of all, issue numbers to focus (e.g. "42 57"), "en"/"fr" for language, no arg = audit only in French.
ship
Build, commit, push & version bump workflow - automates the complete release cycle.
pr-review
Batch review des PRs RTK par ordre de complexité croissante (XS → S → M → L). Pour chaque PR : vérifie l'état (conflits, CLA, reviews), lit le diff complet, analyse le code en contexte, présente un résumé avec lien + taille + recommandation. Attend validation explicite avant tout merge. Poste des commentaires…
rtk-triage
Triage complet RTK : exécute issue-triage + pr-triage en parallèle, puis croise les données pour détecter doubles couvertures, trous sécurité, P0 sans PR, et conflits internes. Sauvegarde dans claudedocs/RTK-YYYY-MM-DD.md. Args: "en"/"fr" pour la langue (défaut: fr), "save" pour forcer la sauvegarde.
code-simplifier
Review RTK Rust code for idiomatic simplification. Detects over-engineering, unnecessary allocations, verbose patterns. Applies Rust idioms without changing behavior.
build-teaql-app
Build or change a TeaQL application in Java, Rust, Go, Swift, Python, C#/.NET, or TypeScript, including Kotlin/JVM applications that consume Java-generated libraries. Mandatory order: first draft and save a complete KSML model, then verify the client and evaluate that saved model, repair it through repeated evaluation…