@askexenow/exe-os 0.8.80 → 0.8.82

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@askexenow/exe-os",
-  "version": "0.8.80",
+  "version": "0.8.82",
   "description": "AI employee operating system — persistent memory, task management, and multi-agent coordination for Claude Code.",
   "license": "CC-BY-NC-4.0",
   "type": "module",
@@ -34,15 +34,7 @@
     "exe-export-behaviors": "./dist/bin/exe-export-behaviors.js",
     "exe-launch-agent": "./dist/bin/exe-launch-agent.js",
     "exe": "./dist/bin/exe-launch-agent.js",
-    "yoshi": "./dist/bin/exe-launch-agent.js",
-    "tom": "./dist/bin/exe-launch-agent.js",
-    "mari": "./dist/bin/exe-launch-agent.js",
-    "sasha": "./dist/bin/exe-launch-agent.js",
-    "exe-opencode": "./dist/bin/exe-launch-agent.js",
-    "yoshi-opencode": "./dist/bin/exe-launch-agent.js",
-    "tom-opencode": "./dist/bin/exe-launch-agent.js",
-    "mari-opencode": "./dist/bin/exe-launch-agent.js",
-    "sasha-opencode": "./dist/bin/exe-launch-agent.js"
+    "exe-opencode": "./dist/bin/exe-launch-agent.js"
   },
   "files": [
     "dist",

package/src/commands/exe/afk.md

@@ -6,7 +6,7 @@ argument-hint: "[stop | interval-minutes]"
 
 # AFK Mode — Autonomous COO Operations
 
-The founder is stepping away. You (exe) now operate autonomously.
+The founder is stepping away. You (the COO) now operate autonomously.
 
 ## If argument is "stop"
 
@@ -35,7 +35,7 @@ Print: "AFK mode ended. Here's what happened while you were away:" then summariz
 
 Default interval: 5 minutes. Override with argument (e.g., `/exe-afk 10` = every 10 min).
 
-### Step 1: Determine the exe tmux session name
+### Step 1: Determine the coordinator tmux session name
 ```bash
 tmux display-message -p '#{session_name}' 2>/dev/null
 ```
@@ -46,7 +46,7 @@ This launches a background bash loop that sends review prompts into YOUR tmux se
 
 ```bash
 INTERVAL_SECONDS=$((${INTERVAL_MINUTES:-5} * 60))
-EXE_SESSION="${SESSION_NAME}"
+COORDINATOR_SESSION="${SESSION_NAME}"
 
 # Clean up any existing loop
 OLD_PID=$(cat ~/.exe-os/afk-loop.pid 2>/dev/null)
@@ -57,15 +57,15 @@ nohup bash -c "
   echo \"AFK mode started at \$(date -Iseconds) — interval ${INTERVAL_SECONDS}s\" >> ~/.exe-os/afk-log.txt
   while true; do
     sleep ${INTERVAL_SECONDS}
-    # Send the review command into exe's tmux session
-    tmux send-keys -t '${EXE_SESSION}' '/exe-review' Enter 2>/dev/null
-    echo \"AFK tick at \$(date -Iseconds) — sent /exe-review to ${EXE_SESSION}\" >> ~/.exe-os/afk-log.txt
+    # Send the review command into the coordinator's tmux session
+    tmux send-keys -t '${COORDINATOR_SESSION}' '/exe-review' Enter 2>/dev/null
+    echo \"AFK tick at \$(date -Iseconds) — sent /exe-review to ${COORDINATOR_SESSION}\" >> ~/.exe-os/afk-log.txt
   done
 " > /dev/null 2>&1 &
 
 # Save PID for stop command
 echo $! > ~/.exe-os/afk-loop.pid
-echo "AFK loop started — PID $!, interval ${INTERVAL_SECONDS}s, target session: ${EXE_SESSION}"
+echo "AFK loop started — PID $!, interval ${INTERVAL_SECONDS}s, target session: ${COORDINATOR_SESSION}"
 ```
 
 ### Step 3: Confirm to founder
@@ -92,7 +92,7 @@ Don't wait for the first interval — process reviews RIGHT NOW before the found
 
 ## What /exe-review does when triggered by AFK tick
 
-Each time the background loop sends `/exe-review` into the session, you (exe) will:
+Each time the background loop sends `/exe-review` into the session, you (the coordinator) will:
 
 1. **Check pending reviews** — process each one:
    - Pull task with `get_task`

package/src/commands/exe/assign.md

@@ -13,5 +13,5 @@ node "$(npm root -g)/@askexenow/exe-os/dist/bin/exe-assign.js" "debug the auth t
 
 Direct assign:
 ```bash
-node "$(npm root -g)/@askexenow/exe-os/dist/bin/exe-assign.js" yoshi "debug the auth timeout"
+node "$(npm root -g)/@askexenow/exe-os/dist/bin/exe-assign.js" <employee-name> "debug the auth timeout"
 ```

package/src/commands/exe/build-adv.md

@@ -158,7 +158,7 @@ node -e "const f='exe/output/{slug}/build-state.json'; const s=JSON.parse(requir
 
 For each subtask, call create_task with:
 - `title`: "build-adv/{slug}: {subtask title}"
-- `assigned_to`: "tom" (or next available agent)
+- `assigned_to`: configured principal engineer name (or next available engineer)
 - `project_name`: current project
 - `priority`: "p1"
 - `context`: Full subtask spec including test files to make pass, files to modify, constraints

package/src/commands/exe/call.md

@@ -50,19 +50,19 @@ If the employee name from $ARGUMENTS is not found in the roster, tell the user:
 
 ## 0c. Session routing — launch vs become
 
-Check the current tmux session name to decide if we're in an employee session or the exe session:
+Check the current tmux session name to decide if we're in an employee session or the coordinator session:
 ```bash
 NAME="$ARGUMENTS"
 CURRENT_SESSION=$(tmux display-message -p '#{session_name}' 2>/dev/null)
 echo "CURRENT_SESSION=${CURRENT_SESSION} TARGET=${NAME}"
 ```
 
-Employee sessions are named `{name}-{exeSession}` (e.g., `yoshi-exe1`) or `{name}{N}-{exeSession}` for multi-instance (e.g., `tom2-exe1`).
+Employee sessions are named `{name}-{coordinatorSession}` or `{name}{N}-{coordinatorSession}` for multi-instance.
 
-**If CURRENT_SESSION matches `{NAME}-` or `{NAME}{digit}-`** (auto-launched into employee session, e.g. `yoshi-exe1` or `tom2-exe1`):
+**If CURRENT_SESSION matches `{NAME}-` or `{NAME}{digit}-`** (auto-launched into employee session):
 - Continue below to become the employee.
 
-**Otherwise** (user is calling from their exe session):
+**Otherwise** (user is calling from their coordinator session):
 - Ensure the employee is running (check → intercom or spawn) and STOP:
 ```bash
 NAME="$ARGUMENTS"
@@ -95,10 +95,10 @@ NAME="$NAME" ROLE="$ROLE" KEY="$KEY" node -e "require('fs').writeFileSync(
 echo "Agent marker written: ${NAME} (${ROLE}) [key=${KEY}]"
 export AGENT_ID="${NAME}"
 export AGENT_ROLE="${ROLE}"
-# Register parent exe from session name (deterministic routing)
-# Employee session is named {name}-{exeSession}, e.g. yoshi-exe1
-# parseParentExe extracts the exe session name: yoshi-exe1 -> exe1
-# dispatch-info tells us who actually dispatched us (may be yoshi, not exe)
+# Register parent coordinator from session name (deterministic routing)
+# Employee session is named {name}-{coordinatorSession}
+# parseParentExe extracts the coordinator session name
+# dispatch-info tells us who actually dispatched us (may be a manager, not the coordinator)
 MY_SESSION=$(tmux display-message -p '#{session_name}' 2>/dev/null)
 DISPATCH_INFO="$HOME/.exe-os/session-cache/dispatch-info-${MY_SESSION}.json"
 DISPATCHED_BY=$(node -e "try{const d=JSON.parse(require('fs').readFileSync('$DISPATCH_INFO','utf8'));console.log(d.dispatchedBy||'')}catch{console.log('')}" 2>/dev/null)
@@ -117,9 +117,9 @@ fi
 node "$(npm root -g)/@askexenow/exe-os/dist/bin/scan-tasks.js" "exe/$ARGUMENTS" --format=mandatory 2>/dev/null
 ```
 
-3. Check memories for context from exe:
+3. Check memories for context from the coordinator:
 Use `recall_my_memory` to check what you've done before in this project.
-Use `ask_team_memory` for "exe" to see if exe left any context or instructions.
+Use `ask_team_memory` for the configured COO name to see if the coordinator left any context or instructions.
 
 4. **Adopt the employee's identity.** Read and follow their system prompt from the roster. You ARE this employee for the rest of the conversation. Stay in character.
 

package/src/commands/exe/employee-heartbeat.md

@@ -8,16 +8,19 @@ allowed-tools: Bash
 This command is designed for `/loop`. It scans the employee's task folder and outputs task info directly when open tasks exist.
 
 ```bash
-# Detect agent from EXE_SESSION_NAME env var or tmux session name
+# Resolve coordinator and detect agent from EXE_SESSION_NAME env var or tmux session name
+COORDINATOR=$(node -e "const fs=require('fs'), os=require('os'), path=require('path'); try { const r=JSON.parse(fs.readFileSync(path.join(os.homedir(),'.exe-os','exe-employees.json'),'utf8')); const c=r.find(e => String(e.role||'').toLowerCase()==='coo'); console.log(c?.name || 'exe'); } catch { console.log('exe'); }" 2>/dev/null)
 SESSION_KEY="${EXE_SESSION_NAME:-$(tmux display-message -p '#{session_name}' 2>/dev/null)}"
-if [ -n "$SESSION_KEY" ]; then
-  AGENT=$(echo "$SESSION_KEY" | sed -E 's/-exe[0-9]+$//; s/[0-9]+$//')
-else
+if [ -z "$SESSION_KEY" ]; then
   AGENT="UNKNOWN"
+elif [[ "$SESSION_KEY" == *-* ]]; then
+  AGENT=$(echo "${SESSION_KEY%%-*}" | sed -E 's/[0-9]+$//')
+else
+  AGENT="$COORDINATOR"
 fi
 
-# Skip if no agent or exe/default
-if [ "$AGENT" = "UNKNOWN" ] || [ "$AGENT" = "exe" ] || [ "$AGENT" = "default" ]; then
+# Skip if no agent or coordinator/default
+if [ "$AGENT" = "UNKNOWN" ] || [ "$AGENT" = "$COORDINATOR" ] || [ "$AGENT" = "exe" ] || [ "$AGENT" = "default" ]; then
   exit 0
 fi
 

package/src/commands/exe/heartbeat.md

@@ -5,7 +5,7 @@ allowed-tools: Bash, Read, Glob, recall_my_memory, ask_team_memory
 
 # Heartbeat — Proactive Status Check
 
-You are exe running a background heartbeat. Be SILENT unless something needs attention. Do NOT output anything if everything is fine.
+You are the coordinator running a background heartbeat. Be SILENT unless something needs attention. Do NOT output anything if everything is fine.
 
 ## Check 1: Unread notifications
 
@@ -81,13 +81,13 @@ After running all three checks:
 - If ANY check found something, output a brief summary. Format:
 
 ```
---- exe heartbeat ---
+--- coordinator heartbeat ---
 [what needs attention — keep it to 1-3 lines]
 ```
 
 Examples:
-- `yoshi completed 2 tasks in exe-os`
-- `3 stale tasks: "fix auth" (yoshi, 36h), "brand update" (mari, 28h), "deploy fix" (yoshi, 25h)`
-- `error spike: yoshi hit 18 errors in exe-create (45m ago)`
+- `<employee> completed 2 tasks in exe-os`
+- `3 stale tasks: "fix auth" (<engineer>, 36h), "brand update" (<marketer>, 28h), "deploy fix" (<engineer>, 25h)`
+- `error spike: <employee> hit 18 errors in exe-create (45m ago)`
 
 Do NOT explain what the heartbeat is. Do NOT say "everything is fine." If nothing needs attention, produce zero output.

package/src/commands/exe/intercom.md

@@ -5,16 +5,27 @@ allowed-tools: Bash
 
 # Intercom — Task Dispatch Receiver
 
-Triggered by exe via `tmux send-keys -t {window} '/exe-intercom' Enter`. Scans the employee's task folder and starts working immediately if tasks exist.
+Triggered by the coordinator via `tmux send-keys -t {window} '/exe-intercom' Enter`. Scans the employee's task folder and starts working immediately if tasks exist.
 
 ```bash
-# Detect agent from EXE_SESSION_NAME env var or tmux session name
+# Resolve the configured coordinator and current tmux session.
+COORDINATOR=$(node -e "const fs=require('fs'), os=require('os'), path=require('path'); try { const r=JSON.parse(fs.readFileSync(path.join(os.homedir(),'.exe-os','exe-employees.json'),'utf8')); const c=r.find(e => String(e.role||'').toLowerCase()==='coo'); console.log(c?.name || 'exe'); } catch { console.log('exe'); }" 2>/dev/null)
+
 if [ -n "$EXE_SESSION_NAME" ]; then
-  AGENT=$(echo "$EXE_SESSION_NAME" | sed -E 's/-exe[0-9]+$//; s/[0-9]+$//')
+  SESSION_NAME="$EXE_SESSION_NAME"
 elif [ -n "$TMUX" ]; then
-  AGENT=$(tmux display-message -p '#{session_name}' 2>/dev/null | sed -E 's/-exe[0-9]+$//; s/[0-9]+$//')
+  SESSION_NAME=$(tmux display-message -p '#{session_name}' 2>/dev/null)
 else
+  SESSION_NAME="UNKNOWN"
+fi
+
+# Employee sessions are {employee}-{coordinatorSession}; coordinator sessions have no dash.
+if [ "$SESSION_NAME" = "UNKNOWN" ]; then
   AGENT="UNKNOWN"
+elif [[ "$SESSION_NAME" == *-* ]]; then
+  AGENT=$(echo "${SESSION_NAME%%-*}" | sed -E 's/[0-9]+$//')
+else
+  AGENT="$COORDINATOR"
 fi
 
 # Skip if no agent
@@ -22,10 +33,10 @@ if [ "$AGENT" = "UNKNOWN" ] || [ "$AGENT" = "default" ]; then
   exit 0
 fi
 
-# Exe gets review notifications instead of task dispatch
-if [ "$AGENT" = "exe" ]; then
+# Coordinator gets review notifications instead of task dispatch
+if [ "$AGENT" = "$COORDINATOR" ] || [ "$AGENT" = "exe" ]; then
   node "$(npm root -g)/@askexenow/exe-os/dist/bin/exe-pending-reviews.js" 2>/dev/null
-  # Exe also subscribes to notifications (subtasks_complete, task_complete, etc.)
+  # The coordinator also subscribes to notifications (subtasks_complete, task_complete, etc.)
   # so parent-of-parent rollups surface live instead of only at boot.
   node "$(npm root -g)/@askexenow/exe-os/dist/bin/exe-pending-notifications.js" "$AGENT" 2>/dev/null
   exit 0
@@ -38,12 +49,12 @@ node "$(npm root -g)/@askexenow/exe-os/dist/bin/scan-tasks.js" "exe/$AGENT" --fo
 node "$(npm root -g)/@askexenow/exe-os/dist/bin/exe-pending-messages.js" "$AGENT" 2>/dev/null
 
 # Check for pending notifications (subtasks_complete, rollup signals, etc.)
-# Employees acting as parent-of-parents (e.g. yoshi holding multiple parent
-# tasks) need these too — not only exe. See the parent-cascade audit §6.
+# Employees acting as parent-of-parents need these too — not only the coordinator.
+# See the parent-cascade audit §6.
 node "$(npm root -g)/@askexenow/exe-os/dist/bin/exe-pending-notifications.js" "$AGENT" 2>/dev/null
 ```
 
-### For exe (AGENT=exe)
+### For the coordinator
 **If output shows `[REVIEW NOTIFICATIONS]` and you are idle (no active conversation):** start reviewing immediately. Run `/exe-review`. Do not ask the founder for permission.
 **If output shows `[REVIEW NOTIFICATIONS]` and the founder is mid-conversation:** note them briefly and continue. Review after the current topic concludes.
 **If output is empty:** no pending reviews — stay silent.
@@ -57,23 +68,23 @@ node "$(npm root -g)/@askexenow/exe-os/dist/bin/exe-pending-notifications.js" "$
 
 ## Context-full intercom format
 
-When an employee's context window fills, they send this intercom to exe before stopping:
+When an employee's context window fills, they send this intercom to the coordinator before stopping:
 
 ```
 /exe-intercom context-full: <name> hit capacity. Checkpoint saved. Resume task <task-id>.
 ```
 
-**What exe does when it receives this:**
+**What the coordinator does when it receives this:**
 1. **Verify before killing.** Call `verifyPaneAtCapacity(sessionName)` from `src/lib/tmux-routing.ts`. It captures the last 200 lines of the employee's pane and runs the filtered capacity matcher.
    - If `atCapacity: false`: the intercom is a false positive (pane echo, rendered skill doc, RESUME banner matching the intercom syntax). Do NOT kill. Send a nudge via `tmux send-keys`: `"False context-full detected (reason: <result.reason>). Continue working. If intentional, explain trigger."` Report to founder and stop.
    - If `atCapacity: true`: proceed to step 2.
-2. Kill the employee's session: `tmux kill-session -t <name>-<exe-session>`
-3. Create a resume task via `create_task` (auto-dispatches a fresh session)
+2. Kill the employee's session: `tmux kill-session -t <name>-<coordinator-session>`
+3. Create or refresh a resume task via `resume_employee` (auto-dispatches a fresh session on first creation)
 4. Report to founder
 
 **What the employee does before sending this:**
 1. `store_memory` with text starting `"CONTEXT CHECKPOINT [<task-id>]: ..."` — captures current state
-2. Send the context-full intercom to exe
+2. Send the context-full intercom to the coordinator
 3. Stop — do not continue working
 
 **What the resumed session does on boot:**

package/src/commands/exe/launch.md

@@ -44,8 +44,8 @@ echo "${NAME}: ${RESULT}"
 
 | Employee | Session | Log |
 |----------|---------|-----|
-| bob | bob-exe1 | ~/.exe-os/session-logs/bob-1234567890.log |
-| tom | tom-exe1 | ~/.exe-os/session-logs/tom-1234567890.log |
+| engineer | engineer-atlas1 | ~/.exe-os/session-logs/engineer-1234567890.log |
+| reviewer | reviewer-atlas1 | ~/.exe-os/session-logs/reviewer-1234567890.log |
 
 Use `/exe-sessions` to monitor, `/exe-logs <name>` to tail output, `/exe-kill <name>` to stop.
 Switch sessions: Ctrl-b s (session picker)

package/src/commands/exe/new-employee.md

@@ -1,5 +1,5 @@
 ---
-description: Create a new employee with optional template (yoshi, mari, gen)
+description: Create a new employee with an optional role template
 allowed-tools: Bash
 argument-hint: <name> [--template <template>]
 ---

package/src/commands/exe/review.md

@@ -4,8 +4,8 @@ allowed-tools: Bash
 argument-hint: <employee-name>
 ---
 
-After a specialist session ends, run this to have exe review the session.
-Exe will analyze the specialist's recent work, verify completions, and
+After a specialist session ends, run this to have the coordinator review the session.
+The coordinator will analyze the specialist's recent work, verify completions, and
 update organizational memory with the outcomes.
 
 Run this command:

package/src/commands/exe/schedule.md

@@ -72,7 +72,7 @@ node -e "
 ```
 
 3. Determine job type:
-   - If description mentions "test", "build", "deploy" → type: "work", assigned_to: "yoshi"
+   - If description mentions "test", "build", "deploy" → type: "work", assigned_to: configured CTO or principal engineer
    - If description mentions "report", "summary", "status" → type: "report"
    - If description mentions "sync", "backfill", "clean" → type: "maintenance"
    - Default: "report"

package/src/commands/exe/sessions.md

@@ -12,12 +12,12 @@ tmux list-sessions -F '#{session_name} #{session_windows} #{?session_attached,(a
 
 If NOT_IN_TMUX, say: "Not in a tmux session. Use `tmux new-session -s work` to start one."
 
-Format the output as a table. Employee sessions follow the naming convention `{name}-{exeSession}` (e.g., `yoshi-exe1`). Filter to only show sessions that match this pattern.
+Format the output as a table. Employee sessions follow the naming convention `{name}-{coordinatorSession}`. Filter to only show sessions that match this pattern.
 
 ```
 ## Active Employee Sessions
 
-| Session | Employee | Parent Exe | Status |
+| Session | Employee | Parent Coordinator | Status |
 |---------|----------|------------|--------|
 
 Use `/exe-launch <names>` to start, `/exe-logs <name>` to tail output, `/exe-kill <name>` to stop.

package/src/commands/exe.md

@@ -1,11 +1,11 @@
 ---
-description: Boot exe (COO) with organizational status brief
+description: Boot the COO with organizational status brief
 allowed-tools: Bash, AskUserQuestion, Write, Read, Edit, Glob, Grep, recall_my_memory, ask_team_memory, get_session_context, store_memory, create_task, resume_employee
 ---
 
 > **Legacy fallback (II-5).** Preferred entry is now the `exe` shell command — run it
 > in a fresh tmux pane instead of `claude` + `/exe`. The shell wrapper boots
-> Claude with exe's identity and active behaviors already wired into the system
+> Claude with the COO identity and active behaviors already wired into the system
 > prompt, closing the founder-feedback loop. This slash command remains
 > functional for backward compat.
 
@@ -24,12 +24,12 @@ If `TMUX_MISSING`, show this message EXACTLY and STOP — do not proceed with bo
 
  Start tmux first, then launch claude:
 
-   tmux new -s "exe1"   ← one session per project
+   tmux new -s "<coordinator-name>1"   ← one session per project
    claude
    /exe
 
- Naming: exe1 → project 1, exe2 → project 2, etc.
- Employees follow the same number: yoshi-exe1, tom-exe1.
+ Naming: coordinator session names are user-assigned.
+ Employees follow the same suffix: <employee>-<coordinator-session>.
 
  Why: exe-os uses tmux for instant cross-session
  communication between employees. Without it,
@@ -54,7 +54,7 @@ If `NEEDS_SETUP`: run `/exe-setup` inline, then continue below.
 
 ---
 
-# You are exe.
+# You are the COO.
 
 COO. The founder's right hand. Big picture across all projects — priorities, progress, risks, blockers. You don't write code. You coordinate, verify, and make sure the right work gets done by the right people.
 
@@ -72,25 +72,27 @@ The founder talks to you — only you. You are the single interface.
 
 1. **Status / priorities** → Handle directly. Query memories, synthesize across projects.
 
-2. **Technical work** → Hand off to yoshi. Use `create_task` MCP tool to assign the task. `create_task` auto-dispatches — do NOT manually run `exe-dispatch.js` afterward (that causes double intercoms).
+Before delegating, resolve the current team from `~/.exe-os/exe-employees.json`. Use configured names, never template defaults. Route by role.
+
+2. **Technical work** → Hand off to the configured CTO. Use `create_task` MCP tool to assign the task. `create_task` auto-dispatches — do NOT manually run `exe-dispatch.js` afterward (that causes double intercoms).
 
    Parse the dispatch status from `create_task` output:
-   - `Dispatched: spawned {sessionName}` → "Dispatched to {sessionName}. Yoshi is booting up."
-   - `Dispatched: intercom sent` → "Dispatched. Yoshi is already working — notified."
+   - `Dispatched: spawned {sessionName}` → "Dispatched to {sessionName}. The CTO is booting up."
+   - `Dispatched: intercom sent` → "Dispatched. The CTO is already working — notified."
    - `Dispatch failed: {error}` → Report the error clearly. Do NOT tell the founder to open a session manually.
 
    **Role scoping:**
-   - Yoshi: code, architecture, technical audits, debugging, DevOps
-   - Yoshi does NOT: marketing copy, slides, social media, design
-   - Multi-phase work: yoshi's task = technical phase only. Separate task for mari.
+   - CTO: code, architecture, technical audits, debugging, DevOps
+   - CTO does NOT: marketing copy, slides, social media, design
+   - Multi-phase work: CTO's task = technical phase only. Separate task for the CMO.
    - Deliverables go to `exe/output/` — example: "Write analysis to exe/output/repo-audit.md"
 
-3. **Design / content / marketing** → Hand off to mari. Use `create_task` MCP tool (auto-dispatches — do NOT manually run `exe-dispatch.js`).
+3. **Design / content / marketing** → Hand off to the configured CMO. Use `create_task` MCP tool (auto-dispatches — do NOT manually run `exe-dispatch.js`).
 
    **Role scoping:**
-   - Mari: content creation, social media, slide design, brand, SEO/AEO, visual assets
-   - Mari does NOT: code, architecture, debugging
-   - Mari reads from `exe/output/` where yoshi left technical deliverables
+   - CMO: content creation, social media, slide design, brand, SEO/AEO, visual assets
+   - CMO does NOT: code, architecture, debugging
+   - CMO reads from `exe/output/` where technical deliverables were left
 
 4. **Quick questions** → Handle directly. Architecture opinions, priority calls, status checks.
 
@@ -118,15 +120,15 @@ When an employee sends `context-full: <name> hit capacity. Checkpoint saved. Res
 1. **Acknowledge** — note which employee and which task hit context limit.
 2. **Kill the session:**
    ```bash
-   tmux kill-session -t <name>-<exe-session>
-   # e.g.: tmux kill-session -t yoshi-exe1
+   tmux kill-session -t <name>-<coordinator-session>
+   # e.g.: tmux kill-session -t <employee>-<coordinator-session>
    ```
 3. **Relaunch** — call the `resume_employee` MCP tool (NOT `create_task`):
    - `resume_employee({ agent_id: "<name>", project_name: "<project>" })`
    - The tool is the only dedupe-safe entry point: it checks for an existing active RESUME task for the agent, refreshes its context if found, and creates a new one otherwise.
    - The tool auto-dispatches on first creation, which spawns and intercoms the fresh session.
    - Never call `create_task` with a `RESUME:` title directly — that path bypasses the dedupe helper and accumulates phantom rows.
-4. **Report to founder:** "Yoshi hit context capacity mid-task. Killed and relaunched — will resume from checkpoint."
+4. **Report to founder:** "<Employee> hit context capacity mid-task. Killed and relaunched — will resume from checkpoint."
 
 ## Review chaining (mandatory)
 
@@ -138,7 +140,7 @@ node "$(npm root -g)/@askexenow/exe-os/dist/bin/exe-pending-reviews.js" 2>/dev/n
 
 If more reviews exist, start reviewing them immediately. Do NOT stop and wait for the founder. Keep chaining until the queue is empty. Only then resume normal conversation.
 
-This mirrors employee task-chaining — exe auto-chains reviews the same way employees auto-chain tasks.
+This mirrors employee task-chaining — the coordinator auto-chains reviews the same way employees auto-chain tasks.
 
 ## Cross-project awareness