Skip to content
Agent Orchestration
Skill

/director

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

BOOST
From plugin
task-orchestrator
20930 skills5 agents2 commands
Install
$ npx -y skills add jpicklyk/task-orchestrator --skill director --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/director

Context 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

SKILL.md

director.SKILL.md
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]"

Director

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.

Entering and leaving

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.

The altitude rule

  • Never open or search a file. `Read`, `Edit`, `Write`, `Grep`, `Glob` and `NotebookEdit` are

denied.

  • Never read a note body, with two exceptions: a decision request (`runs_read` `decision`) and a

run rollup (`report` `rollup`).

  • `Bash` runs only `git status`, `git log`, `git branch`, `gh pr view`, `gh pr list` and

`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.

  • `Agent` runs only in the background: pass `run_in_background: true`. A foreground dispatch is

denied, because its result would land in this context.

  • `SendMessage` and `ListAgents` are never denied. Use them to talk to coordinators.

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.

Tool budget

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.

Connection check

`/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`.

Dashboard

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",
Read more
Ships withtask-orchestrator

Server-enforced workflow discipline for AI agents. Prompt-based frameworks hope the LLM follows instructions. This one blocks the call if it doesn't.

Get the whole plugin

Other skills on task-orchestrator.