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 skills add daman8271/the-perfect-orchestrator --skill orchgit clone --depth 1 https://github.com/daman8271/the-perfect-orchestratorWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/daman8271/the-perfect-orchestrator/orch)<a href="https://agentmods.dev/skills/daman8271/the-perfect-orchestrator/orch"><img src="https://agentmods.dev/badge/skills/daman8271/the-perfect-orchestrator/orch/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/daman8271/the-perfect-orchestrator/orch"><img src="https://agentmods.dev/badge/skills/daman8271/the-perfect-orchestrator/orch.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00133 | $0.01710 |
| Opus 5 | $0.00067 | $0.00855 |
| Sonnet 5 | $0.00027 | $0.00342 |
| Haiku 4.5 | $0.00013 | $0.00171 |
Grade B, and why
orch scanned grade B 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 10d 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.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
- **PERMISSIONS (the #1 blocker):** the permission classifier may *deny* autonomous spawns/sends. If `orch`/`tmux` calls get blocked, the user must add allow-rules to `~/.claude/settings.local.json`: `Bash(orch:*)` and ` Copies of this mod
1 near-identical copy found in the catalogue:
- orch — 95% identical, 2 lines differ
How it starts
The opening of the file, as written. The whole thing — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.
The Perfect Orchestrator — lead playbook
You are the LEAD. This harness lets you spawn N autonomous Claude Code workers
(each its own tmux pane), brief each one, watch them, correct them, verify their
results, and drive them to completion — all from this one session. The CLI is orch
(run orch --help for usage; state lives under $ORCH_HOME, default ~/.orch).
The harness commands
| command | what it does |
|---|---|
orch spawn <session> <N> [workdir] |
Create tmux session orch-<session> with N worker panes + a shared workspace at $ORCH_HOME/runs/<session>/shared/ (contains bus.md; panes.txt lives one level up). Workers are numbered 1..N. Workdir defaults to the current directory. |
orch send <session> <#> --file <path> |
Dispatch a task: tells worker # "Read and follow <path> then begin, work autonomously." |
orch send <session> <#> <one-line msg> |
Send a short single-line nudge (NO newlines — newline submits). |
orch read <session> <#> [lines] |
Capture a worker's pane (to see what it's doing). |
orch status [session] |
Overview of all live fleets, or one fleet's panes + done-flags + bus tail. |
orch kill <session> |
Tear down a fleet when done. |
Workers launch with an isolated config (no hooks → no notification spam on every
turn, a generous allowlist → no permission prompts, shared live credentials,
ORCH_WORKER=1). When a worker's claude exits, its pane ends.
The workflow (do it in this order)
- PLAN — split the job into N independent sub-tasks (one per worker). Pick N deliberately (see Limits).
- SPAWN —
orch spawn <name> <N> [workdir]. Give workers a few seconds to boot (a pane showing a ready prompt = booted). - BRIEF — write each worker's brief to
$ORCH_HOME/runs/<name>/shared/agent-<i>.task.md. A good brief is self-contained: the goal, hard constraints (what NOT to touch), exactly what to produce, where to write its result + a done-flag totouch, and how to use the bus. - DISPATCH —
orch send <name> <i> --file .../agent-<i>.task.mdfor each booted worker. - COORDINATE via the bus — tell workers to post findings to
shared/bus.md(lines prefixed[Wn]) and to read it. When one discovers something (a bug class, a shared fix needed), the others act on it. The bus is the fleet's shared memory. - MONITOR (your core job) — periodically
orch readeach pane + readbus.md. Catch wrong-roads early and correct them with a nudge. Watch for: off-task drift, dead-ends, forbidden actions, or stalls. Re-check on a cadence (~80–600s) so you stay free between passes; a tighter cadence = closer watch. - COLLECT — each worker
touches a done-flag (e.g.shared/agent-<i>.done) + writesagent-<i>.result.md. Poll the flags (background loop ororch status) so you know when all are done. - VERIFY + TEAR DOWN — read the results, verify them adversarially (don't trust blindly — have a DIFFERENT worker try to refute each finding), then
orch kill <name>. Report a consolidated sign-off BEFORE killing sessions.
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.
- 10d ago First seen · 62 lines · 0 tokens per session scan B 6a3a61fa08f7
orch is a skill published in the GitHub repository daman8271/the-perfect-orchestrator (1 stars, last pushed 2mo ago), licensed MIT. It adds 133 tokens to every session and 1,710 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it B with 1 finding (reads agent configuration directories). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
security-review
Perform a focused security review of pending git changes to identify high-confidence security vulnerabilities with real exploitation potential. Use this skill when the user asks for a security review, security audit, vulnerability scan, or wants to check pending changes on a branch for security issues before merging.…
huggingface-llm-trainer
Train or fine-tune language models with TRL or Unsloth on Hugging Face Jobs, including SFT, DPO, GRPO, reward models, and GGUF conversion. Use for cloud LLM training; use huggingface-vision-trainer for vision tasks.
feature-dev
Guide a feature implementation through a structured seven-phase workflow with deep codebase understanding, clarifying questions, parallel architecture design, and quality review. Use this skill when the user asks to build a new feature, add functionality, or wants a methodical approach to implementation rather than…
memstack-business-gdpr
Use this skill when the user says 'GDPR', 'data protection', 'privacy compliance', 'DPA', 'DSAR', 'data subject request', 'cookie consent', 'privacy audit', 'CCPA', or asks 'do I need GDPR for this repo'. Scans the repository to detect what personal data is collected, classifies sensitivity, determines whether GDPR…
memstack-deployment-domain-ssl
Use this skill when the user says 'setup domain', 'configure DNS', 'SSL certificate', 'domain-ssl', 'custom domain', 'HTTPS setup', or needs to configure DNS records, SSL certificates, and custom domains for any hosting provider. Do NOT use for full deployment workflows.
memstack-development-refactor-planner
Use this skill when the user says 'refactor', 'refactoring plan', 'code cleanup', 'reduce duplication', 'simplify code', 'tech debt', 'god class', 'tight coupling', or needs to systematically improve existing code. Identifies targets, assesses risk, and builds incremental execution plans. Do NOT use for writing new…