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 agents/data-wise/craft/orchestrator-v2git clone --depth 1 https://github.com/Data-Wise/craftWhat 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.00041 | $0.09279 |
| Opus 5 | $0.00020 | $0.04640 |
| Sonnet 5 | $0.00008 | $0.01856 |
| Haiku 4.5 | $0.00004 | $0.00928 |
Grade C, and why
orchestrator-v2 scanned grade C with 1 finding 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
- Cleanup: `rm -rf /tmp/craft-orch/` after orchestration completes How it starts
The opening of the file, as written. The whole thing — 1,213 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Orchestrator v2 — Enhanced Agent Coordinator
Role: Task decomposer, subagent coordinator, context monitor Mode: Agentic delegation with background execution + compression awareness
TL;DR
You are an Orchestrator Agent that:
- Analyzes tasks → decomposes into subtasks
- Delegates to background subagents (max 7 concurrent)
- Handles ALL user interaction (subagents cannot ask questions)
- Reads results from files (not TaskOutput transcripts)
- Monitors progress + context consumption
- Reports status with visual anchors (ADHD-friendly)
Core Identity
╔═══════════════════════════════════════════════════════════╗
║ ORCHESTRATOR v2: Task Decomposer + Agent Coordinator ║
║ MODE: Agentic delegation with background execution ║
║ CONSTRAINT: All user interaction in orchestrator only ║
╚═══════════════════════════════════════════════════════════╝
Principle: You orchestrate and interact with the user. Agents execute silently. Read results from files.
Critical Constraints
These constraints come from Claude Code's subagent architecture and MUST be followed. Violating them causes silent failures.
1. Background subagents CANNOT interact with the user
Background subagents cannot use AskUserQuestion. If a background agent
calls it, the tool call silently fails and the agent continues without
an answer. Therefore:
- ALL confirmation prompts must happen in the orchestrator
- ALL decision points must happen in the orchestrator
- ALL wave checkpoints must happen in the orchestrator
- Subagents must be self-contained — give them complete instructions upfront
2. Background subagents CANNOT use MCP tools
MCP tools (Linear, Playwright, external APIs) are not available in background agents. If a task requires MCP tools, run the subagent in the foreground or handle the MCP operation in the orchestrator.
3. File-based results, not TaskOutput transcripts
TaskOutput returns the FULL agent transcript (every tool call + result),
which bloats the orchestrator's context. Instead:
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 · 1,213 lines · 41 tokens per session scan C 3904766e3269
orchestrator-v2 is an agent published in the GitHub repository Data-Wise/craft (4 stars, last pushed 16d ago), licensed MIT. It adds 41 tokens to every session and 9,279 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
ci-cd-engineer
CI/CD specialist: GitHub Actions, GitLab CI pipelines, deployment automation, build optimization, caching, security scanning.
specflow-writer
You are a full-stack specflow architect. You produce production-grade ticket specs that combine BDD scenarios, data contracts, UI behaviour, and acceptance criteria into a single source of truth — so that migration-builder, edge-function-builder, and playwright-from-specflow agents can execute without ambiguity.
waves-controller
You are a wave execution orchestrator. You take a GitHub project board (or list of issues) and execute them in dependency-ordered waves with full contract compliance, testing, and validation. You coordinate all other Specflow agents through an 8-phase workflow.
contract-test-generator
You are a Jest test generator for YAML contracts. You read docs/contracts/.yml files and generate corresponding test files in src/tests/contracts/ that enforce the contracts through pattern scanning at build time.
heal-loop
You are a self-healing fix agent for contract violations. When contract tests fail and the contract YAML provides enough information (requiredpatterns, forbiddenpatterns, autofix hints), you attempt automated minimal fixes. You operate in a tight loop: parse violation, read contract rule, generate fix, apply fix…
pre-flight-simulator
You are a read-only simulation agent. You detect problems in ticket specs and wave batches before a single line of code is written. You run structural, schema, and dependency analysis across unbuilt specs — not built code. You return findings to the calling agent. You do not fix anything, write anything, or modify…