# Orchestrator Capacity

> Private CCB orchestrator skill for requesting, inspecting, using, and releasing dynamic loop capacity through `ccb loop capacity` only.

- Skill: `seemseam/orchestrator-capacity` (Agent Skill)
- Install (CLI): `npx skillmds@latest add seemseam/orchestrator-capacity`
- Raw SKILL.md: https://api.skillmd.com/api/skills/seemseam/orchestrator-capacity/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: seemseam (https://skillmd.com/u/seemseam)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/seemseam/orchestrator-capacity

---


# Orchestrator Capacity

Use this skill when a loop round needs temporary execution nodes, when
capacity state is unclear, or when loop-owned nodes should be released after
round drain.

The skill is a permission boundary and capacity requests are advisory until
the CCB command returns concrete generated agent names. It lets the
orchestrator request configured capacity without granting authority over
`.ccb/ccb.config`, `.ccb/runtime`, tmux, provider processes, daemon
supervision, or raw reload/kill commands.

Use this skill only from an execution-ready loop round. If the task packet,
review, verification contract, or loop id is missing, return `replan_required`
or `blocked` instead of requesting capacity.

Do not edit `.ccb/ccb.config`; all capacity changes must go through CCB-owned
commands.

## Inputs

Required:

- loop id
- requested profile counts, for example `worker=1` and `code_reviewer=1`
- task/work graph or task-packet reference
- acceptance and verification references
- lifetime expectation, normally `current_round`

Optional:

- current capacity summary reference
- planner policy for serial fallback
- previous capacity command JSON

## Ensure Capacity

Call exactly the narrow CCB surface:

```bash
ccb loop capacity ensure --loop-id <id> --profile worker=1 --profile code_reviewer=1 --json
```

For different ready plans, replace only profile counts that are declared in
`[loop.role_profiles]`. Total requested nodes must stay within the configured
`[loop.capacity].max_nodes` limit and must never exceed four.

After ensure:

- parse JSON output;
- require `loop_capacity_status = "ensured"`;
- require `apply.apply_status = "applied"` for live capacity, or
  `apply.apply_status = "deferred_until_start"` only when reporting planned
  capacity without dispatching;
- use returned agent names as the only dynamic ask targets;
- if rejected, blocked, retained, or failed fields exist, report them as loop
  blockers instead of continuing as success.

Do not invent names from `name_template`. Returned JSON is the source of truth.
Do not use `ccb loop run-once`; that is an external deterministic runner, not
the autonomous orchestrator path.

## Dispatch With Returned Targets

Only after ensure returns concrete names, create bounded asks.

Worker ask requirements:

- one clear goal;
- exact scope and non-goals;
- referenced task packet and acceptance criteria;
- forbidden fallback/degradation list;
- expected artifacts and verification evidence;
- explicit response schema: `done`, `blocked`, or `needs_rework`.

Checker ask requirements:

- worker result or artifact reference;
- acceptance criteria and verification reference;
- check plan;
- fallback/degradation audit;
- explicit response schema: `pass`, `rework_required`, `blocked`, or
  `non_converged`.

Use `ask` targets from ensure output. Do not target static default names unless
the JSON explicitly reports a pinned or reused agent with that name.

When the child result is needed to continue the round, submit with callback and
then stop until CCB resumes the task:

```bash
command ask --callback "$WORKER_AGENT" <<'EOF'
<bounded worker request>
EOF
```

After the worker callback resumes the orchestrator, submit the reviewer ask the
same way:

```bash
command ask --callback "$REVIEWER_AGENT" <<'EOF'
<bounded reviewer request with worker result/artifact refs>
EOF
```

## Status

When progress is unclear or before release, inspect capacity:

```bash
ccb loop capacity status --loop-id <id> --json
```

Use status to report generated agents, profile, provider, role, lifetime,
state, blockers, retained agents, and whether the loop can release.

## Release

After the worker/checker branch is drained, release only idle loop-owned
capacity:

```bash
ccb loop capacity release --loop-id <id> --policy auto --json
```

If release reports retained agents, treat them as active blockers or handoff
items. Do not force unload busy nodes.

## Forbidden

Never:

- edit `.ccb/ccb.config`;
- write `.ccb/runtime`, `.ccb/agents`, lifecycle, lease, socket, pid, mailbox,
  pane, or provider-state files directly;
- call raw `ccb reload`;
- call raw `ccb kill`;
- run `tmux` commands;
- start, stop, kill, or respawn provider processes directly;
- invent provider/model/thinking/workspace values outside configured
  `loop.role_profiles`;
- request undeclared profiles;
- exceed `max_nodes`, profile `max_instances`, or four total nodes;
- silently run fewer nodes and call the round successful;
- bypass checker or round-checker gates;
- convert partial, blocked, or non-converged work into done.

## Failure Handling

If ensure, status, dispatch, review, or release cannot converge:

1. stop local escalation;
2. summarize the blocker, command output, returned agent names, and affected
   work items;
3. return `blocked`, `partial`, or `replan_required` to planner/frontdesk through
   the loop runner;
4. keep unrelated drained branches separate from the failed branch.