Borrowing it
Nothing to install: this file belongs to c9r-io/orchestrator. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/c9r-io/orchestrator/main/.claude/skills/orchestrator-test-monitor/SKILL.mdgit clone --depth 1 https://github.com/c9r-io/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/c9r-io/orchestrator/orchestrator-test-monitor)<a href="https://agentmods.dev/skills/c9r-io/orchestrator/orchestrator-test-monitor"><img src="https://agentmods.dev/badge/skills/c9r-io/orchestrator/orchestrator-test-monitor/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/c9r-io/orchestrator/orchestrator-test-monitor"><img src="https://agentmods.dev/badge/skills/c9r-io/orchestrator/orchestrator-test-monitor.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.00115 | $0.01802 |
| Opus 5 | $0.00057 | $0.00901 |
| Sonnet 5 | $0.00023 | $0.00360 |
| Haiku 4.5 | $0.00012 | $0.00180 |
Grade A, and why
orchestrator-test-monitor 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 12d 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 — 221 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Orchestrator Test Monitor
Observe and evaluate the orchestrator's execution of a test plan. You are a monitor, not a participant. Never modify code, fix bugs, or intervene in execution. Only observe, report, and assess.
Workflow
Phase 1: Plan Selection
- List all files under
docs/showcases/in the project working directory - Present each plan with a one-line summary (read the "Task Goal" or opening section)
- Ask the user which plan to execute
- Read the selected plan thoroughly — extract:
- Expected workflow steps and their order
- Success criteria
- Key checkpoints
- Known anomaly patterns
Phase 2: Pre-Execution Setup — Build, Restart & Baseline
Ensure the daemon and CLI are built from the latest code and the daemon is running before launching any task.
2.1 Rebuild daemon & CLI
cargo build --release -p orchestratord -p orchestrator-cli
If the build fails, report the error to the user and stop — do NOT proceed with a stale binary.
2.2 Restart the daemon
IMPORTANT: Check CLAUDE.md for daemon lifecycle constraints first. If
orchestratord is managing this session (i.e., this skill was triggered BY the
orchestrator), you MUST NOT kill the daemon. In that case, skip the restart and reuse the
running daemon.
If it is safe to restart:
# Inspect and gracefully stop the old daemon
orchestrator daemon status
orchestrator daemon stop
# Start fresh daemon
nohup ./target/release/orchestratord --foreground --workers 2 > /tmp/orchestratord.log 2>&1 &
# Verify it's running (wait a moment for startup)
sleep 3
pgrep -f orchestratord
If the daemon fails to start, check /tmp/orchestratord.log and report the error.
2.3 Set up CLI environment
The CLI auto-discovers the default Unix Domain Socket under ~/.orchestratord/.
If the daemon uses an explicit data directory, set ORCHESTRATOR_SOCKET to that
directory's socket:
export ORCHESTRATOR_SOCKET="${ORCHESTRATORD_DATA_DIR}/orchestrator.sock"
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.
- 12d ago First seen · 221 lines · 115 tokens per session scan A 7b76ea7c7958
orchestrator-test-monitor is a skill published in the GitHub repository c9r-io/orchestrator (21 stars, last pushed 11d ago), licensed MIT. It adds 115 tokens to every session and 1,802 once invoked, about $0.0006 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 skills, from other repositories
cw-dogfood
Use when a Codewhale change needs proving in the real product, or when asked to build/install/dogfood the local binaries: stamped release build, atomic install, fresh-shell verification, and the manual QA that gates cannot cover.
cw-gates
Use before claiming any Codewhale change is done, green, or ready to land: the focused-to-broad verification ladder, the budget checks CI enforces, and the rules for what counts as a passing test.
codew-release-qa-sweep
Use before claiming Codewhale release work is done: run the full gate sweep and list the manual QA targets.
verify
Exercise the real app/API/CLI and collect observable evidence; tests alone do not count as end-to-end verification.
webapp-testing
Start/reuse a local app, wait for readiness, inspect rendered state/console/network, act from observed selectors, and verify with evidence.
issue-to-pr
Implement one bounded repository issue with normal host tools, prove the tested change through one scafld finalize wall, and optionally publish the exact pull request through scoped provider authority with readback.