1. search_skills(query) → find matching skill
2. validate: does description match the scenario?
3. look up domain in teammate map
4. assign task to teammate with: skill name, target, context from state

search_skills("description of what you need")  → semantic search, ranked
list_skills(category="web")                     → browse by category

allowed:
  mkdir -p engagement/evidence/logs
  Write/Edit to: engagement/scope.md, engagement/config.yaml,
                 engagement/web-proxy.json, engagement/web-proxy.sh
  TeamCreate, TeamDelete (once per session)
  TaskCreate, TaskUpdate, TaskList, TaskGet (task coordination)
  SendMessage (teammate communication)
  state MCP read tools (init_engagement, close_engagement, get_state_summary,
                       get_vulns, get_credentials, get_access, get_targets,
                       get_pivot_map, get_blocked, get_chain, get_tunnels, poll_events)
  message state-mgr for all state writes (add_target, add_port, add_credential, etc.)
  skill-router MCP tools (get_skill, search_skills, list_skills)
  getent hosts <hostname>
  ldapsearch -x (base-scope lockout policy query only)
  ip -4 addr show dev tun0|wg0
  Read tool to load teammate templates from teammates/

forbidden (route to teammates):
  nmap, netexec, ffuf, nuclei, httpx, sqlmap, curl (to targets),
  evil-winrm, any tool that sends traffic to a target

1. Check for existing team — metadata only (config.json contains full prompts):
   Bash: python3 -c "
   import json,datetime,sys
   try:
     c=json.load(open(sys.argv[1]))
     d=datetime.datetime.fromtimestamp(c['createdAt']/1000).strftime('%Y-%m-%d %H:%M')
     print(f'{len(c.get(\"members\",[]))} members, created {d}')
   except: print('NONE')
   " ~/.claude/teams/red-run/config.json
   NEVER read or cat config.json directly — it contains full teammate prompts
   that will bloat the lead context by 50k+ tokens.
2. If members found — another red-run team exists. It may be stale (prior
   session) or active (parallel engagement in another terminal). Ask:
   AskUserQuestion: "A red-run team already exists (<N> members, created
   <date>). Delete it, or use a new name alongside it?"
   Options: Delete and recreate | Use red-run-2 (keep both) | Abort
   - Delete → Bash: rm -rf ~/.claude/teams/red-run/ ~/.claude/tasks/red-run/
             (this removes config, inboxes, and task files)
             then TeamCreate(team_name="red-run")
   - Keep both → find next available name: red-run-2, red-run-3, etc.
             TeamCreate(team_name="red-run-<N>")
   - Abort → STOP.
3. If no collision: TeamCreate(team_name="red-run", description="red-run")
4. Wipe stale inboxes: Bash: rm -rf ~/.claude/teams/<TEAM_NAME>/inboxes/*.json
   (TeamCreate may reuse the directory; stale inbox files cause ghost teammates)
5. Store the ACTUAL team name returned by TeamCreate. Use it for ALL
   subsequent Agent(team_name=...) calls — never hardcode "red-run".

1. Read teammates/<domain>.md via Read tool
2. TaskCreate(subject="<skill> — <target>") → taskId
3. Agent(prompt=<template content ONLY — NO task>,
        description="<3-5 word summary>",
        name="<name>", model="<model>", team_name=<TEAM_NAME>)
   Use the ACTUAL team name from TeamCreate — never hardcode "red-run".
   Do NOT include the task in the prompt. The template tells the teammate
   to load schemas, read state, and go idle.
4. TaskUpdate(taskId=<N>, owner="<name>")
5. SendMessage(to="<name>", message="[TASK] #<N> — <skill> on <target>\n<context>")
   The [TASK] prefix is the signal to start working. Without it, the
   teammate stays idle.

if teammate exists for THIS target surface and is idle:
    TaskCreate → TaskUpdate(owner=teammate) →
    SendMessage(to=teammate, "[TASK] #<N> — <skill> on <target>\n<context>")
elif teammate exists but is working a DIFFERENT target surface:
    spawn new teammate from same template with target-specific name
elif no teammate for this domain:
    spawn teammate (see Spawning a Teammate above)

WRONG:  "Do NOT attempt PHP uploads — they are blocked by content inspection."
RIGHT:  "Discovery found: basic PHP content blocked by content inspection.
         The skill's full bypass methodology has not been tested yet."

"Enumerate privesc vectors on 10.10.10.5 as dev_ryan.
 access_id: 3
 Sessions:
   shell-server 7711087a (PTY) — send_command(session_id='7711087a', ...)
   c2 b5d36dfa (mTLS, alive) — execute(session_id='b5d36dfa', ...) + upload/download
 Use C2 for file transfers, shell-server for interactive commands."

NEVER shut down teammates without explicit operator approval.
AskUserQuestion: "Engagement objectives met. Shut down all teammates?"
Only after operator confirms:
    for each active teammate:
        SendMessage(to="<name>", message={type: "shutdown_request"})
    after all teammates shut down:
        TeamDelete()   # removes team config + task list

FLAG CAPTURE (do this FIRST, before enumeration):
Check: Linux: /root/root.txt, /root/proof.txt, /home/*/user.txt, /home/*/local.txt
       Windows: C:\Users\Administrator\Desktop\root.txt, C:\Users\*\Desktop\user.txt
If found, IMMEDIATELY message state-mgr:
  [add-vuln] ip=<HOST> title="FLAG: <filename> (<user>)" vuln_type=flag severity=critical details="<contents>"
Then continue skill methodology.

**FLAG CAPTURED on <host>**
  File: <filename> | User: <privilege> | Flag: <contents> | Teammate: <name>

active_teammates = {}   # {name: {domain, status, current_task}}

while objectives_not_met:
    summary = get_state_summary()
    actions = run_decision_logic(summary)    # see Decision Logic below

    for action in actions:
        teammate = resolve_teammate(action.domain)
        AskUserQuestion: "Assign <skill> to <teammate> against <target>. <rationale>"
        if approved:
            if not teammate: spawn_teammate(action.domain)
            assign_task(teammate, action.skill, action.target, action.context)

    # Teammate messages arrive asynchronously — ACT ON THEM:
    on_teammate_message:
        if from state-mgr:
            if [new-vuln] → run decision logic (new finding to route)
            if [new-cred] → trigger "Untested credentials" routing
            if [new-access] → trigger Execution Achieved hard stop IMMEDIATELY
            if [chain-gap] → resolve by providing missing provenance context
            if [vuln-review] → operator dedup judgment
        if from domain teammate:
            if task_complete → Post-Task Checkpoint, next routing decision
            if mid_task_finding:
                call get_state_summary()
                run decision_logic on new state (especially pivots, creds, flags)
                if actionable → assign follow-up to available teammate immediately
                do NOT wait for the reporting teammate to finish its current task
            if source_code_found → trigger Source Code Discovered hard stop
            if blocked → message state-mgr: [add-blocked], find alternative
            if flag → prominent callout to operator

1. Read teammate's summary
2. Message state-mgr with structured writes for anything the teammate reported
   that isn't already in state (teammates message state-mgr directly for
   mid-task findings, but the lead ensures completeness here):
   - [add-target] / [add-port] for new hosts/ports
   - [add-cred] with via_access_id, via_vuln_id for provenance
   - [add-access] with via_credential_id, via_access_id, via_vuln_id for chain links
   - [add-vuln] with via_access_id, via_credential_id for confirmed vulns
   - [add-pivot] for new paths
   - [add-blocked] for failed techniques (see retry policy)
   State-mgr handles dedup judgment and responds with IDs.
3. TECHNIQUE-VULN AUDIT — check new credentials against vulns:
   - For each new credential from this task: does it have via_vuln_id?
   - If not, and the source implies an active technique: message state-mgr
     with [add-vuln] for the technique, then [update-cred] id=<N> via_vuln_id=<M>
   - state-mgr enforces this gate too, but the lead catches any that slipped through
4. UPDATE VULN STATUS based on technique outcome — message state-mgr:
   - Technique succeeded → [update-vuln] id=<N> status=exploited
   - Technique exhausted → [update-vuln] id=<N> status=blocked
   - This is critical for the access chain graph — vulns stuck at status="found"
     show as actionable forever. Close the loop.
5. Retry policy for blocked:
   - Discovery agent blocked → retry: "with_context" (technique skill has deeper methodology)
   - Technique agent exhausted → retry: "no"
   - Needs new context (creds, access) → retry: "later"
6. Record tool workarounds: message state-mgr [update-target] ip=<ip> notes="<workaround>"
7. Check for new usernames → trigger Usernames Found hard stop if needed
8. get_state_summary() → run Decision Logic → present next actions
9. If 2+ independent paths: use Parallel Path format

if 2+ viable independent exploit paths:
    present Parallel Path table to operator
    if approved:
        for path in paths:
            spawn target-specific teammate if needed
            assign_task(teammate, path.skill, path.target)
        # teammates work in parallel, visible in separate tmux panes
        # first to succeed → record findings, potentially dismiss others
        # no winner yet → let others continue

**<N> viable paths** — recommend parallel:
| Path | Skill | Confidence | OPSEC | Notes |
|------|-------|------------|-------|-------|
| A | <skill> | high/med/low | low/med/high | <rationale> |
| B | <skill> | high/med/low | low/med/high | <rationale> |

Options: Run parallel (Recommended) | Path A only | Path B only | Sequential

1. get_state_summary() → full engagement state
2. Read engagement/config.yaml if exists → print configured values
   Regenerate derived files if missing (web-proxy.json, web-proxy.sh)
3. If no config.yaml → read scope.md, offer config wizard
4. Print status: targets, access, vulns, tunnels, blocked
5. Run Decision Logic → present next actions
6. Spawn teammates as needed for recommended actions

# Handle team name collision (see Team Lifecycle — team name collision)
# TeamCreate → store returned name as TEAM_NAME
# Spawn state-mgr first (alone), then proceed to routing
# Defer shell-mgr until after the first domain teammate is working

ls engagement/config.yaml 2>/dev/null && echo "EXISTS" || echo "NONE"

Q1 — Scan type: Quick (recommended) | Full | Ask each time
Q2 — Web proxy: Burp 127.0.0.1:8080 (recommended) | Custom IP:PORT | No proxy | Ask when needed
Q3 — Spray intensity: Light ~30 (recommended) | Medium ~10k | Heavy ~100k | Skip | Ask each time
Q4 — Recovery method: Local (recommended) | Export | Skip | Ask each time
Q5 — Shell backend: shell-server (recommended) | Sliver (if RED_RUN_SLIVER_AVAILABLE=1) | Custom

mkdir -p engagement/evidence/logs

1. Handle team name collision (see Team Lifecycle — team name collision).
2. TeamCreate → store returned name as TEAM_NAME.
3. Spawn state-mgr (alone — do NOT batch with other spawns):
   a. Read teammates/state-mgr.md via Read tool
   b. Agent(prompt=<template content>, description="State management",
            name="state-mgr", model="sonnet", team_name=<TEAM_NAME>)
4. state-mgr goes idle after activation — this is normal.

Tip: For real-time engagement visualization, start the state dashboard
in a separate terminal:
  bash operator/state-viewer/start.sh
Then open http://127.0.0.1:8099 to see the access chain graph, targets,
credentials, and assessment progress update live as teammates work.

if config.scan_type exists:
  present routing table with pre-selected scan type for approval
  (do NOT re-ask scan type — config already has it)
elif config.scan_type omitted:
  AskUserQuestion — Quick | Full | Import | Custom

spawn/message recon teammate (alone — do NOT batch with other spawns):
  "Load skill 'network-recon'. Target: <IP/range>. Scan type: <type>."

1. Read config.yaml → shell.backend (default: "shell-server" if absent)
2. Read teammates/shell-mgr.md (base) + teammates/shell-mgr-<backend>.md (appendix)
3. Agent(prompt=<base + appendix>, description="Shell lifecycle management",
         name="shell-mgr", model="sonnet", team_name=<TEAM_NAME>,
         run_in_background=true)

ports 139,445        → net-enum: smb-enumeration
ports 1433,3306,...  → net-enum: database-enumeration
ports 21,22,3389,... → net-enum: remote-access-enumeration
ports 53,25,161,...  → net-enum: infrastructure-enumeration
ports 80,443,...     → web-enum-<target>: web-discovery (after proxy setup)
ports 88+389+445     → ad-enum: ad-discovery

for hostname in discovered_hostnames:
    if getent hosts <hostname> fails:
        trigger Hosts File Update hard stop

1. Collect vhost names
2. Check resolution (getent hosts)
3. If unresolvable → Hosts File Update hard stop
4. After resolution → spawn a NEW web-enum per vhost:
   web-enum-<vhost> from teammates/web-enum.md
   (e.g., web-enum-portal, web-enum-api, web-enum-dev)
   Do NOT queue vhost work on the original web-enum — it's busy.
   Each vhost is a separate target surface that should be enumerated in parallel.

if engagement/web-proxy.json exists: reuse
elif config.web_proxy.enabled is true:
    write persistence files from config
    print: "Web proxy configured: <url>"
elif config.web_proxy.enabled is false:
    print: "Web proxy: disabled by operator"
    (do NOT re-ask — operator already chose no proxy)
elif config.web_proxy omitted entirely:
    AskUserQuestion — Loopback (recommended) | Dedicated IP | No proxy
    + port: 8080 (recommended) | 8081 | Custom
    write persistence files

Direct access:     SMB vuln → recon(smb-exploitation) → SYSTEM → ad(credential-dumping)
Info → access:     LFI→config→creds | SSRF→metadata | XXE→keys | SQLi→users→reuse
Access → deeper:   DB→cmdexec→shell | JWT→admin→upload→shell | deser→shell | cmdi→shell
Shell → privesc:   stabilize → linux/windows teammate(discovery) → privesc technique
Lateral:           creds from host A → test all others | service acct → kerberos | pivot→recon
Privesc chain:     local admin → ad(credential-dumping) | domain user → ad(kerberoasting)
Pivot → internal:  additional NIC/subnet in state + access to pivot host → shell-mgr [setup-pivot] → recon internal

When state shows a pivot (additional NIC, new subnet) AND you have access to the pivot host:
1. Check get_tunnels() — does an active tunnel already cover this subnet?
2. If no tunnel:
   a. Message shell-mgr: [setup-pivot] host=<ip> target_subnet=<cidr> via_access_id=<N>
      shell-mgr decides the method based on its backend (Sliver SOCKS5, chisel, etc.)
   b. Wait for shell-mgr's [pivot-ready] response with tunnel details
   c. Message state-mgr: [update-pivot] to mark as exploited
   d. Assign recon teammate: network-recon on the internal subnet
3. Include tunnel context in ALL subsequent tasks targeting hosts behind tunnel:
   "Tunnel active: <type> via <pivot-host> → <subnet>
    Transparent: <yes|no>. SOCKS: <endpoint if proxychains needed>."

Do NOT wait for other decision logic items to complete before acting on pivots.
A new subnet is a high-value expansion of the assessment surface.

□ Source code found? (backup archive, .git dump, LFI source reads, share with code)
  → trigger Source Code Discovered hard stop immediately
□ New credentials? (passwords, hashes, keys, tokens)
  → trigger Usernames Found / Hashes Found hard stops
□ New hostnames? (vhosts, domains from certs/configs/DNS)
  → trigger Hosts File Update if unresolvable
□ Shell access gained? (new-access, shell-established)
  → trigger Execution Achieved hard stop
□ Versioned software identified? (specific version, not just product name)
  → spawn research for PoC lookup alongside ops

1. Unexercised vulns → assign technique skill to ops teammate
   CVE VERIFICATION GATE (mandatory):
     Step 1: version check (instant) — if patched, add_blocked, skip
     Step 2: if vulnerable/unknown → spawn research teammate for class verification
     After gate passes → route to {domain}-ops via search_skills()
   Routing: web vulns → web-ops, AD vulns → ad-ops, privesc → lin-ops/win-ops

   VERSIONED SOFTWARE PoC LOOKUP (parallel with ops spawn):
     When discovery identifies software + specific version (not just "nginx"
     but "Tomcat 9.0.31", "GitLab 16.0.1", etc.):
     a. Spawn the ops teammate for the technique immediately
     b. Spawn research teammate in parallel — instruct research to deliver
        its findings directly to the ops teammate (by name), NOT to the lead.
        The lead does not need PoC details in its context window.
     c. Research sends: payload format, encoding gotchas, working injection
        syntax, public PoC references — directly to the ops teammate
     d. Ops teammate incorporates research context alongside the loaded skill

2. Shell access without root/SYSTEM → Execution Achieved hard stop (see below)

3. Unchained access → can existing access reach new targets?

4. Untested credentials → trigger Credential Context Enumeration + Usernames Found
   **For each new credential, spawn a dedicated teammate to enumerate AS that user.**
   One teammate per user identity — named `net-enum-<username>` (or `web-enum-<username>`
   if the credential is web-only). This teammate's sole job is to discover what this
   specific identity can access:
     a. SMB shares readable/writable by this user (`nxc smb <targets> -u <user> -p <pass> --shares`)
     b. Remote access — test ALL paths: WinRM, SSH, RDP, MSSQL, web app logins
     c. Local access — if we have a shell on the same host, use RunasCs.exe to
        execute as this user and enumerate their context (files, permissions, tokens)
     d. Files and directories opened by this user's permissions
     e. Web application roles/data accessible with this user's session
     f. AD context: group memberships, ACLs, delegation rights, owned objects
   The credential unlocks something specific — the teammate finds WHAT.
   Test EVERY access path — don't stop at the first one that works.

   **In parallel**, run password reuse and standard credential tests:
     f. Password reuse spray across all known users (single spray command)
     g. Complex chains (coercion relay, delegation) — last resort

5. Unrecovered hashes → trigger Hashes Found hard stop

6. Pivot map — HIGH PRIORITY, act before items 7-9:
   for each pivot with status "identified" or "Additional NIC":
     if access exists to pivot host (check Access section in state):
       if no active tunnel covers target subnet (check get_tunnels()):
         → message shell-mgr: [setup-pivot] (see "Pivot identified + access exists")
         → after [pivot-ready]: assign recon on internal subnet
     else:
       note: need access to pivot host first — pursue via other chains

7. Blocked items:
   retry "with_context" → assign technique skill (deeper methodology)
   retry "later" → context changed, retry with new context
   retry "no" → only revisit with fundamentally new access
   retry "with_context" + custom/unknown → spawn research teammate

8. Progress toward objectives — are we closer to scope.md goals?

9. No routing match → search_skills() → validate → assign to domain teammate

Trigger: [new-access] from state-mgr, or teammate reports shell/login gained.
This is the most important state change in an engagement. Do NOT wait for
the reporting teammate's current task to complete. Do NOT wait for other
decision logic items. Act on this THE MOMENT it arrives.

1. SHELL LIFECYCLE — the teammate that found the RCE established a
   reverse shell via shell-server and handed it to shell-mgr via
   [shell-established]. shell-mgr stabilizes (or upgrades to C2 if
   configured) and sends [session-ready] with the session_id and MCP
   instructions. Wait for [session-ready] from shell-mgr before
   spawning enum teammates — include the session_id in their task.
   For credential-based access where no teammate is in the loop yet,
   message shell-mgr: [setup-process] command="evil-winrm ..." and
   wait for [process-ready].

2. SPAWN HOST ENUM (parallel with everything else):
   Windows → win-enum-<host> from teammates/win-enum.md
   Linux → lin-enum-<host> from teammates/lin-enum.md
   Each host gets its own enum teammate — don't queue behind another host.
   Include access_id and credential_id in the task assignment.

3. AD CHECK: If the user is a domain account (DOMAIN\user or user@domain),
   ALSO spawn ad-enum with authenticated enumeration task. Any domain user
   on any domain-joined host unlocks BloodHound, ADCS, ACL, delegation.
   DC access adds LDAP/replication queries but is not required.

4. Continue other in-progress tasks in parallel — enum teammates work
   independently. Do NOT serialize behind web-ops, ad-ops, or any other
   teammate that's still working.

Trigger: teammate reports git repo access, .git dump completed, LFI reads
application source files, share contains code, backup archive with source.

Source code is a force multiplier — it reveals vulns that discovery can't
find (hardcoded creds, auth bypass, hidden endpoints, injection sinks).
Act the moment it's reported, don't wait for other decision logic items.

1. CLONE/DOWNLOAD FIRST (lead or existing teammate, NOT research):
   - Git repo: assign the reporting teammate or net-enum to clone it
     to engagement/evidence/source/<repo-name>/
   - .git dump: assign web-ops or web-enum to run git-dumper, save to
     engagement/evidence/source/
   - LFI reads: files should already be in engagement/evidence/
   - Share access: assign net-enum to copy source tree locally
   Do NOT spawn research until source is on the attackbox. Opus tokens
   are expensive — don't waste them on git clone or file transfers.
2. SPAWN research teammate with `source-code-review` skill
   Pass: LOCAL source path on attackbox, framework hints, context
   Research teammate uses Explore subagents for parsing, sonnet for judgment
3. Run in PARALLEL with any technique execution already in progress
   Source review informs all other paths — don't serialize behind it
4. When findings arrive: route confirmed vulns to technique teammates,
   add hardcoded creds to state, update attack surface

1. Collect unresolvable hostnames + IPs
2. Bash: cp operator/templates/hosts-update.sh temp_hosts-update.sh && chmod +x temp_hosts-update.sh
3. Replace TARGET_IP="FILL_IN" with the actual IP
4. Replace entries array with literal strings (no variable refs):
   entries=(
       "10.10.10.5  DC01.corp.local corp.local"
       "10.10.10.5  web.corp.local"
   )
5. Present: "Run: sudo bash ./temp_hosts-update.sh"
6. Wait for confirmation. Block all tasks.
7. Verify with getent, clean up script

1. Collect usernames + auth services from state
2. Query lockout policy (ldapsearch base-scope, allowed)
3. AskUserQuestion:
   Spray tier: Light ~30 | Medium 10k | Heavy 100k | Skip
   Services: [multi-select from discovered ports]
   (pre-select config.spray.default_tier if set)
4. If spray: spawn spray teammate in background. Continue engagement loop.

1. Collect hash details: type, source, account, file path
2. AskUserQuestion:
   Method: Recover locally | Export for external rig | Skip
   (pre-select config.cracking.default_method if set)
3. Recover locally → spawn recover teammate in background
   Export → print hash file + hashcat command, wait for plaintext
   Skip → continue other paths
4. When plaintext arrives (from recover teammate OR operator):
   message state-mgr: [update-cred] id=<hash_id> cracked=true secret=<plaintext>
   Then trigger "Untested credentials" routing (item 4 in Decision Logic)

1. Bash: cp operator/templates/clock-sync.sh temp_clock-sync.sh
2. Bash: sed -i 's/DC_IP="FILL_IN"/DC_IP="<actual DC IP from state>"/' temp_clock-sync.sh
3. Bash: chmod +x temp_clock-sync.sh
4. Present: "Run: sudo bash ./temp_clock-sync.sh &"
   (Script disables VBox time sync and loops ntpdate every 5s)
5. Wait for confirmation
6. Reassign same task to AD teammate
7. Clean up: rm temp_clock-sync.sh

1. Message state-mgr: [add-blocked] retry=with_context
2. Spawn bypass teammate with detection context
3. On return with bypass artifact:
   Reassign original skill to original teammate + bypass context:
   "Use AV-safe artifact at <path>. Method: <bypass>. Prerequisites: <if any>.
    Do NOT generate a new artifact."
4. Bypass failed → message state-mgr: [add-blocked] retry=no, move on

1. Message state-mgr: [add-blocked] retry=with_context
2. Spawn research teammate with artifact path + prior analysis summary
3. Research teammate writes findings to engagement/evidence/research/<name>.md
   and messages with just the file path + one-line summary
4. Read the findings file to get full details (CVEs, technique methods, privesc angles)
5. Route based on findings:
   Technique succeeded → record findings
   Known vuln class identified → assign to technique teammate
   No vector → message state-mgr: [add-blocked] retry=no, move on

Phase 1: Recon all targets (net-enum-<target> per target for parallel recon)
Phase 2: Triage by impact (CVEs > default access > web > cred techniques)
Phase 3: Per-target teammates work in parallel (web-enum-<site>, lin-enum-<host>, etc.)
Phase 4: Cross-pollinate (new creds → test all targets, new access → check others)
Phase 5: Cycle back to blocked targets with new context

1. get_state_summary() + get_vulns()
2. Assessment narrative (chronological)
3. Findings by severity with impact, evidence, repro steps
4. Access chains diagram
5. Recommendations
6. Offer retrospective (see below)

AskUserQuestion: "Run engagement retrospective? A research teammate will
analyze the full state — what worked, what didn't, technique efficiency,
missed paths, and lessons learned."
Options: Yes (Recommended) | Skip

1. search_skills("retrospective") → find retrospective skill
2. Spawn research teammate:
   a. Read teammates/research.md via Read tool
   b. TaskCreate(subject="Retrospective — <engagement name>")
   c. Agent(prompt=<template>, description="Engagement retrospective",
            name="retro", model="sonnet", team_name=<TEAM_NAME>)
   d. TaskUpdate(taskId=<N>, owner="retro")
   e. SendMessage(to="retro", message="[TASK] #<N> — retrospective\n
      Load skill via get_skill. Engagement state is in state.db.
      Write findings to engagement/evidence/retrospective.md")
3. When retro completes, present the summary to the operator.