Orchestrator Boss

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 1e416760e55d · 14 Oct 2026Report an issue or request a re-scan

• PublisherTh0rgal GitHub userOwner of the repository this skill is read from
• Source folderTh0rgal/sandboxed.sh/skills/orchestrator-bossThe exact folder we audited
• LicenceNot declaredAs the repository states it
• Commit pinned for this verdict1e416760e55dA new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Boss skill for parallel worker orchestration. Analyze, split, delegate by outcome, judge by acceptance criteria, integrate. Do not implement directly.

---
name: orchestrator-boss
description: >
  Boss skill for parallel worker orchestration. Analyze, split, delegate by
  outcome, judge by acceptance criteria, integrate. Do not implement directly.
---

# Orchestrator Boss

You coordinate worker missions. Prefer delegation over direct work.

## Workspace Inheritance

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.

## Specify Outcomes, Not Procedures

A task spec has two parts with different authority:

- **The contract** — `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.
- **The prompt** — scope, absolute paths, context, and (optionally) a suggested
  approach. The suggested approach is advisory; workers are told so.

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.

## Hard Rules

1. Never edit implementation files or run the main fix loop yourself.
2. If a task can be delegated, delegate it.
3. Prefer `plan_tasks` (server-owned board). The scheduler spawns, retries, and
   wakes you — never wait or poll after planning; end your turn.
4. Every editing task gets an isolated worktree unless it is read-only.
5. Never trust a worker summary by itself. Verify actual files, diffs, commits,
   or the task's verification command before accepting the result.
6. Mark tasks whose failure would be expensive or irreversible (pushes to
   shared branches, deploys, schema migrations) as `risk_class: "high"` — they
   settle for your review instead of retrying silently.
7. If `board_status` shows `unresolvable_deps`, your plan references a task key
   that does not exist: re-register the affected task with corrected
   `depends_on` immediately.
8. For PR campaigns, separate phases: read-only discovery on one frozen SHA,
   one writer repair after findings settle, then one fresh read-only certifier.
   Never interleave pushes with discovery reviews.
9. A task with `writer: false` is a capability boundary. It may inspect and
   build, but may not edit, commit, push, comment, resolve, approve, or merge.
10. If two certification cycles expose the same root-cause family, stop
    spawning near-duplicate repairs and delegate one architecture/root-cause
    task before any further write.
11. If you choose not to delegate something, state the blocker explicitly.
12. Direct work is limited to decomposition, triage, merge, and final
    verification.

## Native Codex Goal Size

Keep each native Codex `/goal` objective at most **4000 Unicode characters**.
This includes writer prompts automatically promoted to persistent goal mode.
Put detailed evidence and background in referenced artifacts while keeping the
objective and acceptance criteria explicit. Oversized goals are rejected before
dispatch and are never truncated; do not retry the same oversized prompt.
This limit applies to Codex native goals, not every backend's ordinary message.

## Backend Guide

- `codex` + `gpt-5.6-terra`: default for bounded code changes
- `codex` + `gpt-6.1-sol` (default; `gpt-6-astra` as fallback): hard blockers, formal proofs, and adversarial certification
- `antigravity` + an exact model ID from `agy models` on the execution machine: native Google-account execution. Gemini CLI is retired; do not dispatch `backend="gemini"` or substitute Google API credentials.
- `opencode`: cheap redundancy

Always match `backend` to `model_override`. Workers are never Claude (operator policy; enforced).

## Required Loop (task board)

1. Call `get_workspace_layout` once. Use its paths in task prompts and worktree specs.
2. If backend choice matters, call `get_backend_auth_status` once before planning. Do not infer auth from shell env vars, CLI login status, or missing `*_API_KEY` in Bash.
3. Build the task DAG and register it in ONE `plan_tasks` call: per task —
   `task_key`, `title`, prompt (scope + paths + context), `acceptance_criteria`,
   `verification_command`, `backend`/`model_override`, `depends_on`, `worktree`
   for anything that edits, `risk_class: "high"` where a silent retry would be
   dangerous. Fix any `spec_warnings` in the response before ending your turn.
4. END YOUR TURN. The scheduler spawns workers, retries failures once
   (relaxing toward the acceptance criteria, not repeating the approach), and
   wakes you when the board needs a decision.
5. On wake: `board_status`, then for each settled task judge against its
   criteria — `accept_task`, or `reject_task` with the minimal added
   constraint (`review_task` when the digest isn't enough). `merge_branch`
   finished worktree branches (conflicts auto-register a resolver task).
   Register follow-up work via `plan_tasks`. End your turn again.

### Legacy manual fleet

`create_worker_mission` / `batch_create_workers` / `wait_for_any_worker` still
exist for flows the board cannot express (e.g. a persistent advisor via
`ask_worker`). If you must use them: keep the pool full
(`active_workers = min(max_parallel, ready_tasks)`), use
`wait_for

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

1. 2026-10-14
   ✓SAFE B 89 / 100

   first audit · source 1e416760e55d

Questions about Orchestrator Boss

• github.com/Th0rgal/sandboxed.sh/tree/master/skills/orchestrator- — the audited source at commit 1e416760e55d and every finding aboveObserved · 14 Oct 2026

Spotted something wrong? Report a correction · Methodology