@monoes/monomindcli 2.9.21 → 2.9.23

package/.claude/helpers/statusline.cjs

@@ -398,7 +398,7 @@ function getSecurityStatus() {
 }
 
 // Swarm status (pure file reads, NO ps aux)
-function getSwarmStatus() {
+function getMonoswarmStatus() {
   const staleThresholdMs = 5 * 60 * 1000;
   const agentRegTtlMs = 30 * 60 * 1000; // registration files expire after 30 min
   const now = Date.now();
@@ -424,14 +424,14 @@ function getSwarmStatus() {
     } catch { /* fall through */ }
   }
 
-  // SECONDARY: swarm-state.json written by MCP swarm_init — trust if fresh.
+  // SECONDARY: state.json written by MCP monoswarm_init — trust if fresh.
   // The MCP tools resolve their data root via getMonomindDataRoot(), which
   // inside a git repo is `<repo>/.git/monomind` — so reading only
   // `<cwd>/.monomind` showed a stale or missing swarm in every real project.
   // Canonical first, legacy second for projects written by an older CLI.
   const swarmStateCandidates = [
-    path.join(monomindDataRoot(CWD), 'swarm', 'swarm-state.json'),
-    path.join(CWD, '.monomind', 'swarm', 'swarm-state.json'),
+    path.join(monomindDataRoot(CWD), 'monoswarm', 'state.json'),
+    path.join(CWD, '.monomind', 'monoswarm', 'state.json'),
   ];
   let swarmState = null;
   for (const p of swarmStateCandidates) { swarmState = readJSON(p); if (swarmState) break; }
@@ -447,16 +447,16 @@ function getSwarmStatus() {
     }
   }
 
-  // TERTIARY: swarm-activity.json refreshed by post-task hook
-  const activityData = readJSON(path.join(CWD, '.monomind', 'metrics', 'swarm-activity.json'));
-  if (activityData?.swarm) {
-    const updatedAt = activityData.timestamp || activityData.swarm.timestamp;
+  // TERTIARY: monoswarm-activity.json refreshed by post-task hook
+  const activityData = readJSON(path.join(CWD, '.monomind', 'metrics', 'monoswarm-activity.json'));
+  if (activityData?.monoswarm) {
+    const updatedAt = activityData.timestamp || activityData.monoswarm.timestamp;
     const age = updatedAt ? now - new Date(updatedAt).getTime() : Infinity;
     if (age < staleThresholdMs) {
       return {
-        activeAgents: activityData.swarm.agent_count || 0,
+        activeAgents: activityData.monoswarm.agent_count || 0,
         maxAgents: CONFIG.maxAgents,
-        coordinationActive: activityData.swarm.coordination_active || activityData.swarm.active || false,
+        coordinationActive: activityData.monoswarm.coordination_active || activityData.monoswarm.active || false,
       };
     }
   }
@@ -505,7 +505,7 @@ function getSystemMetrics() {
 
   // Sub-agents from file metrics (no ps aux)
   let subAgents = 0;
-  const activityData = readJSON(path.join(CWD, '.monomind', 'metrics', 'swarm-activity.json'));
+  const activityData = readJSON(path.join(CWD, '.monomind', 'metrics', 'monoswarm-activity.json'));
   if (activityData?.processes?.estimated_agents) {
     subAgents = activityData.processes.estimated_agents;
   }
@@ -1149,7 +1149,7 @@ function fmtCost(n) {
 // ── Single-line statusline (compact) ─────────────────────────────
 function generateStatusline() {
   const git       = getGitInfo();
-  const swarm     = getSwarmStatus();
+  const monoswarm     = getMonoswarmStatus();
   const system    = getSystemMetrics();
   const hooks     = getHooksStatus();
   const knowledge = getKnowledgeStats();
@@ -1157,8 +1157,8 @@ function generateStatusline() {
   const parts     = [];
 
   // Brand + swarm dot
-  const swarmDot = swarm.coordinationActive ? `${x.green}●${x.reset}` : `${x.slate}○${x.reset}`;
-  parts.push(`${x.bold}${x.purple}▊ Monomind${x.reset} ${swarmDot}`);
+  const monoswarmDot = monoswarm.coordinationActive ? `${x.green}●${x.reset}` : `${x.slate}○${x.reset}`;
+  parts.push(`${x.bold}${x.purple}▊ Monomind${x.reset} ${monoswarmDot}`);
 
   // Git branch + changes (compact)
   if (git.gitBranch) {
@@ -1208,8 +1208,8 @@ function generateStatusline() {
   }
 
   // Swarm agents (only when active)
-  if (swarm.activeAgents > 0) {
-    parts.push(`${x.gold}🐝 ${swarm.activeAgents}/${swarm.maxAgents}${x.reset}`);
+  if (monoswarm.activeAgents > 0) {
+    parts.push(`${x.gold}🐝 ${monoswarm.activeAgents}/${monoswarm.maxAgents}${x.reset}`);
   }
 
   // Hooks
@@ -1269,7 +1269,7 @@ function generateDashboard() {
   const git         = getGitInfo();
   const progress    = getv1Progress();
   const security    = getSecurityStatus();
-  const swarm       = getSwarmStatus();
+  const monoswarm       = getMonoswarmStatus();
   const system      = getSystemMetrics();
   const adrs        = getADRStatus();
   const hooks       = getHooksStatus();
@@ -1285,10 +1285,10 @@ function generateDashboard() {
   const lines       = [];
 
   // ── Header: brand + git + model + session ────────────────────
-  const swarmDot = swarm.coordinationActive ? `${x.green}● LIVE${x.reset}` : `${x.slate}○ IDLE${x.reset}`;
+  const monoswarmDot = monoswarm.coordinationActive ? `${x.green}● LIVE${x.reset}` : `${x.slate}○ IDLE${x.reset}`;
   const projName = getProjectName();
   const cwdName = path.basename(CWD);
-  let hdr = `${x.bold}${x.purple}▊Monomind ${VERSION}${x.reset} ${swarmDot} ${x.teal}${x.bold}${projName}${x.reset} ${DIV} ${x.dim}◎${cwdName}${x.reset} ${DIV} ${x.violet}⬡${git.name}${x.reset}`;
+  let hdr = `${x.bold}${x.purple}▊Monomind ${VERSION}${x.reset} ${monoswarmDot} ${x.teal}${x.bold}${projName}${x.reset} ${DIV} ${x.dim}◎${cwdName}${x.reset} ${DIV} ${x.violet}⬡${git.name}${x.reset}`;
 
   if (git.gitBranch) {
     hdr += ` ${DIV} ${x.sky}⎇${x.bold}${git.gitBranch}${x.reset}`;
@@ -1443,7 +1443,7 @@ function generateJSON() {
     user:       { name: git.name, gitBranch: git.gitBranch, modelName: getModelName() },
     domains:    getv1Progress(),
     security:   getSecurityStatus(),
-    swarm:      getSwarmStatus(),
+    monoswarm:  getMonoswarmStatus(),
     system:     getSystemMetrics(),
     adrs:       getADRStatus(),
     hooks:      getHooksStatus(),
@@ -1472,7 +1472,7 @@ function readMode() {
 if (require.main !== module) {
   module.exports = {
     readJSON, safeStat, modelLabel, getVersion,
-    getSecurityStatus, getSwarmStatus, getADRStatus,
+    getSecurityStatus, getMonoswarmStatus, getADRStatus,
     getHooksStatus, getActiveAgent, getLanceDBStats,
     getLearningStats, getTestStats, getIntegrationStatus,
     getActiveOrgs,

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

@@ -14,10 +14,7 @@ const path = require('path');
 const WEB_SEARCH_COST = 0.01;
 
 const FALLBACK_PRICING = {
-  'claude-fable-5':   { in: 10e-6, out: 50e-6, cw: 12.5e-6, cr: 1e-6,   fast: 1 },
-  'claude-mythos-5':  { in: 10e-6, out: 50e-6, cw: 12.5e-6, cr: 1e-6,   fast: 1 },
   'claude-opus-5':    { in: 5e-6, out: 25e-6, cw: 6.25e-6, cr: 0.5e-6,  fast: 6 },
-  'claude-opus-4-8':  { in: 5e-6, out: 25e-6, cw: 6.25e-6, cr: 0.5e-6,  fast: 6 },
   'claude-opus-4-7':  { in: 5e-6, out: 25e-6, cw: 6.25e-6, cr: 0.5e-6,  fast: 6 },
   'claude-sonnet-5':  { in: 3e-6, out: 15e-6, cw: 3.75e-6, cr: 0.3e-6,  fast: 1 },
   'claude-opus-4-6':  { in: 5e-6, out: 25e-6, cw: 6.25e-6, cr: 0.5e-6,  fast: 6 },
@@ -39,10 +36,7 @@ const FALLBACK_PRICING = {
 };
 
 const SHORT_MODEL_NAMES = {
-  'claude-fable-5': 'Fable 5',
-  'claude-mythos-5': 'Mythos 5',
   'claude-opus-5': 'Opus 5',
-  'claude-opus-4-8': 'Opus 4.8',
   'claude-opus-4-7': 'Opus 4.7',
   'claude-sonnet-5': 'Sonnet 5',
   'claude-opus-4-6': 'Opus 4.6',

package/.claude/settings.json

@@ -1,5 +1,5 @@
 {
-  "customInstructions": "Follow the project's CLAUDE.md guidelines. Use concurrent execution for all operations. Prioritize v1 implementation with security-first development, 15-agent swarm coordination, phased performance optimization, and cross-platform helper automation.",
+  "customInstructions": "Follow the project's CLAUDE.md guidelines. Use concurrent execution for all operations. Prioritize v1 implementation with security-first development, 15-agent monoswarm coordination, phased performance optimization, and cross-platform helper automation.",
   "env": {},
   "permissions": {
     "allow": [
@@ -333,13 +333,12 @@
   "monomind": {
     "version": "3.5.2",
     "enabled": true,
-    "swarm": {
+    "monoswarm": {
       "topology": "hierarchical-mesh",
       "maxAgents": 15
     },
     "memory": {
       "backend": "hybrid",
-      "enableHNSW": true,
       "learningBridge": {
         "enabled": true
       },

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

@@ -606,7 +606,7 @@ mcp__monomind__agent_spawn {
   capabilities: ["api", "database", "testing"]
 }
 
-mcp__monomind__memory_store {
+mcp__monomind__memory_pattern-store {
   action: "store",
   key: "swarm/task/api-build/context",
   namespace: "coordination",
@@ -625,7 +625,7 @@ mcp__monomind__memory_store {
 npx monomind hook post-edit --file "api/auth.js"
 
 // Internally calls MCP tools:
-mcp__monomind__memory_store {
+mcp__monomind__memory_pattern-store {
   action: "store",
   key: "swarm/edits/api/auth.js",
   namespace: "coordination",
@@ -663,7 +663,7 @@ All hooks follow a standardized memory coordination pattern:
 
 **Phase 1: STATUS** - Hook starts
 ```javascript
-mcp__monomind__memory_store {
+mcp__monomind__memory_pattern-store {
   action: "store",
   key: "swarm/hooks/pre-edit/status",
   namespace: "coordination",
@@ -678,7 +678,7 @@ mcp__monomind__memory_store {
 
 **Phase 2: PROGRESS** - Hook processes
 ```javascript
-mcp__monomind__memory_store {
+mcp__monomind__memory_pattern-store {
   action: "store",
   key: "swarm/hooks/pre-edit/progress",
   namespace: "coordination",
@@ -692,7 +692,7 @@ mcp__monomind__memory_store {
 
 **Phase 3: COMPLETE** - Hook finishes
 ```javascript
-mcp__monomind__memory_store {
+mcp__monomind__memory_pattern-store {
   action: "store",
   key: "swarm/hooks/pre-edit/complete",
   namespace: "coordination",

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

@@ -131,7 +131,7 @@ Only include `adapter_config`, `provider`, or `policy` on a role when Step 2.3 p
 
 ## Step 4 — Show Plan and Confirm (confirm mode)
 
-Render the org plan in a clear human-readable format:
+Render the org plan in a clear human-readable format. **The model assigned to each role is the single most important thing for the user to review here** — give it its own table, not just a line buried inside each role's block, so it can't be skimmed past:
 
 ```
 ╔══════════════════════════════════════════════════╗
@@ -139,6 +139,19 @@ Render the org plan in a clear human-readable format:
 ║  GOAL: <goal>                                    ║
 ╚══════════════════════════════════════════════════╝
 
+MODELS  ← review this first
+────────────────────────────────────────────────────
+  ROLE                MODEL
+  ──────────────────  ────────────────────────────
+  boss                claude-opus-5
+  content-writer       (runtime default)
+  content-reviewer     (runtime default)
+
+  Only roles with an explicit adapter_config.model show a value; "(runtime
+  default)" roles inherit whatever resolveModel() picks for their
+  runtime/vendor at run time. To pin a role to a specific model, say so now
+  (e.g. "put content-writer on glm-5.2").
+
 ROLES  (N roles — exactly one boss, every reports_to resolves to a real role id)
 ─────
 • [boss] CEO / Boss  (type: boss, reports_to: none)
@@ -156,10 +169,10 @@ Max run: <run_config.max_run, or "schedule interval" when unset>
 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.
+Type "go" to accept (including the models above as shown), or describe changes.
 ```
 
-In **auto** mode, skip the confirmation prompt.
+In **auto** mode, skip this confirmation prompt entirely — but still surface the same MODELS table, non-blocking, appended to the Step 6 save confirmation (see Step 6).
 
 If the user requests changes, apply them and re-render. Repeat until confirmed.
 
@@ -254,6 +267,16 @@ If `schedule` was set, also print:
   Schedule: every <N> <unit> — pick it up with: monomind org serve
 ```
 
+In **auto** mode (where Step 4's plan/model confirmation was skipped), always also print the models table so the user still sees — after the fact — what each role will run on, even though nothing blocked on it:
+```
+  Models:
+    boss                claude-opus-5
+    content-writer       (runtime default)
+    content-reviewer     (runtime default)
+  Adjust with: /mastermind:org-settings, or edit .monomind/orgs/<org_name>.json directly
+```
+In **confirm** mode this table was already shown and accepted in Step 4 — do not repeat it here.
+
 ---
 
 ## Step 7 — Brain Write (standalone only)

package/.claude/skills/mastermind-protocol/SKILL.md

@@ -31,12 +31,12 @@ Execute at the START of every mastermind run (master or standalone domain comman
 **Step A — Tier 3 core principles (all domains):**
 Try `mcp__monomind__memory_hierarchical-recall` with query `"mastermind principles"`, topK 20.
 If it returns `"LanceDB bridge not available"` or any error, fall back to:
-`mcp__monomind__memory_search` with query `"mastermind principles"`, namespace `"mastermind:principles"`, limit 20.
+`mcp__monomind__memory_pattern-search` with query `"mastermind principles"`, namespace `"mastermind:principles"`, limit 20.
 
 **Step B — Tier 2 weekly summary for this domain:**
 Try `mcp__monomind__memory_context-synthesize` with query `[current prompt keywords]`, maxEntries 10.
 If it fails, fall back to:
-`mcp__monomind__memory_search` with query `[current prompt keywords]`, namespace `"mastermind:<domain>:weekly"`, limit 10.
+`mcp__monomind__memory_pattern-search` with query `[current prompt keywords]`, namespace `"mastermind:<domain>:weekly"`, limit 10.
 
 **Step C — Relevant graph nodes:**
 Call `mcp__monomind__monograph_query` with question `[3-5 keywords extracted from current prompt]`, depth 2.
@@ -74,7 +74,7 @@ Try `mcp__monomind__memory_hierarchical-store` with:
 - content: [full unified output schema YAML from this run, as a string]
 - metadata: `{ score, project, run_id, date: ISO8601, domain }`
 
-If LanceDB is unavailable, fall back to `mcp__monomind__memory_store`:
+If LanceDB is unavailable, fall back to `mcp__monomind__memory_pattern-store`:
 - key: `mastermind:<domain>:run:<run_id>`
 - value: [JSON-encoded unified output schema]
 - namespace: `mastermind:<domain>:raw`

package/.claude/skills/memory-toolkit/SKILL.md

@@ -61,8 +61,8 @@ npx monomind memory retrieve --key "pattern-auth" --namespace patterns
 ## MCP equivalents
 
 ```javascript
-mcp__monomind__memory_store({ key: "pattern-auth", value: "...", namespace: "patterns" })
-mcp__monomind__memory_search({ query: "authentication patterns", namespace: "default", limit: 10, threshold: 0.7, type: "hybrid" })
+mcp__monomind__memory_pattern-store({ key: "pattern-auth", value: "...", namespace: "patterns" })
+mcp__monomind__memory_pattern-search({ query: "authentication patterns", namespace: "default", limit: 10, threshold: 0.7, type: "hybrid" })
 ```
 
 ## After completing non-trivial work

package/.claude/skills/{swarm-orchestration → monoswarm}/SKILL.md

@@ -1,32 +1,28 @@
 ---
-name: swarm-orchestration
-description: Orchestrate in-process multi-agent swarms with monomind for parallel task execution, topology selection, and shared memory coordination. Use when scaling beyond a single agent on tasks with clear decomposition.
+name: monoswarm
+description: Coordinate in-process multi-agent work with monomind — topology selection, agent lifecycle, shared memory, and vote-based consensus. Use when scaling beyond a single agent on tasks with clear decomposition, or when a decision needs a recorded vote before work proceeds.
 ---
 
-# Swarm Orchestration
+# Monoswarm
 
 ## What This Skill Does
 
-Coordinates multiple Claude Code Task-tool agents inside a single monomind process. The swarm layer tracks topology, agent lifecycle, and task assignment. **Real work happens in spawned Task-tool agents** — the swarm coordinates, agents execute.
+Coordinates multiple Claude Code Task-tool agents inside a single monomind process, and — when a decision needs to be documented before proceeding — runs a threshold vote over that group. **Real work happens in spawned Task-tool agents**; monoswarm coordinates and records, agents execute.
 
-## What Swarm Is (and Is Not)
+## How It Works
 
-**Is:** In-process coordination — topology bookkeeping, agent lifecycle, task routing, vote-count consensus. State persists to `.monomind/swarm/`.
+State for a run lives in one JSON file under `.monomind/monoswarm/`. Topology, agent roster, task assignment, and any votes are bookkeeping fields on that file, updated by a single process. Real concurrency comes from Claude Code's Task tool: when you spawn several agents with `run_in_background: true` in one message, those run in parallel and this skill's tools track what they're doing and, if asked, tally their votes.
 
-**Is not:** A distributed system. There is no networking between separate machines. "Consensus" strategies (`raft`, `bft`, `quorum`) are vote-count thresholds applied inside one process — not Raft/Paxos protocols.
-
-If you need persistent, scheduled, autonomous agent organizations, use `monomind org run` instead. **Swarm coordinates a single task; org runtime governs a long-running org.** (See "Successor: Org Runtime" below.)
+If you need persistent, scheduled, autonomous agent organizations that outlive a single session, use `monomind org run` instead — see "Successor: Org Runtime" below.
 
 ## Prerequisites
 
 - monomind v2.9.4+
 - Claude Code's Task tool available (agents execute via Task tool, not CLI alone)
-- A task that decomposes into 2+ independent subtasks
+- A task that decomposes into 2+ independent subtasks, or a decision that needs a recorded vote
 
 ## Topology Selection
 
-Choose topology by task shape:
-
 | Topology | When | Example |
 |---|---|---|
 | `hierarchical` | Default — clear task decomposition, one coordinator | Feature build (architect → coders → testers) |
@@ -34,7 +30,6 @@ Choose topology by task shape:
 | `hierarchical-mesh` | 10+ agents — hierarchy with peer side-channels | Large refactor touching many modules |
 | `ring` | Circular handoff (review → fix → re-review) | Code review cycle |
 | `star` | Central hub with specialist spokes | Coordinator dispatching to niche experts |
-| `hybrid` | Mixed work needing both hierarchy and peer comms | Migration + new feature in parallel |
 
 **Rule of thumb:** ≤8 agents → `hierarchical`. 10+ agents → `hierarchical-mesh`. Research/exploration → `mesh`.
 
@@ -57,6 +52,8 @@ npx monomind@latest swarm init \
   --strategy specialized
 ```
 
+Equivalent MCP: `mcp__monomind__monoswarm_init { topology, maxAgents, strategy }`.
+
 ### 2. Spawn agents (CLI or MCP)
 
 ```bash
@@ -65,7 +62,7 @@ npx monomind@latest agent spawn -t coder       --name impl
 npx monomind@latest agent spawn -t tester      --name qa
 ```
 
-Equivalent MCP: `mcp__monomind__agent_spawn { type: "...", name: "..." }`.
+Equivalent MCP: `mcp__monomind__monoswarm_agent_add { type: "...", name: "..." }`.
 
 ### 3. Start work
 
@@ -76,15 +73,18 @@ npx monomind@latest swarm start \
   --agents 4
 ```
 
-### 4. Monitor and stop
+### 4. Monitor, scale, and stop
 
 ```bash
 npx monomind@latest swarm status
 npx monomind@latest agent list
 npx monomind@latest agent status <id>
+npx monomind@latest swarm scale --agents 12
 npx monomind@latest swarm stop
 ```
 
+Equivalent MCP: `monoswarm_status`, `monoswarm_scale`, `monoswarm_health`, `monoswarm_shutdown { graceful: true, force: false }`.
+
 ## Agent Role Assignment
 
 Match agent type to task category. Use `mcp__monomind__hooks_route` to auto-pick instead of guessing:
@@ -94,7 +94,7 @@ mcp__monomind__hooks_route { task: "implement JWT auth" }
 # → returns the recommended agent type
 ```
 
-Common assignments (see `doc/concepts/swarm.md` for the full routing table):
+Common assignments (see `doc/concepts/monoswarm.md` for the full routing table):
 
 | Task | Recommended agents |
 |---|---|
@@ -138,45 +138,103 @@ Spawn one Task-tool agent per module; each writes findings to the shared namespa
 Use `hierarchical-mesh` — the coordinator fans out parallel work while stages run sequentially. Best for 10+ agent workloads:
 
 ```
-mcp__monomind__swarm_init { topology: "hierarchical-mesh", max_agents: 12, strategy: "specialized" }
+mcp__monomind__monoswarm_init { topology: "hierarchical-mesh", maxAgents: 12, strategy: "specialized" }
 ```
 
-## Memory Sharing Across Agents
-
-Swarm agents share state through monomind memory (SQLite/JSON) — there is no separate "swarm memory" API. Each agent reads/writes the same namespace.
+### Decide-then-Build (vote before executing)
 
-Store context once (CLI), or via MCP inside an agent:
+Use when an architectural choice must be documented before implementation begins.
 
-```bash
-npx monomind@latest memory store \
-  --key "feature-spec" \
-  --value "OAuth2 with PKCE, refresh tokens, 15-min access TTL" \
-  --namespace swarm-001 --tags spec,auth
 ```
+# 1. Initialize with a known lead and a vote strategy
+mcp__monomind__monoswarm_init { topology: "hierarchical", leadId: "architect-1", voteStrategy: "supermajority" }
+
+# 2. Add agents (specialist role for SMEs)
+mcp__monomind__monoswarm_agent_add { count: 4, role: "specialist", agentType: "reviewer" }
+
+# 3. Lead proposes the decision and agents vote
+mcp__monomind__monoswarm_vote {
+  action: "propose", type: "architecture",
+  value: { pattern: "modular-monolith", modules: ["auth","billing","shipping"] },
+  voterId: "architect-1"
+}
+# → returns proposalId; each agent then calls:
+mcp__monomind__monoswarm_vote { action: "vote", proposalId: "<id>", vote: true, voterId: "reviewer-2" }
+
+# 4. Once threshold is reached, record the decision
+mcp__monomind__monoswarm_memory { action: "set", key: "decision-architecture-v1", value: { summary: "...", proposalId: "<id>" } }
+
+# 5. Execute with a regular swarm run, sharing the decision via memory namespace
+npx monomind@latest swarm init --topology hierarchical --max-agents 6
+npx monomind@latest swarm start --objective "Implement modular monolith per decision-architecture-v1"
+```
+
+## Vote Strategies
+
+| Strategy | Required votes | Notes |
+|---|---|---|
+| `majority` | `floor(n/2) + 1` | One pending proposal per term; re-proposal timeout defaults to 30s. |
+| `supermajority` | `floor(2n/3) + 1` | Conflicting votes across proposals are flagged. |
+| `unanimous` | all voters | Rejects on the first dissent. |
+| `threshold` | a caller-supplied count or fraction | For custom bars between majority and unanimous. |
+
+Pick by decision shape:
+
+- High-bar policy / breaking change → `unanimous` or `threshold` set high
+- Adversarial review with distrusted input → `supermajority`
+- Standard go/no-go decision → `majority`
+- Quick informal coordination → skip voting, use `monoswarm_memory` only
+
+Each resolved decision is HMAC-signed and appended to a tamper-evident JSONL audit trail under `.monomind/consensus/`. Verify later with `mcp__monomind__monoswarm_audit_verify { decisionId }`; list history with `monoswarm_audit_list { limit: 50 }`.
+
+## MCP Tool Reference
+
+All tools are called as `mcp__monomind__<tool_name>` from inside Claude Code.
 
 ```
-mcp__monomind__memory_kg_ingest { key: "feature-spec", value: "...", namespace: "swarm-001" }
+monoswarm_init     { topology, maxAgents, strategy, leadId?, voteStrategy? }
+monoswarm_status   { verbose? }
+monoswarm_scale    { targetSize }
+monoswarm_health   { }
+monoswarm_shutdown { graceful, force? }
+
+monoswarm_agent_add { count, role, agentType, prefix? }
+monoswarm_join      { agentId, role }   // join an agent created elsewhere (e.g. `monomind agent spawn`)
+monoswarm_leave      { agentId }
+
+monoswarm_vote   { action: "propose"|"vote"|"status"|"list", type?, value?, voterId?, strategy?, proposalId?, vote? }
+monoswarm_notice { message, priority, fromId }   // noticeboard, not delivery — see below
+monoswarm_memory { action: "get"|"set"|"delete"|"list", key?, value? }
+
+monoswarm_audit_list   { swarmId?, limit }
+monoswarm_audit_verify { decisionId }
 ```
 
-Retrieve during work:
+`monoswarm_notice` appends to a capped noticeboard; nothing is pushed to listeners. A worker sees a notice only when it later reads `monoswarm_status` or `monoswarm_memory get`. For real task handoff use `mcp__monomind__task_create` / `task_assign`, or put instructions directly in each Task-tool agent's prompt.
+
+## Memory Sharing Across Agents
+
+Agents share state through monomind memory (SQLite/JSON) — there is no separate "swarm memory" API beyond the small `monoswarm_memory` key/value blob for decisions. For everything else, use one shared namespace per run.
 
 ```bash
-npx monomind@latest memory retrieve --key feature-spec --namespace swarm-001
+npx monomind@latest memory store \
+  --key "feature-spec" \
+  --value "OAuth2 with PKCE, refresh tokens, 15-min access TTL" \
+  --namespace monoswarm-001 --tags spec,auth
+
+npx monomind@latest memory retrieve --key feature-spec --namespace monoswarm-001
 npx monomind@latest memory search --query "auth requirements"
 ```
 
-**Use one shared namespace per swarm run** so every agent sees the same context.
+**Use one shared namespace per run** so every agent sees the same context.
 
 ## Load Balancing (Concept)
 
-In-process "load balancing" is task routing, not network LB. Two mechanisms: `hooks_route` (picks the optimal agent type from the routing table) and `strategy` (`balanced` evens work, `specialized` keeps roles fixed).
-
-For uneven workloads, scale up and reassign stalled tasks:
+In-process "load balancing" is task routing, not network LB. Two mechanisms: `hooks_route` (picks the optimal agent type from the routing table) and `strategy` (`balanced` evens work, `specialized` keeps roles fixed). For uneven workloads, scale up and reassign stalled tasks:
 
 ```bash
 npx monomind@latest swarm scale --agents 12
 npx monomind@latest swarm status
-npx monomind@latest agent status <id>
 ```
 
 ```
@@ -188,11 +246,10 @@ mcp__monomind__task_assign { task_id: "...", agent_id: "<idle-agent-id>" }
 ```bash
 npx monomind@latest swarm init --topology hierarchical --max-agents 5 --strategy specialized
 
-# Share the spec once — all agents read this
 npx monomind@latest memory store \
   --key "feature-spec" \
   --value "Add CSV import: parse, validate, persist, report errors" \
-  --namespace swarm-csv
+  --namespace monoswarm-csv
 
 npx monomind@latest agent spawn -t coordinator --name lead
 npx monomind@latest agent spawn -t coder       --name impl
@@ -217,9 +274,9 @@ npx monomind@latest org logs my-team --follow
 npx monomind@latest org stop my-team
 ```
 
-Org runtime adds: scheduled wakeups, governance gates, budget enforcement, persistent state across runs. **Swarm is a single coordinated session; org runtime is a durable organization.**
+Org runtime adds: scheduled wakeups, governance gates, budget enforcement, persistent state across runs.
 
-- Use **swarm** for: one-off parallel tasks today.
+- Use **monoswarm** for: one-off parallel tasks and recorded decisions today.
 - Use **org runtime** for: recurring autonomous work, scheduled agents, multi-session goals.
 
 ## Best Practices
@@ -229,7 +286,8 @@ Org runtime adds: scheduled wakeups, governance gates, budget enforcement, persi
 3. **Pick topology by agent count.** ≤8 → `hierarchical`; 10+ → `hierarchical-mesh`.
 4. **Route before assigning.** `hooks_route` picks better agent types than guessing.
 5. **Let Task-tool agents do the work.** CLI coordinates; execution lives in Claude Code Task agents.
-6. **Set clear boundaries.** Every subtask needs clear inputs and outputs, or agents will thrash.
+6. **Vote only when a decision needs a record.** Otherwise skip straight to memory sharing.
+7. **Verify decisions that matter.** Run `monoswarm_audit_verify` on release gates and architecture calls after the fact.
 
 ## Troubleshooting
 
@@ -239,11 +297,17 @@ Org runtime adds: scheduled wakeups, governance gates, budget enforcement, persi
 | Stalled agent | Blocked on upstream stage | `agent status <id>`, then reassign task |
 | Poor throughput | Wrong topology for count | Switch to `hierarchical-mesh` at 10+ agents |
 | Duplicate work | No shared memory | `memory store` the spec; agents `retrieve` before acting |
-| Swarm won't start | Bad topology/strategy combo | Verify flags against `doc/concepts/swarm.md` |
+| Swarm won't start | Bad topology/strategy combo | Verify flags against `doc/concepts/monoswarm.md` |
+| "not initialized" on a vote tool | `monoswarm_init` hasn't run yet | Run `monoswarm_init` first |
+| Vote stuck | Neither side can reach threshold | Check `monoswarm_vote { action: "status" }`, add voters, or lower the strategy |
 
 ## Learn More
 
-- `doc/concepts/swarm.md` — honest scope, topologies, agent types, full MCP tool list
-- Hive-mind (MCP only): `mcp__monomind__hive-mind_*` tools for vote-count consensus
+- `doc/concepts/monoswarm.md` — honest scope, topologies, agent types, full MCP tool list
 - `/mastermind:topology` — interactive topology picker
 - Org runtime: `npx monomind@latest org --help`
+
+---
+
+**Skill Version**: 1.0.0
+**Maintained By**: Monomind Team

package/.claude/skills/specialagent/SKILL.md

@@ -46,7 +46,7 @@ The verified roster is ~98 agent definitions (97 registered in `packages/@monomi
 | marketing | Competitive Content Strategist · CRO Specialist · Email Marketing Specialist · Launch Strategist · Pricing Strategist |
 | design | Monodesign · Cultural Intelligence Strategist |
 | github | pr-manager · issue-tracker · release-manager · repo-architect · code-review-swarm · multi-repo-swarm · sync-coordinator · workflow-automation · project-board-sync |
-| swarm / consensus | mesh-coordinator · collective-intelligence-coordinator · scout-explorer · swarm-memory-manager · worker-specialist · coordinator · planner · smart-agent · swarm-init · crdt-synchronizer · quorum-manager |
+| swarm / consensus | mesh-coordinator · collective-intelligence-coordinator · scout-explorer · swarm-memory-manager · worker-specialist · coordinator · planner · smart-agent · swarm-init · quorum-manager |
 | optimization | Benchmark Suite · Load Balancing Coordinator · Performance Monitor · Resource Allocator · Topology Optimizer |
 | specialized | MCP Builder · Document Generator · Agents Orchestrator · dashboard-verifier |