add-component
Checklists for adding a new MCP tool, select or op, a new Flyway database migration, or a new Gradle dependency to the Task…
Enters director mode: this session runs the board instead of the code. It shows open runs, their frontier, open decisions and rollups, answers decisions, and delegates every read or edit to background agents and coordinators. A guard hook blocks file reads, edits, foreground
$ npx -y skills add jpicklyk/task-orchestrator --skill director --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/directorContext preview
The summary Claude sees to decide when to auto-load this skill.
Enters director mode: this session runs the board instead of the code. It shows open runs, their frontier, open decisions and rollups, answers decisions, and delegates every read or edit to background agents and coordinators. A guard hook blocks file reads, edits, foreground
name: director description: "Enters director mode: this session runs the board instead of the code. It shows open runs, their frontier, open decisions and rollups, answers decisions, and delegates every read or edit to background agents and coordinators. A guard hook blocks file reads, edits, foreground dispatches and most shell commands until you leave with off. Use when the user says: director mode, become the director, be the director, run the board, show open decisions, answer decisions, what needs my decision, or director off." argument-hint: "[off]"
The director watches runs and answers decisions. It does not read code, open files or read note bodies; coordinators and background agents do that and report back.
Calling this skill entered director mode. The plugin's `director-guard` hook saw the `Skill` call and wrote a marker for this session (`<tmp>/task-orchestrator/<session>/director.json`). While the marker exists, the guard enforces the altitude rule below on every tool call of this session. Subagents are exempt (their calls carry `agent_id`), and a headless ralph iteration is never guarded.
`/task-orchestrator:director off` removes the marker and ends director mode. Say so in one line and stop; do not show the dashboard.
Calling the skill again while in director mode refreshes the marker and the dashboard.
denied.
run rollup (`report` `rollup`).
`docker ps`, one command per segment, with no redirection (`<`, `>`), no substitution (backtick, `$`), no braces, globs or backslashes, and nothing chained after a command outside that list. `git log`, `git status` and `git branch` take only listing flags (a flag allow-list): `git log` takes `--oneline`, `--format=`, `-n <k>`, `--graph`, `--since=`, `--author=`, `--grep=` and `--stat`, never `-p` or another patch flag; `git status` takes `-s`, `-b`, `--porcelain` and `-uno`, never `-v`; `git branch` may only list (`-a`, `-r`, `-v`, `--list`, `--show-current`, `--merged <ref>`, `--contains <ref>` and the like). Revisions and paths are allowed as operands.
denied, because its result would land in this context.
When a call is denied, the reason starts with `Director altitude rule:`. Do not retry it in another form. Delegate it: a background `Agent` with an explicit `model`, or `SendMessage` to the coordinator that owns the run.
After a compaction the `director-context` hook re-injects a two-sentence reminder of this rule. Re-invoke `/task-orchestrator:director` to get the dashboard back.
This is the whole tool budget of a director session:
| Tool | Use | |------|-----| | `runs_read` | Runs, frontier, decisions, one decision request | | `runs_write` | `answer`, `withdraw` (and `ack`) on decisions | | `report` | `rollup` per run; `usage`, `gates`, `contention`, `waste` on request | | `items_read` | `overview` of the project, for blocked work | | `deps_read` | Dependency `list` / `graph` when a blocker needs explaining | | `Agent` | Background only (`run_in_background: true`), with `model` set | | `SendMessage`, `ListAgents` | Talk to coordinators and other sessions | | `Skill` | Re-invoke this skill, or `off` | | `PushNotification` | Tell the user a decision is waiting when they are away |
The five MCP tools come from the director connection. Anything else (notes, items writes, `advance`, config) is a coordinator's job.
`/task-orchestrator:init` registers a second MCP entry, `mcp-task-orchestrator-director`, next to the orchestration one. Its tools appear as `mcp__mcp-task-orchestrator-director__runs_read` and so on. Confirm they are in your tool list; do not edit `.mcp.json` from here.
The director connection uses the server's `director` profile (the `/mcp/director` endpoint over HTTP, or `MCP_TOOL_PROFILE=director` on stdio). That profile has no note-body read at all, so the server enforces the rule for MCP even when the hook cannot see the call.
If the director tools are missing, say so and name `/task-orchestrator:init` as the fix. Until then, make the same `runs_read` and `items_read` calls on the orchestration connection, skip the rollup (`report` exists only in the director profile), and still never call `notes_read`.
Run these in order and render one compact board. Every call below uses the director profile.
1. Open runs:
{"tool": "runs_read", "select": "list", "args": {"status": "open", "limit": 20}, "profile": "director"}No open run: say so in one line, show the decision list (step 3 without `runId`) and the blocked work (step 5), and stop.
2. For each open run, its frontier (ready, running and waiting seats):
{"tool": "runs_read", "select": "frontier", "args": {"runId": "7c41e0a2"}, "profile": "director"}3. Decisions per run. The select has no status filter: keep the summaries whose `status` is open and drop answered, withdrawn and closed ones yourself. `overdue: true` narrows to the late ones.
{"tool": "runs_read", "select": "decisions", "args": {"runId": "7c41e0a2", "limit": 50}, "profile": "director"}4. The rollup per open run (counts, spend, stalls). This is one of the two bodies you may read:
{"tool": "report", "select": "rollup", "args": {"runId": "7c41e0a2"}, "profile": "director"}5. Blocked work under the project root. Read each blocked item's `blockedByReason`; do not open the item's notes:
{"tool": "items_read", "select": "overview",Server-enforced workflow discipline for AI agents. Prompt-based frameworks hope the LLM follows instructions. This one blocks the call if it doesn't.
Checklists for adding a new MCP tool, select or op, a new Flyway database migration, or a new Gradle dependency to the Task…
Compatibility assessment for items with the needs-api-compat-review trait. Evaluates the MCP tool surface and the REST surface…
Guides the full lifecycle of a feature-implementation typed MCP item (the feature container) — from queue through review. Creates…
End-to-end workflow for taking MCP work items from backlog to merged PR. Handles git branching, schema-driven planning,…
SQLite migration assessment for items with the needs-migration-review trait. Evaluates schema changes, table recreation patterns,…
Performance impact assessment for items with the needs-perf-review trait. Evaluates hot paths, query patterns, and measurement…