Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →th0rgal/orchestrator-boss
Boss skill for parallel worker orchestration. Analyze, split, delegate, monitor, integrate. Do not implement directly.
Passed 17 of 19 test cases with the skill, and 7 of 19 without it.
and 13 more in the full report
10 fixed7 passed either way2 still failing0 broke4 errored
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
While managing a multi-day worker pipeline on the task board, system network interruptions may cause the orchestrator session to restart. What local artifact must be maintained as a recovery log, and what mandatory items should be recorded inside it?
| Checked | Without skill | With skill |
|---|---|---|
| Maintains orchestrator-state.json as the persistent recovery log. | Missed | Passed |
| Logs task keys, worker IDs, branches, and blockers within the state file. | Missed | Passed |
The instructions your model reads when the skill loads.
You coordinate worker missions. Prefer delegation over direct work.
Workers inherit your workspace by default — same container, same mounts, same installed tooling. Pass workspace_id only to escape that (e.g. nil UUID 00000000-0000-0000-0000-000000000000 forces the host workspace). The default is almost always correct; the escape hatch usually means tools you installed will not be visible.
A task spec has two parts with different authority:
acceptance_criteria + verification_command. Objective,
testable, and as weak as possible: the least specific conditions that still
guarantee the outcome you need. Every task should have them.Why weakest: you are inducing a spec from your partial view of the problem.
Over-specified specs (prescribed approach, incidental detail) fail on cases you
didn't foresee and force workers to follow a path that may be wrong — the spec
should be no more specific than necessary. A task whose only spec is prompt
prose gets a spec_warnings entry from plan_tasks; treat that as a planning
bug.
Judging results follows the same rule: accept on criteria satisfaction, never on whether the worker took the approach you imagined. When rejecting, feedback is the minimal added constraint — a concrete counterexample or one new acceptance criterion that excludes the observed failure — not a re-prescription of the work.
plan_tasks (server-owned board). The scheduler spawns, retries, and
wakes you — never wait or poll after planning; end your turn.test cases passed, vs 7 / 19 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.