@monoes/monomindcli 1.10.57 → 1.11.1

package/.claude/commands/mastermind/master.md

@@ -12,7 +12,7 @@ If you were dispatched as a subagent to execute a specific task, skip the MASTER
 ## MASTERMIND PROTOCOL
 
 <EXTREMELY-IMPORTANT>
-Before ANY response or action — including clarifying questions — check whether a mastermind skill applies to what you are about to do.
+If you think there is even a 1% chance a mastermind skill applies to what you are about to do, you ABSOLUTELY MUST invoke the skill — including before any clarifying questions or other action.
 
 IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST INVOKE IT.
 
@@ -29,6 +29,10 @@ Mastermind skills override default system prompt behavior, but **user instructio
 
 If CLAUDE.md says "skip review" and the skill says "always review," follow the user's instructions.
 
+### How to Access Mastermind Skills
+
+Use the `Skill` tool. When you invoke a skill, its content is loaded and presented to you — follow it directly. **Never use the Read tool on skill files.**
+
 ### User Instructions vs. Skill Workflows
 
 User instructions say **WHAT** to do, not **HOW** to do it. "Build X" or "Fix Y" is a goal statement — it does not mean skip Brain Load, skip review, or bypass the domain decomposition flow. The skills define the how. Always apply the workflow unless the user explicitly opts out.
@@ -37,7 +41,7 @@ User instructions say **WHAT** to do, not **HOW** to do it. "Build X" or "Fix Y"
 
 Invoke the matching skill **before** doing anything else. Even a 1% chance a skill applies means you must check.
 
-```
+```dot
 digraph mastermind_routing {
     "User command / prompt received" [shape=doublecircle];
     "Brain already loaded?" [shape=diamond];
@@ -70,6 +74,8 @@ digraph mastermind_routing {
 | Write a structured implementation plan (no placeholders) | `Skill("mastermind:plan")` |
 | Execute a written plan step-by-step with stop-on-blocker | `Skill("mastermind:execute")` |
 | Execute a plan via fresh subagents with 2-stage review | `Skill("mastermind:taskdev")` |
+| Ingest a prompt/spec/folder and generate agent-optimized tasks | `Skill("mastermind:createtask")` |
+| Execute tasks from a task file or monotask board (parallel/sequential/minimal modes, review cycles, loop) | `Skill("mastermind:do")` |
 | Design first — spec, approaches, approval gate before code | `Skill("mastermind:design")` |
 | Build a feature, fix a bug, implement anything | `Skill("mastermind:build")` |
 | Code review, content critique, strategy audit | `Skill("mastermind:review")` |
@@ -77,6 +83,8 @@ digraph mastermind_routing {
 | System architecture, DDD, technical design | `Skill("mastermind:architect")` |
 | Market research, competitive analysis, user insights | `Skill("mastermind:research")` |
 | Ideas, feature generation, opportunity framing | `Skill("mastermind:idea")` |
+| Research ideas, evaluate with PM lens, decompose into subtasks | `Skill("mastermind:ideate")` |
+| Analyze a component, research improvements, generate improvement tasks | `Skill("mastermind:improve")` |
 | Marketing campaign, copy, SEO | `Skill("mastermind:marketing")` |
 | Sales outreach, proposals, pipeline | `Skill("mastermind:sales")` |
 | Blog, docs, newsletters, threads | `Skill("mastermind:content")` |
@@ -135,6 +143,12 @@ These thoughts mean **STOP** — you are rationalizing. Check for a skill first.
 | "Auto mode means I should move fast" | Speed without discipline creates drift. Use skills. |
 | "The user said --auto, so I skip confirmation" | --auto skips user confirmation. It does NOT skip skill invocation. |
 | "Spawned agents don't need to check skills" | Subagents that have Skill access MUST use it. Only subagents with the `<SUBAGENT-STOP>` gate may skip. |
+| "Agent said success" / "should work now" | Agent reports ≠ evidence. Run `mastermind:verify` independently — fresh and complete. |
+| "I'll just make a quick change on main" | No changes on main/master without explicit user consent. `mastermind:worktree` first. |
+| "Should I continue?" (in auto mode) | Never ask. Auto mode means execute continuously until blocked or all tasks complete. |
+| "TBD / TODO / implement later" (in a plan) | Placeholder = plan failure. Every step needs exact paths, complete code, runnable commands. |
+| "Code quality review first, then spec" | Wrong order every time. Spec compliance FIRST, code quality SECOND. Never reversed. |
+| "The subagent can read the plan file itself" | Controller provides full task text to each implementer. Subagents never read plan files. |
 
 ### Mandatory Patterns
 
@@ -147,6 +161,22 @@ These sequences are non-negotiable in all modes:
 - **After any run**: Brain Write Procedure — score decisions, append to AgentDB
 - **Before releasing**: `mastermind:review --tillend --auto` → `mastermind:verify` → `mastermind:finish`
 - **Isolated work**: `mastermind:worktree` before making changes to avoid contaminating main
+- **Before claiming complete**: Run `mastermind:verify` — never claim completion based on agent reports, linter passes, or partial checks
+- **When writing a plan**: Map file structure first → write tasks with exact paths + complete code (no placeholders) → self-review (spec coverage, placeholder scan, type consistency) → offer execution mode choice (subagent-driven vs inline)
+- **When executing with subagents**: Provide full task text to each implementer (never make them read the plan file) → spec compliance review FIRST → code quality review SECOND → re-review until both ✅ → dispatch final reviewer after all tasks complete → then `mastermind:finish`
+- **When blocked during execution**: Stop immediately — do not guess or force through. Diagnose, provide context, re-dispatch with more capable model, or escalate to user
+
+### Iron Laws
+
+These are inviolable regardless of mode, pressure, or context:
+
+| Law | Rule |
+|---|---|
+| **TDD** | No production code without a failing test first. Entry point: `mastermind:tdd`. |
+| **Debug** | No fix without root cause investigation first. Entry point: `mastermind:debug`. |
+| **Verify** | No completion claim without fresh verification evidence. Entry point: `mastermind:verify`. |
+| **Isolation** | No changes on main/master without explicit user consent. Entry point: `mastermind:worktree`. |
+| **Plans** | No placeholders: every plan step has exact file paths, complete code, and runnable commands. Entry point: `mastermind:plan`. |
 
 ### Platform Note
 
@@ -209,7 +239,7 @@ Describe your goal. Mastermind identifies the relevant domains, spawns specialis
 `/mastermind:skill-builder` — write or improve a mastermind skill with TDD discipline
 
 ---
-Flags: `--auto` · `--confirm` · `--project <name>` · `--iterate <N>`
+Flags: `--auto` · `--confirm` · `--project <name>` · `--iterate <N>` · `--monotask`
 
 ---
 
@@ -226,6 +256,7 @@ Extract from `$ARGUMENTS`:
 - `--confirm` → mode = confirm
 - `--project <name>` → project_name = <name>
 - `--iterate <N>` → iterate = N (integer ≥ 1; when flag is absent, no iteration runs)
+- `--monotask` → use_monotask = true (default: false — domain tracking writes to session files only)
 - Remaining text = prompt
 
 If `--project` was not provided, default `project_name` to the current directory name:
@@ -343,7 +374,9 @@ If mode = auto: proceed immediately.
 
 ### Step 6 — Monotask Setup
 
-Follow the Monotask Space+Board Setup Procedure from `_protocol.md`. Resolve the space **once**, then create one board per active domain. Use `project_name` as the space name so all boards across repos and domains share the same space.
+**Skip this step entirely if `use_monotask` is false** (the default). Domain tracking uses session JSON files only — no boards are created. Set `monotask_available: false` in `current.json` so Step 7 runs without board IDs.
+
+If `use_monotask` is true: follow the Monotask Space+Board Setup Procedure from `_protocol.md`. Resolve the space **once**, then create one board per active domain. Use `project_name` as the space name so all boards across repos and domains share the same space.
 
 **Board naming convention:** Every board is named `<project_name>-<domain>` (e.g. `factory-idea`, `factory-build`). This canonical name is stable across runs — mastermind finds the existing board instead of creating a new one every time.
 
@@ -610,7 +643,7 @@ Each Task call must include a complete briefing following the Monotask Task Brie
 - The specific goal for this domain
 - The project name and run context
 - Instruction to create monotask cards directly using `monotask card create $BOARD_ID $COL_TODO_ID "<title>" --json` for all sub-tasks
-- Instruction to use `Skill("monomind:do")` to execute tasks (Task agents have Skill tool access — do NOT use slash command syntax)
+- Instruction to use `Skill("mastermind:do")` to execute tasks (Task agents have Skill tool access — do NOT use slash command syntax)
 - Instruction to spawn specialized agents using the domain-appropriate swarm topology
 - Instruction to return the unified output schema when done
 
@@ -660,7 +693,7 @@ Task({
     "     -H 'Content-Type: application/json' \\\n" +
     "     -d \"$(jq -cn --arg sid '<SESSION_ID>' --arg to '<domain>' --arg msg '<summary>' \\\n" +
     "       '{type:\"intercom\",session:$sid,from:\"build\",to:$to,msg:$msg,ts:(now*1000|floor)}')\" || true\n\n" +
-    "5. Execute tasks via Skill(\"monomind:do\") --board <board_build>  (use Skill tool — slash command syntax does not work inside a Task agent)\n" +
+    "5. Execute tasks via Skill(\"mastermind:do\") --board <board_build>  (use Skill tool — slash command syntax does not work inside a Task agent)\n" +
     "6. Collect all agent outputs\n\n" +
     "7. BEFORE returning, write your output schema to disk AND emit domain:complete:\n" +
     "   REPO_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)\n" +

package/.claude/commands/mastermind/memory.md

@@ -5,7 +5,7 @@ description: AgentDB memory system — store, search, retrieve, list, delete, an
 
 # Monomind Memory System
 
-Persistent memory backed by AgentDB with HNSW vector indexing for semantic search (150x-12,500x faster than brute-force). Supports cross-session and cross-agent collaboration.
+Persistent memory backed by AgentDB with pure-JS HNSW vector indexing for semantic search (O(log n) approximate nearest neighbor). Supports cross-session and cross-agent collaboration.
 
 ## Subcommands
 

package/.claude/commands/memory/memory-search.md

@@ -21,7 +21,7 @@ npx monomind memory search [options]
 | `--limit` | `-l` | number | `10` | Maximum results to return |
 | `--threshold` | — | number | `0.7` | Minimum similarity threshold (0–1) |
 | `--type` | `-t` | string | `hybrid` | Search type: `semantic`, `keyword`, `hybrid` |
-| `--build-hnsw` | — | boolean | `false` | Build HNSW index before search (150x–12,500x speedup) |
+| `--build-hnsw` | — | boolean | `false` | Build pure-JS HNSW index before search (O(log n) vs O(n) linear) |
 | `--format` | — | string | — | Output format: `json` |
 
 ## Examples
@@ -56,7 +56,7 @@ npx monomind memory search -q "auth" --format json
 
 ## HNSW Index
 
-Use `--build-hnsw` when searching large memory stores (1,000+ entries). The HNSW index provides 150x–12,500x search speedup after the one-time build cost.
+Use `--build-hnsw` when searching large memory stores (1,000+ entries). The pure-JS HNSW index gives O(log n) approximate-nearest-neighbor queries (vs O(n) linear scan) after the one-time build cost.
 
 ## MCP Tool
 

package/.claude/commands/monitoring/status.md

@@ -65,7 +65,7 @@ npx monomind status memory
 - **Tasks** — pending / running / completed / failed / total
 - **Memory** — backend, entries, size, search time, cache hit rate
 - **MCP Server** — running state, transport, port
-- **Performance** — CPU usage, memory usage, Flash Attention, vector search speed
+- **Performance** — CPU usage, memory usage, vector search speed
 
 ## Health Check Mode
 

package/.claude/commands/{browse.md → monobrowse.md}

@@ -1,5 +1,5 @@
 ---
-name: browse
+name: monobrowse
 description: Launch monomind browse for web UI testing and automation — native TypeScript CDP client, no external binary needed
 ---
 
@@ -18,4 +18,4 @@ Use the full monomind browse workflow:
 4. Re-snapshot to verify
 5. Report results (PASS / FAIL / WARN)
 
-Examples: `/browse`, `/browse https://example.com`, `/browse test the login flow`
+Examples: `/monobrowse`, `/monobrowse https://example.com`, `/monobrowse test the login flow`

package/.claude/commands/sparc.md

@@ -109,4 +109,4 @@ Task({ subagent_type: "reviewer", description: "Security and code review", run_i
 - Store important decisions in memory across phases
 - All tasks should end with verification against acceptance criteria
 
-See `/monomind:help` for all available commands.
+See `/mastermind:help` for all available commands.

package/.claude/helpers/handlers/graph-status-handler.cjs

@@ -13,7 +13,7 @@ module.exports = {
 
     var db = _openMonographDb();
     if (!db) {
-      console.log('No monograph.db found. Run /monomind:understand to build.');
+      console.log('No monograph.db found. Run /mastermind:understand to build.');
       return;
     }
     try {

package/.claude/helpers/loop-tracker.cjs

@@ -48,7 +48,7 @@ function parseRepInfo(prompt, reason) {
 
 function detectType(prompt, maxReps) {
   if (maxReps > 0) return 'repeat';
-  if ((prompt || '').startsWith('/monomind-repeat') || (prompt || '').startsWith('/loop')) return 'repeat';
+  if ((prompt || '').startsWith('/mastermind-repeat') || (prompt || '').startsWith('/loop')) return 'repeat';
   return 'do';
 }
 

package/.claude/skills/agent-browser-testing/SKILL.md

@@ -5,7 +5,7 @@ version: 4.0.0
 triggers:
   - /agent-browser-testing
   - /ui-test
-  - /browse
+  - /monobrowse
   - /qa
   - /crawl
   - ui test

package/.claude/skills/hooks-automation/SKILL.md

@@ -637,9 +637,6 @@ mcp__monomind__memory_store {
     linted: true
   })
 }
-
-// Train neural patterns:
-// npx monomind neural train --pattern coordination --data edit-patterns
 ```
 
 #### Session End Hook with State Persistence

package/.claude/skills/mastermind/build.md

@@ -120,7 +120,7 @@ Spawn one Task agent per task (all in parallel where dependencies allow):
 - Code review: subagent_type "reviewer"
 - TDD/SPARC work: subagent_type "sparc-coder"
 
-Also run /monomind:do --board <board_id> to track execution.
+Also run /mastermind:do --board <board_id> to track execution.
 
 STEP 4 — COLLECT AND RETURN
 Collect all agent output schemas. Return to caller:

package/.claude/skills/mastermind/code-quality-reviewer-prompt.md

@@ -0,0 +1,60 @@
+# Code Quality Reviewer Prompt Template
+
+Use this template when dispatching a code quality reviewer subagent from `mastermind:taskdev`.
+
+**Purpose:** Verify implementation is well-built — clean, tested, maintainable.
+
+**Only dispatch AFTER spec compliance review passes (✅).** Never run this first.
+
+```
+Task tool (general-purpose):
+  description: "Code quality review for Task N: [task name]"
+  prompt: |
+    You are reviewing the code quality of a recently implemented task.
+
+    ## Task Summary
+
+    [From implementer's report — what was built]
+
+    ## Diff to Review
+
+    BASE_SHA: [commit before task]
+    HEAD_SHA: [current commit after task]
+
+    Review the changes introduced between these commits.
+
+    ## What to Check
+
+    **Code quality:**
+    - Is the code clean and maintainable?
+    - Are names clear and accurate (match what things do, not how they work)?
+    - Is there duplication that could be DRY'd up?
+    - Are there magic numbers or hardcoded strings that should be constants?
+
+    **File structure:**
+    - Does each file have one clear responsibility with a well-defined interface?
+    - Are units decomposed so they can be understood and tested independently?
+    - Is the implementation following the file structure from the plan?
+    - Did this task create new files that are already large, or significantly grow
+      existing files? (Focus on what this change contributed, not pre-existing sizes.)
+
+    **Tests:**
+    - Do tests actually verify behavior (not just mock behavior)?
+    - Is test coverage adequate for the functionality added?
+    - Are tests readable and well-named?
+
+    **YAGNI / over-engineering:**
+    - Was anything built that wasn't needed?
+    - Is any abstraction premature?
+
+    ## Report Format
+
+    Return:
+    - **Strengths:** What was done well
+    - **Issues (Critical):** Must fix before proceeding
+    - **Issues (Important):** Should fix — notable quality problems
+    - **Issues (Minor):** Nice to have — low priority
+    - **Assessment:** ✅ Approved | ❌ Needs fixes
+
+    If issues are found, the implementer will fix them and you will re-review.
+```

package/.claude/skills/mastermind/content.md

@@ -147,7 +147,7 @@ Stage 2 draft: subagent_type "Content Creator"
 Stage 3 edit: subagent_type "Technical Writer"
 Stage 4 format/publish: subagent_type "Content Creator"
 
-Also run /monomind:do --board <board_id> to track execution.
+Also run /mastermind:do --board <board_id> to track execution.
 
 STEP 4 — COLLECT AND RETURN
 Collect the final formatted content. Return to caller:

package/.claude/skills/mastermind/createorg.md

@@ -68,7 +68,72 @@ Parse `roles_desc` (if provided) into a list of role titles. If not provided, de
 | product / product manager | `Product Manager` | Roadmap, prioritization |
 | qa / tester | `tester` | Quality assurance, testing |
 
-If a role doesn't match any keyword, use `general-purpose` and note it in the org config.
+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.
+
+---
+
+## Step 2.5 — Complete Every Agent's Specification (generate what's missing)
+
+**This is the step that makes each created agent actually work.** A role is only usable if it has: skills, an instruction document (system prompt), an input contract, and an output contract. Most of these are missing from a bare role description — **generate them, tailored to the specific agent, rather than leaving them blank.**
+
+For **each** role, do the following:
+
+**1. Check whether a usable agent definition already exists.**
+```bash
+# Match by frontmatter `name:` first, then by filename slug, anywhere under .claude/agents
+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).
+
+**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:
+
+```markdown
+---
+name: <agent_type>
+description: <one line — who this agent is and what it does>
+capability:
+  role: <agent_type>
+  goal: <one sentence: the agent's standing objective in this org>
+  version: "1.0.0"
+  expertise:            # 4–6 concrete SKILLS this role needs to do its job well
+    - <skill>
+    - <skill>
+  task_types:           # 3–5 kinds of work it performs
+    - <task-type>
+  input_type: <what this agent consumes — who/what it receives, derived from its inbound communication edges + responsibilities>
+  output_type: <what this agent produces — the artifact it hands off or reports, derived from its outbound edges + responsibilities>
+  model_preference: sonnet
+  termination: <the condition under which this agent's job is done>
+---
+
+# <Role Title>
+
+<1–2 sentences: the agent's identity and stance.>
+
+## Core Responsibilities
+<the role's responsibilities, expanded into numbered, actionable duties>
+
+## Operating Guidelines
+<3–6 concrete rules that keep this agent doing the right thing for its domain — what to always do, what never to do, how to handle missing inputs>
+
+## Communication
+- **Receives (input)**: <sources + what, from the inbound edges in Step 3>
+- **Sends (output)**: <targets + what, from the outbound edges in Step 3>
+- **Protocol**: <direct / via manager; who it reports to>
+
+## Quality Bar
+<one sentence defining "good output" for this role, so the agent can self-check>
+```
+
+Generate this content with real domain reasoning — the `expertise`, `input_type`, `output_type`, and instruction body must be specific to *this* agent (a prosecutor's skills are not a judge's). Reuse a generated def across roles of the same `agent_type` (don't regenerate if you just created it this run).
+
+**3. Populate the org role.** Set the role's `skills` array to the def's `expertise` list (so the org config is self-describing), and keep `agent_type` pointing at the (possibly newly coined) type. Never leave `skills: []` when expertise was generated.
+
+**4. Note generated files** for the Step 8 artifacts list.
+
+The dashboard agent drawer and `runorg` both read these definitions (matched by `agent_type`), so generating them here is what makes the Roles/Skills/instructions show up *and* what gives each spawned agent its real instructions at run time.
 
 ---
 
@@ -103,6 +168,15 @@ boss → middle_manager (feedback)
 
 Adjust for the actual roles in this run. Assign `reports_to` on each role using the derived topology.
 
+**Completeness rules (every role must be properly wired — no orphans):**
+- Every executor role has **≥1 inbound edge** (how work reaches it — usually a `command`) and **≥1 outbound edge** (how its output leaves — usually a `report` or `handoff`).
+- Where one role's output is another's input, connect them with a `handoff` in that direction (e.g. clerk → counsel; writer → editor). Make sequential producer→consumer chains explicit.
+- The coordinator/boss has an inbound `report` from each role it commands, so results flow back up.
+- Peer roles that critique each other get `feedback` edges; adversarial pairs (e.g. prosecutor ↔ defender) get reciprocal `handoff` edges.
+- After building edges, **derive each role's input/output contract from them**: a role's `input_type` summarizes who/what its inbound edges deliver; its `output_type` summarizes what its outbound edges carry. Feed these into the generated definition from Step 2.5 so the spec and the topology agree.
+
+A role that ends up with no inbound or no outbound edge is a bug — re-examine the topology before saving.
+
 ---
 
 ## Step 4 — Build Org Config
@@ -128,7 +202,7 @@ Ask the user (or infer from prompt) for the optional Paperclip-style fields:
       "agent_type": "<subagent_type slug from mapping table>",
       "responsibilities": ["<1-3 bullet responsibilities>"],
       "reports_to": "<role id or null>",
-      "skills": [],
+      "skills": ["<populated from the generated def's expertise in Step 2.5 — never left empty>"],
       "adapter_config": {
         "model": "<claude model id>",
         "max_tokens": 8192
@@ -332,6 +406,9 @@ status: complete
 artifacts:
   - path: .monomind/orgs/<org_name>.json
     type: config
+  - path: .claude/agents/generated/<agent_type>.md
+    type: agent-definition
+    note: "one per role whose agent_type lacked a usable definition (skills, instructions, input/output)"
 decisions:
   - what: "Org <org_name> created with N roles"
     why: "Role mapping derived from goal and user description"

package/.claude/skills/mastermind/design.md

@@ -137,12 +137,14 @@ Fix any issues inline. No need to re-review — just fix and move on.
 
 ### User Review Gate
 
-After the spec self-review, ask the user to review the written spec before proceeding:
+**In confirm mode (default):** Ask the user to review the written spec before proceeding:
 
 > "Spec written and committed to `<path>`. Please review it and let me know if you want any changes before we start writing the implementation plan."
 
 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")`.
+
 ### Transition to Planning
 
 - Invoke `Skill("mastermind:plan")` to create a detailed implementation plan

package/.claude/skills/mastermind/finance.md

@@ -116,7 +116,7 @@ Spawn one Task agent per workstream:
 - Financial tracking and invoicing: subagent_type "Finance Tracker"
 - Analysis and reporting: subagent_type "Analytics Reporter"
 
-Also run /monomind:do --board <board_id> to track execution.
+Also run /mastermind:do --board <board_id> to track execution.
 
 STEP 4 — COLLECT AND RETURN
 Collect all financial outputs. Return to caller:

package/.claude/skills/mastermind/implementer-prompt.md

@@ -0,0 +1,109 @@
+# Implementer Subagent Prompt Template
+
+Use this template when dispatching an implementer subagent from `mastermind:taskdev`.
+
+```
+Task tool (general-purpose):
+  description: "Implement Task N: [task name]"
+  prompt: |
+    You are implementing Task N: [task name]
+
+    ## Task Description
+
+    [FULL TEXT of task from plan — paste it here, do not make the subagent read the file]
+
+    ## Context
+
+    [Scene-setting: where this fits, dependencies, architectural context, brain context summary]
+
+    ## Before You Begin
+
+    If you have questions about:
+    - The requirements or acceptance criteria
+    - The approach or implementation strategy
+    - Dependencies or assumptions
+    - Anything unclear in the task description
+
+    **Ask them now.** Raise any concerns before starting work.
+
+    ## Your Job
+
+    Once you're clear on requirements:
+    1. Implement exactly what the task specifies
+    2. Write tests following TDD (use Skill("mastermind:tdd") if available)
+    3. Verify implementation works
+    4. Commit your work
+    5. Self-review (see below)
+    6. Report back
+
+    Work from: [directory]
+
+    **While you work:** If you encounter something unexpected or unclear, **ask questions**.
+    It's always OK to pause and clarify. Don't guess or make assumptions.
+
+    ## Code Organization
+
+    - Follow the file structure defined in the plan
+    - Each file should have one clear responsibility with a well-defined interface
+    - If a file you're creating is growing beyond the plan's intent, stop and report
+      it as DONE_WITH_CONCERNS — don't split files on your own without plan guidance
+    - If an existing file you're modifying is already large or tangled, work carefully
+      and note it as a concern in your report
+    - In existing codebases, follow established patterns. Improve code you're touching
+      the way a good developer would, but don't restructure things outside your task.
+
+    ## When You're in Over Your Head
+
+    It is always OK to stop and say "this is too hard for me." Bad work is worse than
+    no work. You will not be penalized for escalating.
+
+    **STOP and escalate when:**
+    - The task requires architectural decisions with multiple valid approaches
+    - You need to understand code beyond what was provided and can't find clarity
+    - You feel uncertain about whether your approach is correct
+    - The task involves restructuring existing code in ways the plan didn't anticipate
+    - You've been reading file after file trying to understand the system without progress
+
+    **How to escalate:** Report back with status BLOCKED or NEEDS_CONTEXT. Describe
+    specifically what you're stuck on, what you've tried, and what kind of help you need.
+
+    ## Before Reporting Back: Self-Review
+
+    Review your work with fresh eyes. Ask yourself:
+
+    **Completeness:**
+    - Did I fully implement everything in the spec?
+    - Did I miss any requirements?
+    - Are there edge cases I didn't handle?
+
+    **Quality:**
+    - Is this my best work?
+    - Are names clear and accurate?
+    - Is the code clean and maintainable?
+
+    **Discipline:**
+    - Did I avoid overbuilding (YAGNI)?
+    - Did I only build what was requested?
+    - Did I follow existing patterns in the codebase?
+
+    **Testing:**
+    - Do tests actually verify behavior (not just mock behavior)?
+    - Did I follow TDD if required?
+    - Are tests comprehensive?
+
+    If you find issues during self-review, fix them now before reporting.
+
+    ## Report Format
+
+    When done, report:
+    - **Status:** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
+    - What you implemented (or what you attempted, if blocked)
+    - What you tested and test results
+    - Files changed
+    - Self-review findings (if any)
+    - Any issues or concerns
+
+    Use DONE_WITH_CONCERNS if you completed the work but have doubts about correctness.
+    Use BLOCKED if you cannot complete the task. Use NEEDS_CONTEXT if you need
+    information that wasn't provided. Never silently produce work you're unsure about.
+```

package/.claude/skills/mastermind/marketing.md

@@ -172,7 +172,7 @@ Spawn one Task agent per workstream (all in parallel — star topology, hub aggr
 - Product launch / GTM: subagent_type "Launch Strategist" (slug: launch-strategist)
 - Competitive content / comparison pages: subagent_type "Competitive Content Strategist" (slug: competitive-content)
 
-Also run /monomind:do --board <board_id> to track execution.
+Also run /mastermind:do --board <board_id> to track execution.
 
 STEP 4 — COLLECT AND RETURN
 Collect all agent outputs. Return to caller:

package/.claude/skills/mastermind/ops.md

@@ -118,7 +118,7 @@ Spawn one Task agent per workstream (star topology — hub aggregates independen
 - Infrastructure automation: subagent_type "DevOps Automator"
 - CI/CD pipelines: subagent_type "cicd-engineer"
 
-Also run /monomind:do --board <board_id> to track execution.
+Also run /mastermind:do --board <board_id> to track execution.
 
 STEP 4 — COLLECT AND RETURN
 Collect all agent outputs. Return to caller:

package/.claude/skills/mastermind/plan.md

@@ -159,9 +159,25 @@ If you find issues, fix them inline. No need to re-review — just fix and move
 
 ---
 
+## User Review Gate
+
+After self-review:
+
+**In confirm mode (default):** Ask the user to review the written plan before proceeding:
+
+> "Plan written and saved to `docs/mastermind/plans/<filename>.md`. Please review it and let me know if you'd like any changes before we start execution."
+
+Wait for the user's response. If they request changes, make them inline and re-run the self-review. Only proceed once the user approves.
+
+**In auto mode:** Skip the wait. Proceed directly to execution handoff.
+
+---
+
 ## Execution Handoff
 
-After saving the plan, offer execution choice:
+After the plan is approved (or in auto mode, after self-review):
+
+**In confirm mode (default):** Ask the user to choose execution mode:
 
 **"Plan complete and saved to `docs/mastermind/plans/<filename>.md`. Two execution options:**
 
@@ -171,7 +187,9 @@ After saving the plan, offer execution choice:
 
 **Which approach?"**
 
-**If Subagent-Driven chosen:**
+**In auto mode:** Skip the question. Default to subagent-driven — invoke `Skill("mastermind:taskdev")` immediately.
+
+**If Subagent-Driven chosen (or auto mode):**
 - Invoke `Skill("mastermind:taskdev")`
 - Fresh subagent per task + two-stage review
 

package/.claude/skills/mastermind/release.md

@@ -118,7 +118,7 @@ Spawn Task agents in release order (hierarchical raft — coordinator maintains
 - Infrastructure and deploy: subagent_type "DevOps Automator"
 - CI/CD pipeline: subagent_type "cicd-engineer"
 
-Also run /monomind:do --board <board_id> to track execution.
+Also run /mastermind:do --board <board_id> to track execution.
 
 STEP 4 — COLLECT AND RETURN
 Collect all stage outcomes. Return to caller:

package/.claude/skills/mastermind/research.md

@@ -118,7 +118,7 @@ Spawn one Task agent per research stream (mesh topology — findings cross-polli
 - User behavior and UX signals: subagent_type "UX Researcher"
 - Data and metrics analysis: subagent_type "Analytics Reporter"
 
-Also run /monomind:do --board <board_id> to track execution.
+Also run /mastermind:do --board <board_id> to track execution.
 
 STEP 4 — COLLECT AND RETURN
 Synthesize all research streams into an intelligence report. Return to caller:

package/.claude/skills/mastermind/review.md

@@ -119,7 +119,7 @@ Spawn one Task agent per review angle (mesh topology — reviewers share finding
 - Analytics/metrics: subagent_type "Analytics Reporter"
 - Accessibility: subagent_type "Accessibility Auditor"
 
-Also run /monomind:do --board <board_id> to track execution.
+Also run /mastermind:do --board <board_id> to track execution.
 
 STEP 4 — COLLECT AND RETURN
 Synthesize all review findings. Return to caller: