monomind 2.7.11 → 2.7.13

package/packages/@monomind/cli/.claude/skills/mastermind-createorg/SKILL.md

@@ -1,247 +0,0 @@
----
-name: mastermind-createorg
-description: Mastermind createorg — design and persist an autonomous agent organization (Org Runtime v2) as a `.monomind/orgs/<name>.json` config that `monomind org run/serve` loads directly. Supports optional --schedule flag for daemon-scheduled orgs.
-type: domain-skill
-default_mode: confirm
----
-
-# Mastermind Create Org
-
-This skill is invoked by `mastermind:createorg` or directly via `/mastermind:createorg`.
-
-Org Runtime v2 (`packages/@monomind/cli/src/orgrt/`) is a Node daemon, not a Task-tool-spawned boss agent. Every role in the config becomes a live SDK agent session (`@anthropic-ai/claude-agent-sdk` `query()`) the moment the org starts — there is no task board, no per-role generated `.claude/agents/*.md` file, and no communication-topology array. Roles address each other directly with the `org_send` tool using their `id` (or `<org>:<id>` cross-org). This skill's only job is to produce a config that validates against `OrgDefSchema` (`packages/@monomind/cli/src/orgrt/types.ts`).
-
----
-
-## Inputs
-
-- `brain_context`: BRAIN CONTEXT block (injected by command, or loaded below if standalone)
-- `prompt`: goal and/or role description for this org
-- `org_name`: desired name for the org (slug, e.g. `content-team`); constrained to `[a-z0-9-]`
-- `roles_desc`: optional explicit role list from user (e.g. "boss, content writer, reviewer, marketer, designer")
-- `schedule`: optional schedule string in daemon format — `"<N>s"`, `"<N>m"`, or `"<N>h"` (e.g. `"30m"`, `"2h"`). When provided, the org is picked up by `monomind org serve` on its own interval; omit for a one-shot `monomind org run`.
-- `budget_tokens`: optional total token budget for the org run (default 1,000,000 — split evenly across roles by the daemon)
-- `mode`: auto | confirm
-- `session_id`: session ID passed by command wrapper (snake_case input)
-- `caller`: command | master
-
----
-
-## Step 0 — Brain Load (standalone only)
-
-If `caller` is not "command" (i.e. invoked directly, not by the command wrapper), load brain context following mastermind-protocol/SKILL.md Brain Load Procedure with namespace: `ops`.
-
-If `caller` is "command", use the `brain_context` already provided.
-
-Run intake from `mastermind-intake/SKILL.md` if `prompt` is vague (stop at Q3, domain is `ops`). Skip intake if `prompt` is a rich prompt per mastermind-intake/SKILL.md criteria.
-
----
-
-## Step 1 — Resolve Org Name
-
-If `org_name` is not provided, extract the most prominent product/team noun from `prompt`, slugify it (lowercase, spaces → hyphens, strip non-`[a-z0-9-]` chars), and confirm with the user. Fallback: `org-<YYYYMMDD>`.
-
-Reject any `org_name` that does not match `^[a-z0-9][a-z0-9-]{0,63}$` (the CLI's own `ORG_NAME_RE` in `org.ts` is slightly looser — `^[a-z0-9][a-z0-9_-]*$/i` — but this skill's stricter slug is always a valid subset).
-
----
-
-## Step 2 — Ingest Roles
-
-Parse `roles_desc` (if provided) into a list of role titles. If not provided, derive a set of roles from `prompt` by identifying the human functions needed to achieve the goal.
-
-**Required roles to include when deriving roles from the prompt** (**skip this rule for persona-based orgs**, see below, where the characters themselves define the structure):
-- A coordinator/boss role that owns the goal — exactly one role with `reports_to: null`
-- At least one executor role that does the primary work
-- A reviewer role if quality output is implied
-
-**If the user provided an explicit `roles_desc`, their list is authoritative — never silently inject roles into it.** If a structural role above is missing (e.g. no coordinator), in confirm mode note the gap in the Step 4 plan as a one-line suggestion; in auto mode, create exactly the roles listed and let the first one default to boss (Step 2.2).
-
-**Step 2.1 — Assign `id`, `title`, `type`, `reports_to`.**
-
-- `id`: slug derived from title (`Content Writer` → `content-writer`)
-- `title`: display title, as given
-- `type`: `"boss"` for the single root role (the daemon looks for `type === 'boss' || reports_to === null`, falling back to `roles[0]` if neither matches), `"specialist"` for everyone else — or a domain-fit synonym like `"reviewer"` / `"researcher"` purely for readability; the runtime treats `type` as free text except for the `"boss"` match
-- `reports_to`: the boss's `id` for direct reports, `null` only for the boss; for larger teams a middle layer can report to another non-boss role — the runtime does not enforce a shape beyond "each role's `reports_to` must be another role's `id` or null"
-
-Exactly one role must have `reports_to: null`. If the user's role list has none, promote the first/most senior-sounding role. If it has more than one, ask which is the root (confirm mode) or promote the first one listed (auto mode).
-
-**Step 2.2 — Persona / Character Detection.**
-
-A role is **persona-based** if its title is a named real person, a well-known fictional character, or a celebrity/historical figure referred to by name. An org is persona-based if ≥50% of its roles are character names, or the goal/prompt contains `panel`, `debate`, `simulation`, `roleplay`, `celebrity`, `character`, `virtual [name]`, `impersonate`, `as [name]`.
-
-Persona roles work the same as any other role in v2 — there is no separate `agent_type`/subagent registry to resolve against. Put the character depth directly into `responsibilities` (the only field `buildRolePrompt` — `orgrt/session.ts:27-39` — actually feeds into the agent's role briefing): write 3-6 specific, voice-defining responsibilities drawn from the character's known career, positions, and communication style, not generic duties. For a living public figure, base it on documented public behavior — do not invent positions they haven't taken.
-
----
-
-## Step 2.3 — Optional Per-Role Settings
-
-For any role that needs non-default behavior, set (all optional — omit to inherit defaults):
-
-- `adapter_config.model`: a model id (e.g. `"claude-opus-4-7"`) — default is `"claude-sonnet-4-5"` (`orgrt/types.ts:33`)
-- `provider`: `{ kind: "subscription" | "api-key" | "base-url" | "bedrock" | "vertex", apiKeyEnv?, baseUrl?, authTokenEnv? }` — default `subscription` (local Claude Code login); only set this if the role needs a different provider/credential
-- `policy`: `{ allowTools?, denyTools?, fileWrite?, fileRead?, webAllow?, maxTokens? }` — glob-based tool/file/web restrictions for that role; leave unset unless the user asked for sandboxing
-
-Do not invent values for these — only populate a field the user actually specified or clearly implied (e.g. "the researcher should use Opus" → that role's `adapter_config.model`).
-
----
-
-## Step 3 — Build Org Config
-
-Produce an org config object matching `OrgDefSchema` exactly:
-
-```json
-{
-  "name": "<org_name>",
-  "goal": "<the goal the org exists to achieve>",
-  "status": "stopped",
-  "schedule": "<'<N>m' | '<N>h' | '<N>s' from Step 0 input, or null for a one-shot org>",
-  "run_config": {
-    "max_concurrent_agents": 4,
-    "budget_tokens": "<budget_tokens input, or 1000000 default>",
-    "memory_namespace": "org:<org_name>",
-    "max_turns_per_message": 30
-  },
-  "roles": [
-    {
-      "id": "<slug>",
-      "title": "<display title>",
-      "type": "boss | specialist | <domain synonym>",
-      "reports_to": "<role id, or null for the single boss>",
-      "responsibilities": ["<3-6 specific duties — this text becomes part of the agent's role briefing>"]
-    }
-  ]
-}
-```
-
-`status` starts `"stopped"` regardless of whether `schedule` is set — the org does not run until `monomind org run <name>` (one-shot) or `monomind org serve` (picks up any org whose `schedule` is set) is invoked.
-
-Only include `adapter_config`, `provider`, or `policy` on a role when Step 2.3 populated them for it — leave them out entirely rather than writing empty objects.
-
----
-
-## Step 4 — Show Plan and Confirm (confirm mode)
-
-Render the org plan in a clear human-readable format:
-
-```
-╔══════════════════════════════════════════════════╗
-║  ORG: <org_name>                                 ║
-║  GOAL: <goal>                                    ║
-╚══════════════════════════════════════════════════╝
-
-ROLES  (N roles — exactly one boss, every reports_to resolves to a real role id)
-─────
-• [boss] CEO / Boss  (type: boss, reports_to: none)
-    Responsibilities: Strategic oversight, final decisions, coordinates the team via org_send
-
-• [content_writer] Content Writer  (type: specialist, reports_to: boss)
-    Responsibilities: Draft posts per the content calendar, hand off to content_reviewer
-
-  ... (all roles)
-
-SETTINGS
-────────
-Budget: <run_config.budget_tokens> tokens (split evenly across N roles)
-Memory namespace: org:<org_name>
-Schedule: <"every <N> <unit>" if schedule set; otherwise "manual — run with `monomind org run <org_name>`">
-
-Type "go" to save this org, or describe changes.
-```
-
-In **auto** mode, skip the confirmation prompt.
-
-If the user requests changes, apply them and re-render. Repeat until confirmed.
-
----
-
-## Step 5 — Save Org Config
-
-```bash
-org_name="<resolved org name from Step 1>"
-orgJson=".monomind/orgs/${org_name}.json"
-mkdir -p .monomind/orgs
-```
-
-Write the confirmed org config as JSON using `jq` to guarantee valid encoding:
-
-```bash
-# Set shell variables from the confirmed plan before running this block:
-#   goal, schedule_val ("" if none), budget_tokens_val, roles_json (JSON array matching the role shape above)
-jq -n \
-  --arg name "$org_name" \
-  --arg goal "$goal" \
-  --arg schedule "${schedule_val:-}" \
-  --argjson budget_tokens "${budget_tokens_val:-1000000}" \
-  --argjson roles "$roles_json" \
-  '{name:$name,goal:$goal,status:"stopped",
-    schedule:(if $schedule=="" then null else $schedule end),
-    run_config:{max_concurrent_agents:4,budget_tokens:$budget_tokens,
-                memory_namespace:("org:"+$name),max_turns_per_message:30},
-    roles:$roles}' \
-  > "${orgJson}.tmp" && mv "${orgJson}.tmp" "$orgJson"
-```
-
-**POST-SAVE VALIDATION (run immediately after saving — abort if it fails):**
-
-```bash
-# Parses with OrgDefSchema (the exact code path org run/serve use) and checks the
-# structural invariants: exactly one root role, every reports_to resolves, unique
-# role ids, parseable schedule, name/filename agreement.
-if npx -y monomind@latest org validate "$org_name"; then
-  echo "✓ Org config validated — ready for: monomind org run ${org_name}"
-else
-  # CLI < 2.1.8 has no `org validate` — fall back to the two structural checks:
-  root_count=$(jq '[.roles[] | select(.reports_to == null)] | length' "$orgJson")
-  bad_reports=$(jq -r '([.roles[].id]) as $ids |
-    [.roles[] | select(.reports_to != null and (.reports_to as $r | $ids | index($r) | not)) | .id] | join(", ")' "$orgJson")
-  if [ "$root_count" -ne 1 ] || [ -n "$bad_reports" ]; then
-    echo "ERROR: org config invalid (roots: $root_count, unresolved reports_to: ${bad_reports:-none}) — fix the roles array and re-save."
-    exit 1
-  fi
-  echo "✓ Structural checks passed (upgrade monomind for full schema validation)"
-fi
-```
-
----
-
-## Step 6 — Return Output
-
-```yaml
-domain: ops
-status: complete
-artifacts:
-  - path: .monomind/orgs/<org_name>.json
-    type: config
-decisions:
-  - what: "Org <org_name> created with N roles"
-    why: "Role mapping derived from goal and user description"
-    confidence: 0.85
-    outcome: shipped
-lessons:
-  - what_worked: "Auto-suggested roles matched user intent"
-  - what_didnt: ""
-next_actions:
-  - "Run `monomind org run <org_name>` to start the organization in the foreground (add --dry-run to preview each role's briefing first)"
-  - "After hand-editing the config, re-check it with `monomind org validate <org_name>`"
-  - "While running: `monomind org logs <org_name> --follow`; afterwards: `monomind org report <org_name>` for outcome, per-role activity, and token usage"
-  - "Or `monomind org serve` to host it (and any other scheduled orgs) as a background daemon"
-  - "Edit .monomind/orgs/<org_name>.json directly, or use /mastermind:org-settings, to change goal/budget/roles"
-  - "`monomind org status <org_name>` to check runtime state; `monomind org stop <org_name>` to stop a running org"
-```
-
-Print confirmation:
-```
-✓ Org "<org_name>" saved to .monomind/orgs/<org_name>.json
-  → Run: monomind org run <org_name>
-```
-
-If `schedule` was set, also print:
-```
-  Schedule: every <N> <unit> — pick it up with: monomind org serve
-```
-
----
-
-## Step 7 — Brain Write (standalone only)
-
-If `caller` is not "command", follow mastermind-protocol/SKILL.md Brain Write Procedure for domain `ops`.

package/packages/@monomind/cli/.claude/skills/mastermind-debug/SKILL.md

@@ -1,277 +0,0 @@
----
-name: mastermind-debug
-description: Systematic root-cause debugging protocol. Use before ANY fix attempt — for test failures, bugs, unexpected behavior, build failures, performance regressions.
----
-
-# mastermind:debug — Systematic Debugging
-
-## Overview
-
-Random fixes waste time and create new bugs. Quick patches mask underlying issues.
-
-**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
-
-**Violating the letter of this process is violating the spirit of debugging.**
-
-## The Iron Law
-
-```
-NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
-```
-
-If you haven't completed Phase 1, you cannot propose fixes.
-
-## When to Use
-
-Use for ANY technical issue:
-- Test failures
-- Bugs in production or staging
-- Unexpected behavior
-- Performance regressions
-- Build failures
-- Integration issues
-
-**Use this ESPECIALLY when:**
-- Under time pressure (emergencies make guessing tempting)
-- "Just one quick fix" seems obvious
-- You've already tried multiple fixes that didn't work
-- Previous fix didn't resolve the issue
-- You don't fully understand what's happening
-
-**Don't skip when:**
-- Issue seems simple (simple bugs have root causes too)
-- You're in a hurry (systematic is faster than thrashing)
-- The user wants it fixed immediately (systematic approach finds the real fix faster)
-
-## The Four Phases
-
-You MUST complete each phase before proceeding to the next.
-
----
-
-### Phase 1: Root Cause Investigation
-
-**BEFORE attempting ANY fix:**
-
-1. **Read Error Messages Carefully**
-   - Don't skim errors or warnings
-   - They often contain the exact solution
-   - Read stack traces completely
-   - Note line numbers, file paths, error codes
-
-2. **Reproduce Consistently**
-   - Can you trigger the issue reliably?
-   - What are the exact steps?
-   - Does it happen every time?
-   - If not reproducible → gather more data, don't guess
-
-3. **Check Recent Changes**
-   - What changed that could cause this?
-   - `git diff`, recent commits, new dependencies, config changes
-   - Environmental differences between working and broken states
-
-4. **Gather Evidence in Multi-Component Systems**
-
-   **WHEN the system has multiple components (CI → build → deploy, API → service → database):**
-
-   **BEFORE proposing fixes, add diagnostic instrumentation:**
-   ```
-   For EACH component boundary:
-     - Log what data enters the component
-     - Log what data exits the component
-     - Verify config/env propagation at each layer
-     - Check state at each boundary
-
-   Run once to gather evidence showing WHERE it breaks
-   THEN analyze evidence to identify the failing component
-   THEN investigate that specific component
-   ```
-
-   **Example:**
-   ```bash
-   # Layer 1: entry point
-   echo "=== Input received: ==="
-   echo "VAR: ${VAR:+SET}${VAR:-UNSET}"
-
-   # Layer 2: processing
-   echo "=== State after processing: ==="
-   env | grep VAR || echo "VAR not in environment"
-
-   # Layer 3: output/result
-   echo "=== Final state: ==="
-   ```
-
-5. **Trace Data Flow**
-
-   **WHEN the error is deep in a call stack:**
-   - Where does the bad value originate?
-   - What called this with the bad value?
-   - Keep tracing up until you find the source
-   - Fix at the source, not at the symptom — a `null` crashing in layer 4 usually entered in layer 1
-
----
-
-### Phase 2: Pattern Analysis
-
-Once you understand WHERE the break is, find existing working examples:
-
-1. **Find working code that solves the same problem**
-   - Search the codebase for similar patterns
-   - Check git history for when this worked
-   - Find the canonical implementation to compare against
-
-2. **Compare against references**
-   - If implementing a pattern, read the reference implementation COMPLETELY
-   - Don't skim — read every line
-   - Understand the pattern fully before applying it
-
-3. **Compare broken vs. working**
-   - What's different?
-   - List every difference, not just the obvious one — don't assume "that can't matter"
-   - Environment, config, data, timing
-
-4. **Understand dependencies**
-   - What other components does this need?
-   - What settings, config, environment?
-   - What assumptions does it make?
-
----
-
-### Phase 3: Form and Test a Hypothesis
-
-1. **State your hypothesis explicitly:**
-   > "I believe the root cause is [X] because [evidence Y] and [evidence Z]."
-
-2. **Test the hypothesis minimally**
-   - Change one thing and observe the result
-   - If it doesn't confirm or deny, gather more evidence
-   - A confirmed hypothesis means you understand the root cause
-
-3. **If hypothesis is wrong:** Do NOT add more fixes. Return to Phase 1 with the new information.
-
-4. **When you don't know:** Say "I don't understand X". Don't pretend to know. Research more or ask the user — a stated unknown beats a confident guess.
-
----
-
-### Phase 4: Implementation
-
-1. **Write a failing test first** (before touching production code)
-   - Automated test where possible; a one-off test script if no framework
-   - Use `Skill("mastermind-tdd")` for writing proper failing tests
-   - The test MUST fail before the fix proves it
-
-2. **Implement a single fix**
-   - Address the root cause identified in Phase 3
-   - ONE change at a time
-   - No "while I'm here" improvements
-   - No bundled refactoring
-
-3. **Verify the fix**
-   - Test passes now?
-   - No other tests broken?
-   - Issue actually resolved?
-   - Use `Skill("mastermind-review")` to verify before declaring done
-
-4. **If the fix doesn't work:**
-   - STOP
-   - Count: How many fixes have you tried?
-   - If < 3: Return to Phase 1, re-analyze with the new information
-   - **If ≥ 3: STOP — this is likely an architectural problem (see Phase 4.5 below)**
-   - Do NOT attempt a 4th fix without architectural discussion
-
----
-
-### Phase 4.5 — If 3+ Fixes Have Failed: Question the Architecture
-
-**Pattern indicating an architectural problem:**
-- Each fix reveals new coupling or shared state issues in a different place
-- Each fix creates new symptoms elsewhere
-- Fixes require "massive refactoring" to implement cleanly
-
-**STOP and question fundamentals:**
-- Is this design pattern fundamentally sound?
-- Are we continuing out of inertia?
-- Should we refactor the architecture rather than continue patching?
-
-**Discuss with the user before attempting more fixes.** This is not a failed hypothesis — this is the wrong architecture.
-
----
-
-## Red Flags — STOP and Return to Phase 1
-
-If you catch yourself thinking or doing any of these:
-
-| Thought / Action | What it means |
-|---|---|
-| "Quick fix for now, investigate later" | You're skipping root cause. Return to Phase 1. |
-| "Just try changing X and see if it works" | Guessing. Return to Phase 1. |
-| "Add multiple changes, run tests" | Can't isolate what worked. Return to Phase 1. |
-| "Skip the test, I'll manually verify" | Untested fixes don't stick. Write the failing test. |
-| "Pattern says X but I'll adapt it differently" | Partial understanding guarantees bugs. Read the reference completely. |
-| "Here are the main problems: …" (listing fixes without investigation) | Solutions before evidence. Return to Phase 1. |
-| "It's probably X, let me fix that" | Assumed root cause. Verify it first. Return to Phase 1. |
-| "I don't fully understand but this might work" | You don't have a hypothesis. Return to Phase 1. |
-| Proposing solutions before tracing data flow | No root cause. Return to Phase 1. |
-| "One more fix attempt" (already tried 2+) | 3+ failures = architectural problem. Phase 4.5. |
-| Each fix reveals a new problem in a different place | Architectural problem. Phase 4.5. |
-
-## User Signals You're Doing It Wrong
-
-Watch for these redirections from the user:
-
-| Signal | What it means |
-|---|---|
-| "Is that actually happening?" | You assumed without verifying. Add evidence gathering. |
-| "What does the output show?" | You should have checked before proposing a fix. |
-| "Stop guessing" | You're proposing fixes without root cause. Phase 1. |
-| "We keep going in circles" | 3+ fix attempts = architectural problem. Phase 4.5. |
-
-## Common Rationalizations
-
-| Excuse | Reality |
-|---|---|
-| "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs. |
-| "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check thrashing. |
-| "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start. |
-| "I'll write the test after confirming the fix works" | Untested fixes don't stick. Test first proves it. |
-| "Multiple fixes at once saves time" | Can't isolate what worked. Creates new bugs. |
-| "Reference too long, I'll adapt the pattern" | Partial understanding guarantees bugs. Read it completely. |
-| "I can see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. |
-| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. Question the pattern. |
-
-## Quick Reference
-
-| Phase | Key Activities | Success Criteria |
-|---|---|---|
-| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |
-| **2. Pattern** | Find working examples, compare | Identified differences |
-| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |
-| **4. Implementation** | Write failing test, fix, verify | Bug resolved, tests pass |
-
-## When the Process Reveals "No Root Cause"
-
-If systematic investigation reveals the issue is truly environmental, timing-dependent, or external:
-
-1. You've completed the process
-2. Document what you investigated
-3. Implement appropriate handling (retry, timeout, clear error message)
-4. Add monitoring/logging for future investigation
-
-**But:** 95% of "no root cause" cases are incomplete investigation.
-
-## Supporting Techniques
-
-- **Root-cause tracing:** when a bad value crashes deep in the stack, trace it backward caller by caller until you find where it was created; fix there. Adding a guard at the crash site only hides the origin.
-- **Defense in depth:** AFTER fixing the root cause, add validation at the layers the bad value passed through unchecked — so the next bad value fails loudly at its first boundary, not silently at its fourth.
-- **Condition-based waiting:** replace arbitrary sleeps/timeouts in flaky tests and scripts with polling for the actual condition ("wait until the file exists / the port answers"), with a hard cap. Timing guesses are bugs waiting for a slower machine.
-
-**Related skills:**
-- `Skill("mastermind-tdd")` — for creating the failing test case (Phase 4, Step 1)
-- `Skill("mastermind-verify")` — verify the fix worked before claiming success
-
-## Impact
-
-Systematic approach vs random fixing:
-- Time to fix: 15-30 min vs 2-3 hours of thrashing
-- First-time fix rate: ~95% vs ~40%
-- New bugs introduced by the fix: near zero vs common

package/packages/@monomind/cli/.claude/skills/mastermind-delegation/SKILL.md

@@ -1,83 +0,0 @@
----
-name: mastermind-delegation
-description: Agent Delegation Capability — injected into every spawned agent prompt so subagents can further delegate specialized work. Never invoked directly; referenced by mastermind-protocol/SKILL.md and domain skills.
-type: shared
----
-
-# Agent Delegation Capability
-
-This file defines the **AGENT DELEGATION CAPABILITY** block that MUST be included verbatim in every `Task` / `Agent` spawn within mastermind and monomind commands.
-
-Including it in every agent prompt makes delegation **recursive**: an agent can spawn sub-agents, which can spawn their own sub-agents, each with full access to the same capability.
-
----
-
-## How to use this file
-
-When writing a Task/Agent `description` or `prompt`, paste the section below verbatim after `BRAIN CONTEXT:`. Do not paraphrase — paste it as-is so sub-agents receive the full capability statement.
-
----
-
-## AGENT DELEGATION CAPABILITY [paste this block into every agent prompt]
-
-```
-== AGENT DELEGATION CAPABILITY ==
-You have full access to the Agent tool (Claude Code: Task tool) to spawn
-sub-agents for any specialized subtask. This capability is recursive —
-sub-agents you spawn also receive it.
-
-Available agent categories (use the exact slug or name):
-
-  CORE      coder · reviewer · tester · planner · researcher
-  BACKEND   backend-dev · Backend Architect · DB Optimizer · API Tester
-  FRONTEND  Frontend Developer · mobile-dev · Mobile App Builder
-  ARCH      Software Architect · system-architect
-  SECURITY  Security Engineer · security-architect
-  AI/ML     AI Engineer · ml-developer · Data Engineer
-  DEVOPS    DevOps Automator · SRE · cicd-engineer
-  DOCS      Technical Writer · api-docs
-  PRODUCT   Product Manager · Launch Strategist · CRO Specialist
-  MARKETING Content Creator · SEO Specialist · Growth Hacker · Email Marketing
-  SOCIAL    TikTok · LinkedIn · Twitter · Instagram Strategist
-  SALES     Deal Strategist · Sales Coach · Outbound Strategist
-  BUSINESS  Finance Tracker · Legal Compliance Checker · Analytics Reporter
-  DESIGN    Monodesign (UI/UX · brand · CSS · animation · design systems)
-
-WHEN to delegate:
-- A subtask needs deeper expertise than your primary role
-- Work can be done faster in parallel by concurrent specialists
-- A subtask is outside your domain but blocks your progress
-
-HOW to delegate:
-  Agent({
-    subagent_type: "agent-slug",
-    description: "Short task label",
-    prompt: `Full self-contained briefing — treat every sub-agent as cold-start.
-             Include: context, scope, success criteria, and this AGENT DELEGATION
-             CAPABILITY block so they can further delegate if needed.`,
-    run_in_background: true   // use for parallel work
-  })
-
-RULES:
-- Always pass enough context for the sub-agent to work independently
-- Collect and synthesize sub-agent results before writing your final output
-- Report what you delegated and what each sub-agent returned
-- If a sub-agent is blocked, handle it rather than silently failing
-=================================
-```
-
----
-
-## Placement in agent prompts
-
-```
-BRAIN CONTEXT:
-[...]
-=====================
-
-== AGENT DELEGATION CAPABILITY ==
-[full block above]
-=================================
-
-YOUR GOAL: [task description]
-```