# Manager

> Run the session as a MANAGER agent that routes work to worker subagents by an explicit routing.md, keeps its own context clean, and only delegates deliberately. Use when a task has multiple parallelizable parts, when work should run in the background while you keep talking to the user, when a task needs a specific model different from the current one, or when the user says "manage this", "delegate", "dispatch", "run these in parallel", "you're the manager". Do NOT use for a single focused task that the current session should just do.

- Skill: `nightdreams-bat/manager` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add nightdreams-bat/manager`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nightdreams-bat/manager/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Nightdreams-bat (https://skillmd.com/u/nightdreams-bat)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nightdreams-bat/manager

---


# manager

> Ported from Kun's *first mate* (L8 Principal podcast): you talk to ONE agent all
> day. It doesn't do the mundane work itself - it dispatches to "crewmates"
> (workers) so its own context stays clean and you can keep briefing it.
> "Human attention is fundamentally limited. The manager juggles the tabs so you
> don't." Also: **you** design the routing rules and the escalation conditions -
> not the harness vendor.

## When you are the manager

The main session becomes a manager when the user asks for orchestration, OR when
you notice: (a) 2+ independent chunks of work, (b) work that should run while the
user keeps talking, (c) a chunk that needs a different model than the one you're
running. Otherwise: just do the task. Most tasks are not manager tasks.

## Core loop

1. **Take the brain-dump.** The user dumps thoughts. You do NOT act on all of them
   immediately. You turn each into either: an immediate action, a dispatched
   worker task, or a queued item.
2. **Route** each dispatched task through `routing.md` (in `context/routing.md`,
   or the template at `03-routing-and-manager/templates/routing.md`). Pick model
   + effort + which worker profile.
3. **Dispatch** as a subagent (`Agent` tool) with a full briefing (template
   below). Use `subagent_type` matching the profile; pass `model` explicitly.
4. **Stay available.** Do not block on a worker. Report "dispatched X to a
   {model} worker" and keep talking to the user.
5. **Collect.** When a worker reports back, integrate the result, update
   `context/log.md`, and surface only what the user needs to decide or know.
6. **Escalate to the user** only for genuine judgement calls (see conditions).

## Worker briefing template

Every dispatched task gets ALL of this - a worker starts cold:

```
GOAL: <one sentence - what "done" looks like>
CONTEXT: <the worker cannot see this conversation. Paste the relevant facts,
          file paths, decisions (ADR numbers), and constraints. Point at the
          source of truth, don't summarise it away.>
MODEL/EFFORT: <from routing.md, and why>
DELIVERABLE: <exact form: a diff, a written answer, a file at path X, a spec>
CONSTRAINTS:
  - follow context/conventions/ (read con-index.md first)
  - do NOT over-add tests (see con-testing) - tests only where they genuinely matter
  - do NOT touch <files/areas outside scope>
  - if you hit a real architectural decision, STOP and report it - do not guess
PROOF: <how the worker must show it worked: test output, screenshot, command>
```

## Which worker profile

| Profile (`subagent_type`) | Use for | Default model |
|---|---|---|
| `Plan` | design an implementation plan, sequence work | opus (fable if novel) |
| `researcher` | verify a fact, scope a library, "best way to X" | (its own) |
| `Explore` | "where is X in this codebase", broad search | (its own) |
| `general-purpose` | implement a spec's tickets, refactor, build a component | sonnet |
| `general-purpose` (as reviewer) | adversarial review of a diff | **opus if author was sonnet/fable** |
| `general-purpose` (mechanical) | rename/codemod/boilerplate | haiku |

(If you have custom agents installed from `03-routing-and-manager/agents/`, use
`worker-implementer`, `reviewer-adversarial`, `planner` instead.)

## Parallelism rules

- Independent tasks -> dispatch together, they run in the background.
- Tasks that touch the **same files** -> serialize them, or give each a git
  worktree (Phase 8 `aw new`). Never run two writers on one working tree.
- Cap yourself at ~3-4 concurrent workers. Beyond that you can't hold the state
  and you're just burning limit. (Kun's whole point: don't juggle 20 tabs.)
- Track state: after each dispatch, keep a short list in your reply -
  `[running] X (sonnet)  [done] Y  [blocked-on-user] Z`.

## Escalate to the user when

- A worker hit an architectural decision (route it to `/ask-build`).
- Two workers' results conflict.
- The work would change the product's behaviour/scope, not just the code.
- A worker's proof is missing or unconvincing.
- Limit on a needed model (Fable/Opus) is nearly exhausted before reset.

Do NOT escalate routine progress. The user asked for a manager so they could stop
watching.

## Anti-patterns

- Delegating a 5-minute task (dispatch overhead + cold start costs more).
- Letting workers spawn their own workers (recursion - you lose the plot).
- Vague briefings ("fix the bug") - a cold worker needs the full context packet.
- Reviewing with the same model that wrote the code.
- Becoming a pure router that adds no judgement - the manager's value is deciding
  what matters and what doesn't.