@monoes/monomindcli 1.18.1 → 1.18.2

package/.claude/skills/{mastermind → mastermind-skills}/createorg.md

@@ -67,47 +67,54 @@ Reject any `org_name` that does not match `^[a-z0-9][a-z0-9-]{0,63}$`.
 
 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 always include** (if the prompt implies a team — **skip this rule for persona-based orgs** where the characters themselves define the structure; do not inject a generic coordinator into a celebrity panel):
+**Required roles to include when deriving roles from the prompt** (**skip this rule for persona-based orgs** where the characters themselves define the structure; do not inject a generic coordinator into a celebrity panel):
 - A coordinator/boss role that owns the goal and makes final decisions
 - At least one executor role that does the primary work
 - A reviewer or QA role if quality output is implied
 - A communication layer (middle manager) if team size ≥ 4
 
-> ⚠ **Check Step 2.3 (Persona / Character Detection) BEFORE applying this table.** If the org is persona-based (roles are named real people, celebrities, or fictional characters), skip this table for those roles and follow Step 2.3 instead.
+**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, or ≥4 roles with no middle manager), in confirm mode note the gap in the Step 5 plan as a one-line suggestion ("Suggestion: add a coordinator — none in your list; reply 'add it' or 'go' to keep as-is"); in auto mode, create exactly the roles listed.
 
-**Role → Agent Type mapping table** (use exact `subagent_type` slug for Task tool):
+**Step 2.2 — Detect the org's domain.** From the goal/prompt, classify the org's domain in one or two words (e.g. `software-engineering`, `content-marketing`, `sports-analytics`, `legal`, `medical`, `finance`). This drives agent-type resolution below.
 
-| User role keyword | Agent type slug | Specialty |
+> ⚠ **Check Step 2.3 (Persona / Character Detection) BEFORE resolving agent types.** If the org is persona-based (roles are named real people, celebrities, or fictional characters), skip the roster below for those roles and follow Step 2.3 instead.
+
+**Step 2.4 — Resolve each role's `agent_type` (domain-fit first).**
+
+The premade roster below is a set of **candidates, not defaults**. Every premade agent is domain-scoped — `reviewer` reviews *code*, `tester` tests *software*, `Content Creator` writes *marketing content*. A keyword match alone is never enough to use one; the agent's domain must also match the role's actual job in this org.
+
+| Premade agent slug | Its domain | Candidate for role keywords |
 |---|---|---|
-| boss / ceo / director / lead / chief | `coordinator` | Strategic oversight, final decisions |
-| content writer / writer / copywriter | `Content Creator` | Blog posts, copy, articles |
-| content reviewer / editor | `reviewer` | Review quality, accuracy, tone (use `reviewer`, not `Code Reviewer`) |
-| marketer / marketing / growth | `Growth Hacker` | Campaigns, acquisition, channels |
-| designer / ui / ux / visual | `Monodesign` | Visuals, UI, brand |
-| middle manager / manager | `Project Shepherd` | Sprint planning, cross-team coordination |
-| engineer / developer / coder / dev | `coder` | Code implementation |
-| researcher / analyst | `researcher` | Research, data, insights |
-| seo / search | `SEO Specialist` | SEO, search strategy |
-| social media / social | `Social Media Strategist` | Social content and engagement |
-| product / product manager | `Product Manager` | Roadmap, prioritization |
-| qa / tester | `tester` | Quality assurance, testing |
-
-If a role doesn't match any keyword **and the org's domain is far from software** (legal, medical, finance, creative, etc.), do NOT force a mismatched generic type whose instructions are about the wrong domain (e.g. a court reporter mapped to the code `reviewer`). Instead coin a role-specific `agent_type` slug from the role title (slugify: `Court Reporter` → `court-reporter`, `Prosecutor` → `prosecutor`) and generate a fitting definition for it in Step 2.5. Only fall back to `general-purpose` when no sensible slug applies.
-
-**For technical/engineering orgs** (DevBot, code quality, CI/CD, data pipelines, etc.), coin a precise domain slug for every specialized role rather than forcing it into a generic category:
-- `Churn Analyst` → `churn-analyst` (git churn analysis, not a financial analyst)
-- `Complexity Scanner` → `complexity-scanner` (static analysis, cyclomatic complexity)
-- `Impact Assessor` → `impact-assessor` (code change blast-radius scoring)
-- `Validator` → `code-validator` (applies patches, runs tests, enforces kill switch)
-- `Orchestrator` (in a devbot) → `devbot-orchestrator` (4-phase pipeline boss, not generic coordinator)
-
-The coined slug + a generated definition at `.claude/agents/generated/<slug>.md` is always better than a generic type whose system prompt talks about a completely different job.
+| `coordinator` | any (domain-neutral orchestration) | boss / ceo / director / lead / chief |
+| `Project Shepherd` | any (domain-neutral coordination) | middle manager / manager |
+| `researcher` | general research | researcher (broad research roles only) |
+| `coder` | software | engineer / developer / coder / dev |
+| `reviewer` | software — code review | code reviewer |
+| `tester` | software — QA/testing | qa / tester (of software) |
+| `Content Creator` | content/marketing | content writer / copywriter |
+| `Growth Hacker` | marketing | marketer / growth |
+| `SEO Specialist` | search marketing | seo / search |
+| `Social Media Strategist` | social marketing | social media / social |
+| `Product Manager` | product/software | product / product manager |
+| `Monodesign` | design/UI/brand | designer / ui / ux / visual |
+
+**Resolution procedure — apply to each role in order:**
+
+1. **Persona role** (Step 2.3) → coin the character slug; skip the roster.
+2. Find a roster candidate by role keyword.
+3. **Domain-fit gate:** accept the candidate ONLY if its domain column matches what this role actually does in *this org's* domain (Step 2.2). A "reviewer" in a football-analysis org reviews match analyses, not code — `reviewer` fails the gate. An "analyst" there analyzes matches, not general research — `researcher` fails too. When in doubt, the gate fails.
+4. **Gate passed, generic role** → reuse the premade slug as-is.
+5. **Gate passed, use-case-specific role** (e.g. a content writer for a niche audience) → still reuse the premade slug; put the specialization into the role's `responsibilities` and the org goal (runorg passes both to the agent). Do not fork the definition for mere topical focus.
+6. **No candidate, or gate failed** → coin a role-specific slug from the role title (`Football Analyst` → `football-analyst`, `Court Reporter` → `court-reporter`, `Churn Analyst` → `churn-analyst`, devbot `Orchestrator` → `devbot-orchestrator`) and fully generate its definition in Step 2.5 — skills, instructions, and I/O contracts all authored for this role in this org's domain. If a rejected candidate was structurally close, its definition may seed the *shape* of the generated one, but every line must be rewritten for the actual domain.
+7. `general-purpose` is a last resort, only when no sensible slug applies. Never map an editor/content-reviewer role to `reviewer` — that agent is code review; coin `content-editor` (or similar) and generate.
+
+**A coined slug + generated definition always beats a premade agent whose system prompt describes a different job.** runorg and the dashboard load whatever definition matches `agent_type` — a football org whose analyst is `researcher` or whose reviewer is `reviewer` gets the wrong instructions at run time. That is a bug, not a fallback.
 
 ---
 
-## Step 2.3 — Persona / Character Detection (run BEFORE the mapping table above)
+## Step 2.3 — Persona / Character Detection (run BEFORE the Step 2.4 resolution above)
 
-**Before applying the mapping table above, detect whether this org is persona-based:**
+**Before resolving agent types via Step 2.4, detect whether this org is persona-based:**
 
 A role is **persona-based** if its title is:
 - A named real person (e.g. "Donald Trump", "Elon Musk", "Steve Jobs")
@@ -118,7 +125,7 @@ An org is **persona-based** if ≥ 50% of its roles are character names, OR the
 
 **If persona-based:**
 
-1. **Ignore the mapping table entirely for these roles.** Do NOT map "Donald Trump" → `coder`, "Elon Musk" → `researcher`, etc.
+1. **Ignore the premade roster entirely for these roles.** Do NOT map "Donald Trump" → `coder`, "Elon Musk" → `researcher`, etc.
 
 2. **Coin a character-specific `agent_type` slug** from the character's name:
    - `Donald Trump` → `donald-trump`
@@ -132,9 +139,9 @@ An org is **persona-based** if ≥ 50% of its roles are character names, OR the
 
 4. **The generated agent definition** (written in Step 2.5) must read as that character — their voice, stance, known views, communication style. It is a character simulation, not a generic role.
 
-5. **Non-character roles in the same org** (e.g. "Moderator", "Audience") should use the standard mapping table or a role-coined slug as appropriate.
+5. **Non-character roles in the same org** (e.g. "Moderator", "Audience") go through the normal Step 2.4 resolution (roster + domain-fit gate, or a role-coined slug).
 
-**If NOT persona-based:** proceed normally with the mapping table.
+**If NOT persona-based:** proceed normally with Step 2.4.
 
 ---
 
@@ -153,7 +160,7 @@ at="<agent_type>"
 existing=$(grep -rils "^name:[[:space:]]*${at}\$" .claude/agents 2>/dev/null | head -1)
 [ -z "$existing" ] && existing=$(find .claude/agents -iname "${at}.md" 2>/dev/null | head -1)
 ```
-A definition is **usable** only if it exists AND its domain fits this role. A curated def whose instructions are about a different domain (e.g. `reviewer.md` = code review, applied to a "Court Reporter") does **not** count as usable — treat it as missing and coin a role-specific `agent_type` (see Step 2 note).
+A definition is **usable** only if it exists AND it passed the Step 2.4 domain-fit gate (its instructions describe this role's actual job in this org's domain). A curated def about a different domain (e.g. `reviewer.md` = code review, applied to a "Court Reporter" or "Match Reviewer") does **not** count as usable — treat it as missing, coin a role-specific `agent_type` per Step 2.4 rule 6, and generate.
 
 **2. If no usable definition exists, generate one** at `.claude/agents/generated/<agent_type>.md`. Author it specifically for this role and this org's goal — never a generic stub. Use this shape:
 
@@ -209,6 +216,8 @@ The dashboard agent drawer and `runorg` both read these definitions (matched by
 
 This gate prevents saving an org where the dashboard will show "No instruction document" or blank skills. **Run these checks now — one Bash call per role:**
 
+**Check 0 — domain fit (judgment, per role using a premade slug):** for every role whose `agent_type` comes from the Step 2.4 roster, re-confirm the gate: the premade agent's definition describes this role's actual job in *this org's* domain. If not, go back to Step 2.4 rule 6 — coin a slug and generate. An org outside the roster's domains (sports, legal, medical, etc.) should have **zero domain-scoped** roster slugs (`coder`, `reviewer`, `tester`, `researcher`, etc.); domain-neutral slugs (`coordinator`, `Project Shepherd`) and roles whose *function itself* matches a premade (e.g. a content writer publishing that org's output → `Content Creator`, per rule 5) remain valid reuses.
+
 For each role in the org:
 
 ```bash
@@ -323,7 +332,7 @@ Ask the user (or infer from prompt) for the optional Paperclip-style fields:
     {
       "id": "<slug>",
       "title": "<display title>",
-      "agent_type": "<subagent_type slug — from Step 2.3 character slug for persona roles, or from mapping table for functional roles>",
+      "agent_type": "<subagent_type slug — from Step 2.3 character slug for persona roles, or from the Step 2.4 resolution (reused premade or coined+generated) for functional roles>",
       "responsibilities": ["<1-3 bullet responsibilities>"],
       "reports_to": "<role id or null>",
       "skills": ["<populated from the generated def's expertise in Step 2.5 — never left empty>"],

package/.claude/skills/{mastermind → mastermind-skills}/debug.md

@@ -137,7 +137,7 @@ Once you understand WHERE the break is, find existing working examples:
 
 1. **Write a failing test first** (before touching production code)
    - Automated test where possible
-   - Use `Skill("mastermind:build")` with a test-only prompt if needed
+   - Use `Skill("mastermind-skills:build")` with a test-only prompt if needed
    - The test MUST fail before the fix proves it
 
 2. **Implement a single fix**
@@ -150,7 +150,7 @@ Once you understand WHERE the break is, find existing working examples:
    - Test passes now?
    - No other tests broken?
    - Issue actually resolved?
-   - Use `Skill("mastermind:review")` to verify before declaring done
+   - Use `Skill("mastermind-skills:review")` to verify before declaring done
 
 4. **If the fix doesn't work:**
    - STOP

package/.claude/skills/{mastermind → mastermind-skills}/design.md

@@ -44,7 +44,7 @@ Complete these items in order:
 6. **Write design doc** — save to `docs/mastermind/specs/YYYY-MM-DD-<topic>-design.md`
 7. **Spec self-review** — inline check for placeholders, contradictions, ambiguity, scope (see below)
 8. **User reviews written spec** — ask user to review before proceeding
-9. **Transition to planning** — invoke `Skill("mastermind:plan")` to create the implementation plan
+9. **Transition to planning** — invoke `Skill("mastermind-skills:plan")` to create the implementation plan
 
 ---
 
@@ -68,10 +68,10 @@ Spec self-review (fix inline)
         ↓
 User reviews spec? → changes requested → Write design doc
         ↓ approved
-Invoke Skill("mastermind:plan")  ← TERMINAL STATE
+Invoke Skill("mastermind-skills:plan")  ← TERMINAL STATE
 ```
 
-**The terminal state is invoking `Skill("mastermind:plan")`.** Do NOT invoke mastermind:build or any other implementation skill directly. The ONLY next step after design is plan.
+**The terminal state is invoking `Skill("mastermind-skills:plan")`.** Do NOT invoke mastermind:build or any other implementation skill directly. The ONLY next step after design is plan.
 
 ---
 
@@ -143,11 +143,11 @@ Fix any issues inline. No need to re-review — just fix and move on.
 
 Wait for the user's response. If they request changes, make them and re-run the spec self-review. Only proceed once the user approves.
 
-**In auto mode:** Skip the wait. Proceed directly to `Skill("mastermind:plan")`.
+**In auto mode:** Skip the wait. Proceed directly to `Skill("mastermind-skills:plan")`.
 
 ### Transition to Planning
 
-- Invoke `Skill("mastermind:plan")` to create a detailed implementation plan
+- Invoke `Skill("mastermind-skills:plan")` to create a detailed implementation plan
 - Do NOT invoke any other skill. `mastermind:plan` is the only next step.
 
 ---
@@ -178,12 +178,12 @@ A browser-based companion for showing mockups, diagrams, and visual options duri
 - **Use the browser** for content that IS visual — mockups, wireframes, layout comparisons, architecture diagrams
 - **Use the terminal** for content that is text — requirements questions, conceptual choices, tradeoff lists, scope decisions
 
-If they agree to the companion, use `Skill("mastermind:worktree")` to set up an isolated workspace, then invoke `Skill("agent-browser-testing")` to open the browser.
+If they agree to the companion, use `Skill("mastermind-skills:worktree")` to set up an isolated workspace, then invoke `Skill("agent-browser-testing")` to open the browser.
 
 ---
 
 ## Integration
 
 **Skills used by this skill:**
-- `Skill("mastermind:plan")` — creates the implementation plan after design is approved (terminal state)
-- `Skill("mastermind:worktree")` — isolated workspace for visual companion work
+- `Skill("mastermind-skills:plan")` — creates the implementation plan after design is approved (terminal state)
+- `Skill("mastermind-skills:worktree")` — isolated workspace for visual companion work

package/.claude/skills/{mastermind → mastermind-skills}/execute.md

@@ -11,7 +11,7 @@ Load plan, review critically, execute all tasks, report when complete.
 
 **Announce at start:** "I'm using the mastermind:execute skill to implement this plan."
 
-**Note:** This skill works best with subagent support (Claude Code). When subagents are available, prefer `Skill("mastermind:taskdev")` for parallel task execution.
+**Note:** This skill works best with subagent support (Claude Code). When subagents are available, prefer `Skill("mastermind-skills:taskdev")` for parallel task execution.
 
 ---
 
@@ -48,16 +48,16 @@ For each task in the plan:
 4. Mark as `completed`
 
 When the plan references skills:
-- `mastermind:taskdev` → invoke `Skill("mastermind:taskdev")`
-- `mastermind:verify` → invoke `Skill("mastermind:verify")`
-- Any other `mastermind:*` skill → invoke `Skill("mastermind:<name>")`
+- `mastermind:taskdev` → invoke `Skill("mastermind-skills:taskdev")`
+- `mastermind:verify` → invoke `Skill("mastermind-skills:verify")`
+- Any other `mastermind:*` skill → invoke `Skill("mastermind-skills:<name>")`
 
 ### Step 3: Complete Development
 
 After all tasks complete and are verified:
 
 - Announce: "All tasks complete. Handing off to mastermind:finish."
-- **REQUIRED SUB-SKILL:** invoke `Skill("mastermind:finish")`
+- **REQUIRED SUB-SKILL:** invoke `Skill("mastermind-skills:finish")`
 - Follow that skill to verify tests, present options, and execute the chosen finish action
 
 ---
@@ -98,7 +98,7 @@ After all tasks complete and are verified:
 ## Integration
 
 **Skills used by this skill:**
-- `Skill("mastermind:plan")` — creates the plan this skill executes
-- `Skill("mastermind:taskdev")` — subagent-driven parallel task execution (preferred for complex plans)
-- `Skill("mastermind:finish")` — complete the development branch after all tasks
-- `Skill("mastermind:verify")` — verification gate before finishing
+- `Skill("mastermind-skills:plan")` — creates the plan this skill executes
+- `Skill("mastermind-skills:taskdev")` — subagent-driven parallel task execution (preferred for complex plans)
+- `Skill("mastermind-skills:finish")` — complete the development branch after all tasks
+- `Skill("mastermind-skills:verify")` — verification gate before finishing

package/.claude/skills/{mastermind → mastermind-skills}/idea.md

@@ -13,7 +13,7 @@ This skill is invoked by `mastermind:master` or directly via `/mastermind:idea`.
 
 **File mode (default, `USE_MONOTASK=false`):**
 
-Invoke `Skill("mastermind:ideate", $ARGUMENTS)` immediately — it provides the same research, evaluation, elaboration, and task-decomposition pipeline with file-first storage (`docs/ideas/` and `docs/tasks/`). The rest of this skill is skipped in file mode.
+Invoke `Skill("mastermind-skills:ideate", $ARGUMENTS)` immediately — it provides the same research, evaluation, elaboration, and task-decomposition pipeline with file-first storage (`docs/ideas/` and `docs/tasks/`). The rest of this skill is skipped in file mode.
 
 **Board mode (`USE_MONOTASK=true`):**
 

package/.claude/skills/{mastermind → mastermind-skills}/implementer-prompt.md

@@ -30,7 +30,7 @@ Task tool (general-purpose):
 
     Once you're clear on requirements:
     1. Implement exactly what the task specifies
-    2. Write tests following TDD (use Skill("mastermind:tdd") if available)
+    2. Write tests following TDD (use Skill("mastermind-skills:tdd") if available)
     3. Verify implementation works
     4. Commit your work
     5. Self-review (see below)

package/.claude/skills/{mastermind → mastermind-skills}/plan.md

@@ -67,7 +67,7 @@ This structure informs the task decomposition. Each task should produce self-con
 ```markdown
 # [Feature Name] Implementation Plan
 
-> **For agentic workers:** REQUIRED SUB-SKILL: Use `Skill("mastermind:taskdev")` (recommended) or `Skill("mastermind:execute")` to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+> **For agentic workers:** REQUIRED SUB-SKILL: Use `Skill("mastermind-skills:taskdev")` (recommended) or `Skill("mastermind-skills:execute")` to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
 
 **Goal:** [One sentence describing what this builds]
 
@@ -181,18 +181,18 @@ After the plan is approved (or in auto mode, after self-review):
 
 **"Plan complete and saved to `docs/mastermind/plans/<filename>.md`. Two execution options:**
 
-**1. Subagent-Driven (recommended)** — Invoke `Skill("mastermind:taskdev")`: dispatches a fresh subagent per task, reviews between tasks, fast iteration.
+**1. Subagent-Driven (recommended)** — Invoke `Skill("mastermind-skills:taskdev")`: dispatches a fresh subagent per task, reviews between tasks, fast iteration.
 
-**2. Inline Execution** — Invoke `Skill("mastermind:execute")`: batch execution with checkpoints.
+**2. Inline Execution** — Invoke `Skill("mastermind-skills:execute")`: batch execution with checkpoints.
 
 **Which approach?"**
 
-**In auto mode:** Skip the question. Default to subagent-driven — invoke `Skill("mastermind:taskdev")` immediately.
+**In auto mode:** Skip the question. Default to subagent-driven — invoke `Skill("mastermind-skills:taskdev")` immediately.
 
 **If Subagent-Driven chosen (or auto mode):**
-- Invoke `Skill("mastermind:taskdev")`
+- Invoke `Skill("mastermind-skills:taskdev")`
 - Fresh subagent per task + two-stage review
 
 **If Inline Execution chosen:**
-- Invoke `Skill("mastermind:execute")`
+- Invoke `Skill("mastermind-skills:execute")`
 - Batch execution with checkpoints for review

package/.claude/skills/{mastermind → mastermind-skills}/runorg.md

@@ -338,17 +338,33 @@ curl -s -X POST "${CTRL_URL}/api/mastermind/event" \
     --argjson ci "${CHECKPOINT_INTERVAL_MS:-600000}" \
     '{type:"org:start",session:$session,org:$org,runId:$runId,goal:$goal,project:$proj,checkpointInterval:$ci,ts:(now*1000|floor)}')" || true
 
-# Print resolved values so Step 3 can embed them in the boss prompt
-echo "ORG_VARS: orgName=${orgName} runId=${runId} sessionId=${sessionId} goal=${goal} bossRole_id=${bossRole_id} bossRole_title=${bossRole_title} bossRole_agent_type=${bossRole_agent_type} board_id=${board_id} todo_col=${todo_col} doing_col=${doing_col} done_col=${done_col} checkpointMin=${checkpointMin} memNs=${memNs} CTRL_URL=${CTRL_URL} MONO_DIR=${MONO_DIR} runFile=${runFile} REPO_ROOT=${REPO_ROOT}"
+# Write context file so Step 3 can read values even if Bash output is truncated
+contextFile="${MONO_DIR}/orgs/${orgName}/runcontext.json"
+jq -cn \
+  --arg orgName "$orgName" --arg runId "$runId" --arg sessionId "$sessionId" \
+  --arg goal "$goal" --arg bossRole_id "$bossRole_id" --arg bossRole_title "$bossRole_title" \
+  --arg bossRole_agent_type "$bossRole_agent_type" --arg board_id "$board_id" \
+  --arg todo_col "$todo_col" --arg doing_col "$doing_col" --arg done_col "$done_col" \
+  --arg checkpointMin "$checkpointMin" --arg memNs "$memNs" --arg CTRL_URL "$CTRL_URL" \
+  --arg MONO_DIR "$MONO_DIR" --arg runFile "$runFile" --arg REPO_ROOT "$REPO_ROOT" \
+  '{orgName:$orgName,runId:$runId,sessionId:$sessionId,goal:$goal,bossRole_id:$bossRole_id,bossRole_title:$bossRole_title,bossRole_agent_type:$bossRole_agent_type,board_id:$board_id,todo_col:$todo_col,doing_col:$doing_col,done_col:$done_col,checkpointMin:$checkpointMin,memNs:$memNs,CTRL_URL:$CTRL_URL,MONO_DIR:$MONO_DIR,runFile:$runFile,REPO_ROOT:$REPO_ROOT}' \
+  > "$contextFile"
+echo "RUNCONTEXT: $contextFile"
+```
+
+After the script completes, note the `RUNCONTEXT:` path it printed. Then run a second Bash call to read it — this survives output truncation:
+
+```bash
+cat "<RUNCONTEXT path from above>"
 ```
 
-After running the script above, read the `ORG_VARS:` line from its output and hold those values for Step 3 (embed them into the boss prompt as literals — **do not re-run bash to look them up**).
+Use the JSON values from that file for Step 3. Do NOT rely on any `ORG_VARS:`-style stdout from the script above — long bash output gets truncated and the values would be lost (see FA-1 in the org-dashboard-v2 ADR).
 
 ---
 
 ## Step 3 — Spawn Boss Agent
 
-Using the literal values from the `ORG_VARS:` output (not shell variables — they don't persist), spawn the boss agent via Task tool:
+Using values from the context file (not shell variables — they don't persist), spawn the boss agent via Task tool:
 
 ```javascript
 Task({
@@ -597,11 +613,11 @@ START NOW: resolve CTRL_URL, check for stop signal, assess the board, create ini
 
 Emit `org:agent:online` for the boss role (team member events are emitted by the boss itself).
 
-**IMPORTANT**: Shell variables do NOT persist across separate Bash tool calls. Read the `ORG_VARS:` line printed in Step 2+3 and substitute each literal value directly into the curl command before running it. Do NOT use `$variableName` syntax — replace each placeholder with its literal string from `ORG_VARS:`.
+**IMPORTANT**: Shell variables do NOT persist across separate Bash tool calls. Use the values read from the `runcontext.json` file in Step 2+3 and substitute each literal value directly into the curl command before running it. Do NOT use `$variableName` syntax — replace each placeholder with its literal string from the context file.
 
 ```bash
 # Replace <CTRL_URL>, <sessionId>, <orgName>, <runId>, <bossRole_id>, <bossRole_title>, <bossRole_agent_type>, <REPO_ROOT>
-# with the LITERAL values from the ORG_VARS: line printed in Step 2+3.
+# with the LITERAL values from runcontext.json read in Step 2+3.
 curl -s -X POST "<CTRL_URL>/api/mastermind/event" \
   -H "Content-Type: application/json" \
   -d "$(jq -cn \

package/.claude/skills/{mastermind → mastermind-skills}/skill-builder.md

@@ -130,11 +130,11 @@ Default mode: **confirm** (or **auto** for low-risk/fast skills).
 
 ---
 
-Invoke `Skill("mastermind:[name]")` passing: brain_context, params, mode.
+Invoke `Skill("mastermind-skills:[name]")` passing: brain_context, params, mode.
 
 After skill returns: follow `_protocol.md` Brain Write Procedure.
 
-Invoke `Skill("mastermind:_repeat")` now. Required — do not skip.
+Invoke `Skill("mastermind-skills:_repeat")` now. Required — do not skip.
 ```
 
 ## Claude Search Optimization (CSO)
@@ -176,15 +176,15 @@ Use words Claude would search for:
 
 **Techniques:**
 - Reference other skills instead of repeating content
-- Use cross-references: `**REQUIRED BACKGROUND:** Use Skill("mastermind:X")`
+- Use cross-references: `**REQUIRED BACKGROUND:** Use Skill("mastermind-skills:X")`
 - One excellent example beats many mediocre ones
 
 ### Cross-Referencing Other Skills
 
 ```markdown
 # GOOD: Explicit requirement marker
-**REQUIRED SUB-SKILL:** Use Skill("mastermind:worktree")
-**REQUIRED BACKGROUND:** You MUST understand Skill("mastermind:finish")
+**REQUIRED SUB-SKILL:** Use Skill("mastermind-skills:worktree")
+**REQUIRED BACKGROUND:** You MUST understand Skill("mastermind-skills:finish")
 
 # BAD: Unclear if required
 See mastermind/worktree.md

package/.claude/skills/{mastermind → mastermind-skills}/taskdev.md

@@ -296,12 +296,12 @@ Done!
 ## Integration
 
 **Required workflow skills:**
-- `Skill("mastermind:plan")` - Creates the plan this skill executes
-- `Skill("mastermind:review")` - Code review template for reviewer subagents
-- `Skill("mastermind:finish")` - Complete development after all tasks done
+- `Skill("mastermind-skills:plan")` - Creates the plan this skill executes
+- `Skill("mastermind-skills:review")` - Code review template for reviewer subagents
+- `Skill("mastermind-skills:finish")` - Complete development after all tasks done
 
 **Subagents should use:**
-- `Skill("mastermind:tdd")` - Subagents follow TDD for each task
+- `Skill("mastermind-skills:tdd")` - Subagents follow TDD for each task
 
 **Alternative workflow:**
-- `Skill("mastermind:execute")` - Use for parallel session instead of same-session execution
+- `Skill("mastermind-skills:execute")` - Use for parallel session instead of same-session execution

package/.claude/skills/{mastermind → mastermind-skills}/tdd.md

@@ -137,7 +137,7 @@ Confirm:
 
 **Test errors?** Fix error, re-run until it fails correctly.
 
-Invoke `Skill("mastermind:verify")` to gate this step: the RED verification must confirm the test fails for the expected reason.
+Invoke `Skill("mastermind-skills:verify")` to gate this step: the RED verification must confirm the test fails for the expected reason.
 
 ### GREEN — Minimal Code
 
@@ -192,7 +192,7 @@ Confirm:
 
 **Other tests fail?** Fix now.
 
-Invoke `Skill("mastermind:verify")` to gate this step.
+Invoke `Skill("mastermind-skills:verify")` to gate this step.
 
 ### REFACTOR — Clean Up
 
@@ -350,7 +350,7 @@ Extract validation for multiple fields if needed.
 
 ## Verification Checklist
 
-Before marking work complete — invoke `Skill("mastermind:verify")` to run this gate:
+Before marking work complete — invoke `Skill("mastermind-skills:verify")` to run this gate:
 
 - [ ] Every new function/method has a test
 - [ ] Watched each test fail before implementing