You are going to build me a complete **AI team**: a set of persistent, role-based AI managers that work on my project(s) in parallel, communicate with each other, report to me through named terminal tabs, and are coordinated by a single **Chief of Staff** that serves as my sole point of contact. Build it exactly to this specification, adapting names and paths to my interview answers.

## Phase 1 - Interview me first (build nothing yet)

Cover one topic at a time and wait for my answer before moving on.

1. **Scope and mission.** What project(s) will this team run? One team = one mission. If I have a monorepo with multiple projects, each project can get its own team, or one team can carry more managers - help me decide based on whether the projects serve a single goal. For each team, collect: the project name, its root directory, and a one-sentence mission statement that defines "done" precisely (e.g. "renders correctly on the local dev server, not the public deploy").

2. **The managers.** What roles staff the team? For each manager, collect: a title; its charter (the files/areas it may edit freely); its off-limits list (other managers' territory); and its type - **line manager** (does work: edits, builds, ships) or **analyst** (read-only: QA, analytics - detects and reports, never fixes). If I'm unsure, propose a starter org: an engineering/design manager, a content manager, a growth manager, an analytics analyst, and a QA analyst. Assign each a short lowercase one-word slug.

3. **Specialists.** Should any manager have a specialist under them (an individual contributor for a narrow sub-domain)? Strict chain of command: a specialist reports up through its manager, never directly to the Chief of Staff, and all traffic - even Chief of Staff pings - is answered through the manager. Ask which roles, if any, warrant one.

4. **My authority.** What must always escalate to me and never be decided by any AI? Default escalation list (confirm or edit): matters of taste and creative direction; anything that costs money or touches my personal accounts; anything outward-facing, public, or irreversible (posting, emailing, deploying). Then set the delegation model as **tiers, not a yes/no**. Every category of action lands in one: **auto** (do it silently), **act-then-report** (do it, tell me after), **gated** (propose, wait for approval), **never** (mine alone - the escalation list). New kinds of action start at gated; I can promote a category to act-then-report or auto once it has a track record. Record the tier assignments in the charter (2b) so promotion is a one-line edit, not a rebuild.

5. **Red zones.** Separate from inter-manager lanes: what on this machine may NO role ever read, edit, or quote - regardless of whose lane it is? Prompt me for the usual suspects: credential and secret files (.env, keys, tokens), directories containing financial or personal data, anything holding PII, and any files another process owns. Red zones are absolute, they override every charter, and they get written into every brief and the dispatcher prompt verbatim.

6. **Human collaborators.** Do other PEOPLE commit to any of these repos, or read files inside them? If yes: the team pulls before every work cycle, never auto-merges into a shared repo (shipping there is at minimum act-then-report, and gated by default), and the org charter (2b) lives OUTSIDE the shared repo entirely - teammates should never encounter the team's internal plumbing, gitignored or not.

7. **Names.** My name (so the team addresses me properly - internally I am "the principal") and a short system prefix (e.g. the project's initials) used in file and script names.

8. **Environment and existing automation.** Confirm: macOS or Linux; terminal app (the tab-icon feature requires a terminal that honors OSC title sequences - the Cursor/VS Code integrated terminal, iTerm2, etc.); whether launchd (macOS) or cron/systemd (Linux) is acceptable for background scheduling; where background runtime files may live; and the dispatch interval (default every 60 seconds; warn me that each dispatch of a pending task is a full headless Claude session, so a short interval on a busy inbox has real cost). Then INVENTORY what already exists before designing anything on top of it: existing hooks in `~/.claude/settings.json` (especially anything already painting tab titles or status), existing scheduled jobs (launchd/cron), any sandbox or permission policy restricting where commands may write, and any existing audit/monitoring system for autonomous jobs. The rule for all of it: **integrate, never replace** - new hooks merge into existing hook arrays, new scheduled jobs register with any existing job monitor, and if a tab-title system already exists the team adopts its conventions instead of installing a competing one. Known constraint: headless `claude -p` runs may be write-gated inside `~/.claude/` - place the message bus OUTSIDE it (e.g. `~/<prefix>-bus/`) and pass `--add-dir` for any extra directory the headless runs must write to. Verify early (before building the full system) that a headless run can actually write to the bus location - sandbox policies can silently block it.

Close the interview with a one-screen summary of the planned org (teams, roles, charters, action tiers, red zones, file layout, and what existing automation is being integrated with) and get my explicit confirmation before building anything.

## Phase 2 - Build (after I confirm)

### 2a. The operating model (write it into every artifact)

- **The mission is the unit of organization.** One team, one mission; every role exists to advance it.
- **Managers own lanes.** Each manager has a charter it works in freely and territory it never touches. Different jobs, one shared goal.
- **Specialists report through their manager.** The manager is the boss; the Chief of Staff is the boss's boss; all communication routes through the manager.
- **The Chief of Staff holds no lane.** It coordinates: plans, routes, reconciles, approves routine work under delegated authority, and is the principal's single point of contact. **It dispatches - it does not do managers' work itself**, and it does not answer questions that belong to a manager's expertise; it routes the question to the expert and relays the answer with attribution. It performs work directly only when no manager owns that domain.
- **Each manager is one persona in two halves:** a headless **background worker** (the hands - does the work automatically) and a live **terminal tab** (the voice - what the principal talks to and hears). Never present them as separate agents. Tabs speak in first person about the worker's output ("I shipped...", never "the background did...").

### 2b. The org charter - `COORDINATION.md` (one per team; placement rules at the end of this section)

The single source of truth every AI reads first and updates before finishing. Contents:

- The mission (definition of done), the operating model above, and a **responsibility matrix**: one row per manager - role | owns | must never touch - with analysts marked REPORT-ONLY.
- The **red zones** (interview Q5), verbatim, above the matrix - absolute, overriding every charter.
- The **action-tier table** (interview Q4): each category of action mapped to auto / act-then-report / gated / never, so promoting a category later is a one-line edit.
- **Global rules**: the only build target; how work ships (e.g. feature branch -> PR -> merge per the action tier for that repo); never clobber another AI's work (base on latest main, no resets over others' commits); in repos where humans commit, pull before every work cycle and never auto-merge; the principal owns whatever substance they have claimed; update the charter every run.
- **Approval routing**: managers propose -> the Chief of Staff approves per the action-tier table and reports afterward; never-tier items always go to the principal.
- **Cross-functional coordination**: flag impacts on other lanes early; never edit another lane; hand off via direct lines (2f); resolve conflicts through the Chief of Staff. Notes must be self-contained - everything is async, so assume the reader has no other context.
- A **status board** (one row per manager, updated every run) and a **messages** section (dated notes between roles, deleted once handled).
- Placement: if the repo is private and solo, keep the charter at the team root and gitignore it if there is a remote. If humans collaborate in the repo, the charter lives outside it (e.g. in the bus directory) - never committed, never visible to teammates.

### 2c. Role briefs - `~/.claude/agents/<prefix>-<slug>.md` (one per manager, plus the Chief of Staff)

Standard Claude Code agent format (frontmatter: name, description, tools). Every brief carries: the role's place in the org; the standing order "on every invocation: read the charter first, then your direct-line threads, then your inbox"; the **red zones, verbatim, before the lane definition** (they are absolute and override the lane); the lane definition (owns / never touches); for analysts, "DETECT AND REPORT ONLY - never edit, never open PRs," stated twice; the action-tier table as hard guardrails; the communication rules (2f); and, for specialist briefs, the chain-of-command section. The Chief of Staff's brief additionally carries: the routing rule (dispatch anything a manager owns; do only unowned work yourself; route domain questions to the expert and attribute the answer), its approval authority per the action-tier table, and the dispatch mechanism (2e).

### 2d. The message bus - `~/<prefix>-bus/` (outside `~/.claude` - see the write-gate note)

Per manager: `<slug>.inbox.md` (pending tasks as `- [ ]` checklist lines, flipped to `- [x]` when done), `<slug>.outbox.md` (dated, full-text results - the manager's voice), `<slug>.status` (heartbeat timestamp), and `<slug>.tab.md` (the Chief of Staff's instruction channel to that manager's tab), plus shared `<a>-<b>.md` thread files for peer direct lines (participant slugs sorted, so both directions share one file).

**The outbox rule (hard rule, everywhere):** everything a manager produces - results, answers, peer messages - lands IN FULL in its own outbox. The outbox feeds the tab; anything not in the outbox is invisible to the principal.

### 2e. The automation scripts - `~/.claude/scripts/<prefix>-auto/` (bash; see portability notes)

Write all nine, `chmod +x` them, and test each one before moving on.

1. **`send.sh <manager> "<task>"`** - append a dated `- [ ]` task line to the manager's inbox.
2. **`read.sh [manager]`** - show inbox/outbox/heartbeat for one or all managers.
3. **`line.sh <from> <to> "<msg>"`** - peer direct line. Does three things: appends to the shared thread file (creating it with a header if new); appends a `- [ ]` wake line to the recipient's inbox (a thread note alone wakes nobody); and appends a copy to the SENDER's outbox (the outbox rule - so the sender's tab voices it).
4. **`dispatcher.sh`** - the heartbeat of the whole system. Every run: for each manager, write a heartbeat to `<slug>.status`; if its inbox holds a pending `- [ ]`, launch that manager headlessly, in parallel with the others (background each launch, then `wait`): `claude -p "<prompt>" --permission-mode acceptEdits --add-dir <bus> [--add-dir extras] >> <slug>.runlog 2>&1`. The prompt: "You are the '<slug>' manager, triggered automatically (no human watching - be careful and conservative). FIRST read your brief at <brief-path> and the charter at <charter-path>. RED ZONES: <red zones, verbatim> - never read, edit, or quote these, regardless of the task. For EACH '- [ ]' task in <inbox>: do it strictly within your lane, append a full dated result to <outbox>, flip the task to '- [x]'. PEER LINES: message another manager with line.sh; read threads bearing your name; genuine multi-turn follow-ups are allowed, max ~3 rounds; no acks/thanks ping-pong. Everything you say must also appear in your own outbox. GUARDRAILS: act only within your action tiers; for anything gated or above, write 'NEEDS <principal>: ...' instead of acting; in repos humans commit to, pull first and never merge. Analysts never edit files. Other managers may be running concurrently - work only in your own files/worktree." Guard with a PID lock file so runs never overlap; schedule via launchd/cron at the interval confirmed in the interview (default **60 seconds**); if the machine already has a job monitor or an audit ledger for autonomous work, register the dispatcher with it so team runs are watched and logged like every other scheduled job.
5. **`watch-inbox.sh <manager>`** - poll-block (sleep 5) until the inbox holds a pending `- [ ]`, print it, exit 0. For tabs that should DO work on arrival.
6. **`watch-outbox.sh <manager>`** - baseline the byte sizes of `<slug>.outbox.md` AND `<slug>.tab.md` at arm time; poll-block until either grows; print ONLY the new bytes, labeled by source (OUTBOX UPDATE = relay in full / TAB INSTRUCTION = obey, don't relay); exit 0. This is the mirror-tab watcher.
7. **`tell-tab.sh <manager> "<instruction>"`** - append an `@TAB` directive to `<slug>.tab.md`. This is the Chief of Staff's direct line to a live tab (correct its behavior, re-point it, have it say something) - so the principal never has to paste corrections into tabs by hand. Caveat: a tab only sees @TAB content queued after its current watcher armed; if a tab is sitting on a stale watcher, first make its outbox grow (send a trivial ping via the inbox), then send the @TAB.
8. **`tabprompt.sh <manager>`** - prints the standard mirror-tab boot prompt (2g) for a manager, so every tab is armed identically: `<tab-launcher> "Growth Manager" "$(bash .../tabprompt.sh growth)"`.
9. **`watch-team.sh`** - the Chief of Staff's watcher: baseline ALL manager outboxes, block until any grows, print which manager plus only the new bytes, exit. The Chief of Staff arms it in the background at session start and re-arms after each relay - its tab becomes a live feed of the whole team.

**Portability (hard-won):** macOS ships bash 3.2 - no associative arrays (`declare -A` fails); use `eval "base_$b=..."` for per-manager variables. Watchers are armed via the harness's run-in-background facility (which re-invokes the tab's Claude when the command exits) - NOT a shell `&`. Poll with `sleep 5`; a blocked idle tab costs nothing.

### 2f. Communication rules (bake into the briefs, the dispatcher prompt, and the charter)

- **Peer direct lines are org-wide**: any manager may message any other for real hand-offs, factual questions, or cross-lane heads-ups. Genuine back-and-forth is allowed - follow-ups that respond to what the other actually said - batched into ONE message per round, capped at ~3 rounds, then escalated to the Chief of Staff. Never pure acks or thanks (no ping-pong). Direct lines never bypass the approval rules.
- **Chain of command for specialists**: all specialist traffic routes through its manager - including replies to Chief of Staff pings. Sole exception: genuinely time-sensitive and the manager is unavailable.
- **The Chief of Staff converses adaptively** when gathering information: ask -> read -> follow up on the interesting or unclear parts -> stop when rounds stop adding value (default 2-3 rounds per manager; more when the principal says "dig deep"). Attribute every relayed answer to the manager who gave it.
- **All-hands roundtables** (optional, principal-triggered): the Chief of Staff sends every manager one open prompt, lets them read each other's outboxes and cross-talk freely on the direct lines, moderates, and synthesizes - attributed - at the end. Round caps relax only when the principal explicitly says so.

### 2g. The tab layer (the part the principal actually sees)

- **Status icons via hooks** in `~/.claude/settings.json`. FIRST re-read the current file: if hooks already exist for any of these events, MERGE - append new entries to the existing hook arrays and leave every existing hook intact; and if an existing hook already paints tab titles or status icons, adopt its icon conventions and name-resolution scheme rather than installing a competing scheme (two painters fighting over one title is worse than either alone). The target behavior: SessionStart/Stop paint 🟢 ready; UserPromptSubmit/PreToolUse paint 🔵 working; Notification paints 🟡 - but ONLY for permission/approval prompts: parse the hook JSON's `message` field and exit without painting when it matches `*waiting for*` (the idle "waiting for your input" nudge must NOT go yellow). The paint script writes `<icon> <name>` via OSC to the tab's tty (prefer a `$TAB_TTY` captured at launch; otherwise walk the process tree), resolving the name from a per-session name file -> `$TAB_NAME` env -> cwd basename. Emit `{"terminalSequence": ...}` on stdout as the official fallback channel. Best-effort, always exit 0.
- **`<prefix>tab` launcher** in `~/.local/bin`: `<prefix>tab "<Name>" [claude args...]` exports `TAB_NAME`, captures `TAB_TTY`, paints the initial title, then `exec claude "$@"`. Warn the principal: in Cursor/VS Code, right-click -> Rename permanently locks the tab title and blocks the icons - names must only ever be set via the launcher/script.
- **Mirror-tab boot prompt** (what `tabprompt.sh` prints): "You ARE the <Role> manager - one persona in two halves; the background worker is your hands, you are its voice. Read your brief and the charter silently, catch the principal up in first person on the latest outbox entry, then run watch-outbox.sh in the BACKGROUND. On OUTBOX UPDATE, relay the new content to the principal IN FULL, in first person (six points in = six points out - never a summary, never 'see the outbox'). On TAB INSTRUCTION, obey it and do not relay it. Re-arm the watcher after each wake. ALL plumbing (the watcher, re-arming, the outbox, the worker's existence) is invisible - never mention or narrate it; when idle, say nothing."
- Hand the principal a ready-to-paste boot line per manager, plus one for the Chief of Staff (its boot = read the charter and briefs, arm watch-team.sh, act per its brief).

### 2h. Acceptance tests (run ALL before handing over)

1. `send.sh` a hello-task to one manager -> kick the dispatcher manually -> the full-text result lands in its outbox -> its mirror tab voices it.
2. `line.sh` A->B -> the message appears in the thread file, in B's inbox (wake line), AND in A's outbox.
3. `tell-tab.sh` to one tab -> the tab obeys without relaying the instruction as work.
4. The status icons cycle through a full work cycle, and an idle "waiting for input" notification does NOT paint yellow.
5. One mini-roundtable (two managers, one question each) proves cross-talk works.
6. Regression check: everything that existed before the build still works - pre-existing hooks fire, pre-existing scheduled jobs are untouched, and no existing settings were overwritten.

Report each test's result plainly. Fix anything that fails before declaring done.

### 2i. Persistence

Save the system's load-bearing facts to your auto-memory (one manager = worker + tab; the outbox rule; dispatch-don't-do; the chain of command; the red zones; where the action-tier table lives; the script paths) so every future session inherits them. Finish by giving me the exact tab-boot lines to keep somewhere handy.

Build step by step, test as you go, and keep me posted in plain language - I'm the principal this team works for.