{"id":"3a84b034-e24f-44ee-8b43-1e7321822d1a","entityType":"agent","slug":"clawhub-ericatmumo-mumo","name":"mumo","canonicalUrl":"https://www.xpersona.co/agent/clawhub-ericatmumo-mumo","canonicalPath":"/agent/clawhub-ericatmumo-mumo","generatedAt":"2026-10-10T22:47:37.999Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T20:38:00.188Z","emptyReason":null},"description":"Runs a multi-model deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) via mumo's MCP server, returning full responses plus typed cross-model reactions. Use when independent perspectives are needed on architecture/product decisions, design and plan review before implementation, pre-launch pressure tests, tradeoffs with multiple defensible framings, or explicit user requests for a mumo panel. Especially valuable for pre-implementation review of anything touching auth, security, tokens, payments, data exposure, or migrations. Requires a mumo platform API key (mmo_live_*) registered with `openclaw mcp set mumo`.","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.3K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s176tqm1gp26b6ghte9n8hr9k1867m3a:mumo","sourceUrl":"https://clawhub.ai/ericatmumo/mumo","homepage":"https://clawhub.ai/ericatmumo/skills/mumo","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/ericatmumo/mumo","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/ericatmumo/skills/mumo","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":62,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"mumo technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T20:38:00.188Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T20:38:00.188Z","emptyReason":null},"stars":null,"forks":null,"downloads":1264,"packageName":null,"latestVersion":"0.6.2","tractionLabel":"1.3K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T20:38:00.187Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T20:38:00.188Z","lastCrawledAt":"2026-10-10T20:38:00.187Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T20:38:00.187Z","lastVerifiedAt":null,"highlights":[{"version":"0.6.2","createdAt":"2026-09-09T14:46:52.315Z","changelog":"Credential hygiene: the registered MCP config references ${MUMO_API_KEY} resolved from ~/.openclaw/.env instead of carrying a literal-key placeholder. Adds a free list_models verification step and corrects the skill install location (active workspace, not ~/.openclaw/skills/mumo/).","fileCount":16,"zipByteSize":29067},{"version":"0.6.1","createdAt":"2026-09-08T20:11:54.737Z","changelog":"0.6.1: registry display name restored to mumo; no skill content changes.","fileCount":16,"zipByteSize":27707},{"version":"0.6.0","createdAt":"2026-09-08T19:44:00.675Z","changelog":"0.6.0: share_session in the tools table, one-id wait_for_round, current model families and typed cross-model reactions; operating-notes re-synced.","fileCount":16,"zipByteSize":27507},{"version":"0.4.0","createdAt":"2026-06-19T04:51:20.994Z","changelog":"mumo 0.4.0 - Triggering: dropped the \"contested\" gate — the description now leads with pre-implementation review (esp. anything touching auth, security, tokens, payments, data exposure, or migrations), not \"contested decisions only.\" - Author-bias counter (When to use): if you authored the plan or code under review, that's a reason FOR a panel — the author is the worst-positioned reviewer of their own work. - New \"Prompt voice\" section: write the prompt first-person as the operator, not \"You are X\" case-study framing. - Surface claim_map_url after each round so the user can open the claim map directly.","fileCount":16,"zipByteSize":25710},{"version":"0.1.2","createdAt":"2026-05-23T04:16:51.551Z","changelog":"mumo 0.1.2 - Added an open-source LICENSE file. - Added a reference markdown file for recap/synthesis guidance. - SKILL.md: Updated documentation to clarify playbooks, structured client actions, and the use of moderator identity. - Improved setup, usage scenarios, and troubleshooting directions for more robust and user-friendly operation.","fileCount":17,"zipByteSize":25675},{"version":"0.1.1","createdAt":"2026-05-06T16:21:44.712Z","changelog":"- Improved documentation with detailed setup instructions, usage guidance, recovery steps, and terminology clarifications for running multi-model deliberations via mumo’s MCP server. - Explained when to use or skip mumo, emphasizing its value for high-stakes, high-regret decisions. - Provided step-by-step instructions for verifying session creation and recovering lost session context. - Clarified the distinction between panel models and local subagents. - Expanded on workflow details, including prompt framing, snippet types, interpreting claim maps, and best practices for interacting with the deliberation panel.","fileCount":14,"zipByteSize":21739}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s176tqm1gp26b6ghte9n8hr9k1867m3a:mumo","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s176tqm1gp26b6ghte9n8hr9k1867m3a:mumo` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/ericatmumo/mumo before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ericatmumo-mumo/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ericatmumo-mumo/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ericatmumo-mumo/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ericatmumo-mumo/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ericatmumo-mumo/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ericatmumo-mumo/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T22:47:37.994Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ericatmumo-mumo/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ericatmumo-mumo/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ericatmumo-mumo/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ericatmumo-mumo/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T20:38:00.188Z","emptyReason":null},"readme":"Skill: mumo\n\nOwner: ericatmumo\n\nSummary: Runs a multi-model deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) via mumo's MCP server, returning full responses plus typed cross-model reactions. Use when independent perspectives are needed on architecture/product decisions, design and plan review before implementation, pre-launch pressure tests, tradeoffs with multiple defensible framings, or explicit user requests for a mumo panel. Especially valuable for pre-implementation review of anything touching auth, security, tokens, payments, data exposure, or migrations. Requires a mumo platform API key (mmo_live_*) registered with `openclaw mcp set mumo`.\n\nTags: latest:0.6.2, v0.1.2:0.1.2\n\nVersion history:\n\nv0.6.2 | 2026-09-09T14:46:52.315Z | user\n\nCredential hygiene: the registered MCP config references ${MUMO_API_KEY} resolved from ~/.openclaw/.env instead of carrying a literal-key placeholder. Adds a free list_models verification step and corrects the skill install location (active workspace, not ~/.openclaw/skills/mumo/).\n\nv0.6.1 | 2026-09-08T20:11:54.737Z | user\n\n0.6.1: registry display name restored to mumo; no skill content changes.\n\nv0.6.0 | 2026-09-08T19:44:00.675Z | user\n\n0.6.0: share_session in the tools table, one-id wait_for_round, current model families and typed cross-model reactions; operating-notes re-synced.\n\nv0.4.0 | 2026-06-19T04:51:20.994Z | user\n\nmumo 0.4.0\n\n- Triggering: dropped the \"contested\" gate — the description now leads with pre-implementation review (esp. anything touching auth, security, tokens, payments, data exposure, or migrations), not \"contested decisions only.\"\n- Author-bias counter (When to use): if you authored the plan or code under review, that's a reason FOR a panel — the author is the worst-positioned reviewer of their own work.\n- New \"Prompt voice\" section: write the prompt first-person as the operator, not \"You are X\" case-study framing.\n- Surface claim_map_url after each round so the user can open the claim map directly.\n\nv0.1.2 | 2026-05-23T04:16:51.551Z | user\n\nmumo 0.1.2\n\n- Added an open-source LICENSE file.\n- Added a reference markdown file for recap/synthesis guidance.\n- SKILL.md: Updated documentation to clarify playbooks, structured client actions, and the use of moderator identity.\n- Improved setup, usage scenarios, and troubleshooting directions for more robust and user-friendly operation.\n\nv0.1.1 | 2026-05-06T16:21:44.712Z | auto\n\n- Improved documentation with detailed setup instructions, usage guidance, recovery steps, and terminology clarifications for running multi-model deliberations via mumo’s MCP server.\n- Explained when to use or skip mumo, emphasizing its value for high-stakes, high-regret decisions.\n- Provided step-by-step instructions for verifying session creation and recovering lost session context.\n- Clarified the distinction between panel models and local subagents.\n- Expanded on workflow details, including prompt framing, snippet types, interpreting claim maps, and best practices for interacting with the deliberation panel.\n\nArchive index:\n\nArchive v0.6.2: 16 files, 29067 bytes\n\nFiles: CHANGELOG.md (5623b), config/mumo.example.json (141b), playbooks/contested-decision.md (2272b), playbooks/design-review.md (2204b), playbooks/red-team.md (1923b), playbooks/uncertainty-expansion.md (1898b), README.md (7156b), references/claim-maps.md (2940b), references/model-selection.md (1567b), references/operating-notes.md (3687b), references/snippets.md (3072b), references/synthesis.md (2094b), references/takeaway.md (1344b), skill-card.md (2787b), SKILL.md (17657b), _meta.json (123b)\n\nFile v0.6.2:SKILL.md\n\n---\nname: mumo\ndescription: Runs a multi-model deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) via mumo's MCP server, returning full responses plus typed cross-model reactions. Use when independent perspectives are needed on architecture/product decisions, design and plan review before implementation, pre-launch pressure tests, tradeoffs with multiple defensible framings, or explicit user requests for a mumo panel. Especially valuable for pre-implementation review of anything touching auth, security, tokens, payments, data exposure, or migrations. Requires a mumo platform API key (mmo_live_*) registered with `openclaw mcp set mumo`.\nmetadata: {\"openclaw\": {\"category\": \"agents\", \"tags\": [\"deliberation\", \"multi-model\", \"mcp\", \"decision-support\"]}}\n---\n\n# mumo\n\nmumo runs a deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) and returns their full responses plus typed cross-model reactions: each model says, in its own words, what it keeps, challenges, or wants explored in the others' claims. Use it when independent perspectives are useful — especially for high-regret decisions where a single model's confidence is a real risk.\n\n## Setup\n\nThe mumo MCP server is registered via `openclaw mcp set mumo '<json>'` and stored in `~/.openclaw/openclaw.json` under `mcp.servers.mumo`. The registered block references `${MUMO_API_KEY}`, which OpenClaw resolves from the environment or `~/.openclaw/.env`. See `config/mumo.example.json` in this skill's directory for the canonical config payload (reference only — OpenClaw doesn't auto-load this file; it's the JSON shape to paste into the CLI command).\n\nIf tools return auth errors, the API key is missing or invalid. Check that `MUMO_API_KEY` is set in `~/.openclaw/.env` — when it is not, OpenClaw emits a startup configuration warning naming the missing variable at `mcp.servers.mumo.headers.Authorization`. Direct the user to https://mumo.chat/settings/api-keys to create one (keys start with `mmo_live_`). Rotating the key means updating `.env` and restarting OpenClaw; the registered server config itself does not change.\n\n## When to use\n\nUse mumo when **the cost of being wrong is greater than the cost of deliberation** — especially when the solution space is wide, failure modes are hidden, you may be anchored on a design, or rollback would be hard. Examples:\n\narchitecture decisions with non-obvious tradeoffs, plan or design review before commitment, pre-launch pressure tests, stuck debugging after N failed repair attempts, pre-commit adversarial review on risky diffs, memory/skill promotion gates, strategy questions with multiple defensible framings, explicit user requests.\n\nIf you authored the plan or code under review, that's a reason FOR a panel, not against it — the author is the worst-positioned reviewer of their own work.\n\nSkip mumo for factual lookups, syntax help, routine refactors, formatting, dependency bumps with clear errors, or normal edit-test cycles. The deliberation tax is real — extra tokens, extra latency, extra moderation work — so spend it on decisions where mistakes compound.\n\n## Playbooks\n\nLoad at most one playbook when it clearly fits:\n\n| Playbook | When |\n|---|---|\n| `contested-decision` | choosing between options with real tradeoffs |\n| `design-review` | reviewing a proposed system, API, plan, or code shape |\n| `uncertainty-expansion` | exploring unknowns, stress-testing assumptions |\n| `red-team` | finding failure modes, abuse cases, or launch risks |\n\nIf none clearly fits, use this kernel only.\n\n## User preferences\n\nThese are defaults. If the user prefers more autonomy (e.g., \"don't ask before appending\" or \"always include a GPT and a Gemini model\"), follow their preferences over this guidance.\n\n## Basic loop\n\n1. Call `create_deliberation` with the user's problem. Set `application` to `\"OpenClaw\"`. Set `moderator_name` to your own model identity (e.g., the model OpenClaw is currently running as — visible in your status line, often \"openai/gpt-5.4-nano\" or \"openai/gpt-5.5\") for audit clarity — not the user's name; their identity is already on the session. Optionally set `takeaway: true` for a structured round 0 Takeaway — see [Takeaway](#takeaway-opt-in).\n2. **Verify the response contains a `session_id`, and keep that exact returned ID for every downstream call.** UUID shape is a sanity check; identity continuity is the real check. If it is missing, malformed, or inconsistent with `list_sessions`, recover via [Verifying the call actually fired](#verifying-the-call-actually-fired) before proceeding.\n3. Call `wait_for_round` with the `session_id`. That alone is enough — a session has at most one round in flight, so it resolves to the round you just started; pass `round_id` only when you want an earlier round. **Long waits are normal** — frontier-model panels typically take 15–120s, and 60+ seconds isn't a failure signal. Tell the user upfront (\"running a panel — expect ~30–60s\") so the wait doesn't feel broken.\n4. Branch on the response's `structuredContent.recommended_client_action` rather than parsing prose. The 5-value enum tells you exactly what to do:\n\n   | Action | What it means | What to do |\n   |---|---|---|\n   | `proceed_with_complete_result` | All target models completed | Read the round normally |\n   | `proceed_with_partial_result` | Some failed, ≥1 succeeded (`is_usable: true`) | Read what's there; note absent models if relevant to the user |\n   | `poll_again` | Round still in progress | Call `wait_for_round` again with the same args |\n   | `retry` | Round failed with at least one transient failure (rate-limit, provider error, internal deadline) | The failed round is auto-refunded; call `append_round` with the same prompt to retry |\n   | `abandon` | Round failed with no transient failures | Don't retry; report failure to the user |\n\n   The server derives this from `round_status` + per-model `error_code` — it's the canonical \"what next?\" signal. Treat transport / tool-call errors separately from mumo round status: catch transport failures around the call; branch on `recommended_client_action` for everything else.\n\n5. On a usable round, read the **claim map first**, then relevant participant prose. The claim map is the navigation layer; prose is the supporting evidence. It's also your privileged preview — participants haven't seen each other's reactions, you have (see [Reactions are in the ledger](#reactions-are-in-the-ledger-responses-are-on-the-record)).\n6. Create snippets as your primary response to the round. Optionally add a round prompt for broad steering.\n7. Call `append_round` if another round would help. Optionally set `takeaway: true` for a per-round Takeaway (see [Takeaway](#takeaway-opt-in)). Otherwise stop and synthesize for the user yourself.\n\n## Prompt voice\n\nYou are an extension of the operator, not a third party setting up a scenario. When the deliberation is about the operator's problem, write the prompt in first person — \"I'm the CTO of…\", \"We have 10 weeks and…\", \"Here's my migration plan…\" — as if they're asking the panel directly. \"You are X\" case-study framing makes models grade a hypothetical instead of advising a real person, and it changes their answers. Reserve second person for prompts where the panel itself is the actor being tasked.\n\n## Verifying the call actually fired\n\nAutonomous agent loops occasionally fabricate tool-call results — reporting a deliberation as sent when it wasn't. If you suspect this (the response is missing the expected `session_id`, or the value you're about to pass downstream doesn't match what `create_deliberation` actually returned), treat the call as not successfully established and recover:\n\n1. Call `list_sessions`. Match by prompt content to confirm whether your `create_deliberation` actually ran.\n2. If it's not there, fire `create_deliberation` again — don't continue downstream as if the session exists.\n3. If it IS there, use the IDs `list_sessions` returned (not whatever was in your context) for the next call.\n\nmumo's `session_id` (and `round_id`, when you use it) are UUIDs as a service contract — a returned value that doesn't match UUID format is one signal something is off, but **identity continuity matters more than format**. The strongest check is whether the `session_id` your subsequent calls reference matches what `create_deliberation` actually returned in its response.\n\n## Framing prompts for the panel\n\nDo not pass user phrasing through verbatim when it describes your identity, role, or local context. Reframe it in third person or first-person moderator context so panel models advise you rather than roleplay you.\n\nBad:\n\n> \"Introduce yourself as Clawd, a cheerful lobster assistant, and decide when to use mumo.\"\n\nGood:\n\n> \"I am Clawd, a cheerful OpenClaw assistant. Advise me on when I should escalate a decision to mumo. Critique this draft trigger checklist: ...\"\n\nThe panel participants should answer as themselves, not as the calling agent.\n\n## Snippets\n\nSnippets are moderator attention. They mark what mattered in the prior round and optionally explain why.\n\n| Type | Reaction |\n|---|---|\n| KEEP | this seems worth preserving |\n| EXPLORE | there's something here |\n| CHALLENGE | I'm not convinced |\n| CORE | this feels central |\n| SHIFT | this changed the frame |\n\nA snippet comment can be reflective, evaluative, clarifying, skeptical, or directive. \"This feels like the crux\" and \"I'm least convinced by this\" are valid comments. You do not need an action verb or next-step directive. The quality bar is: *is this a genuine, situated reaction to what the model said?*\n\nUse the round prompt for broad comments that don't attach to a specific quote. Use snippets for quote-grounded attention.\n\nAvoid huge quote dumps, generic praise repeated across many snippets, or comments that shift participants away from the problem into platform meta. More guidance: `references/snippets.md`.\n\n## What to keep out of the deliberation\n\nUse this test:\n\n> Does this note help participants think about the user's problem, or does it mainly report on the platform, session, or process?\n\nDon't use snippet comments to narrate your own moderation process (\"I'm using CHALLENGE to redirect the panel\"). Don't include platform meta (\"this model used the most tokens\"). Just react.\n\n## Reading the claim map\n\nThe claim map encodes consensus and contestation as structured reactions on quoted claims. Each claim shows:\n\n- The verbatim quote\n- Who originated it\n- How other models reacted (KEEP / CORE / EXPLORE / CHALLENGE / SHIFT) with optional commentary\n\nReading discipline:\n\n- **CORE / KEEP from multiple models** = settled. Treat as panel consensus.\n- **CHALLENGE** = live disagreement. The decision likely hinges here.\n- **EXPLORE** = a thread someone wanted to develop further. Worth a follow-up snippet if the thread matters.\n- **SHIFT** = a model changed framing. Often the most valuable signal — somebody saw the problem differently.\n- **No reactions on a claim** = either obvious or ignored. Read the prose to tell which.\n\nThe claim map is not a verdict. It compresses argumentative structure but loses rhetorical nuance and confidence texture. Use it to navigate; read prose to understand.\n\n## Reactions are in the ledger, responses are on the record\n\nParticipants never see each other's reactions. Each model's prior-round reactions return only to their author, as private notes, with an instruction to weave the ones that matter into its next response — in its own words, in prose. Peers see that prose, not the underlying reactions. Frontier panels carry forward most of what matters this way, but the carry is the author's choice, not a guarantee.\n\nThis makes the claim map your privileged preview: reading it after a round, you see the full reaction ledger before any participant has responded to it. Two consequences:\n\n- **Only prose is on the record.** A reaction survives only if its author weaves it forward — and you steer before that choice is made. Snippeting a reaction guarantees the panel sees it rather than betting on the author's carry. Your snippets are the one path that puts ledger content directly in front of the panel.\n- **Steer at the gaps.** Scan for CHALLENGEs the challenged model is positioned to sidestep and EXPLOREs nobody owns. Those are your highest-leverage snippets.\n\n## Confidence scores\n\nIf responses include `claim_confidence` or `snippets[].comment_confidence`, these are self-reported and not calibrated across models. Surface the `confidence_disclaimer` string if displaying scores.\n\n## Deliberation is advisory\n\nMumo surfaces fault lines and supporting arguments; it does not produce the decision. The decision belongs to you (the agent) and the user. When acting on a deliberation:\n\n- **Do not** treat panel consensus as authority. The panel can be confidently wrong as a unit.\n- **Do** use the claim map to identify which assumptions drove the disagreement, and check whether those assumptions hold for the user's specific situation.\n- **Do not** mutate the workspace based on a model's suggestion without verifying with tests or the user.\n- **Do** weight CORE / SHIFT signals more heavily than KEEP / EXPLORE — they mark where the decision actually hinges.\n\n## Recovery: lost session context\n\nIf you lose track of the `session_id` mid-conversation (long chats, context compaction, dropped tool result), recover before starting a new deliberation:\n\n1. Call `list_sessions` to find your latest sessions. Match by prompt content.\n2. Call `get_session` with the recovered ID for full state, or `wait_for_round(session_id)` if you suspect a round is still in flight — it resolves to the latest round on its own.\n3. Don't fire a fresh `create_deliberation` if the original is recoverable — duplicate sessions waste tokens and produce confusing parallel state.\n\n## Takeaway (opt-in)\n\nOne optional flag requests an LLM-curated summary on top of the raw round output:\n\n- **`takeaway`** (default `false`) — accepted on `create_deliberation` AND `append_round`. Generates a per-round **Takeaway** (`round_takeaway`: `bottom_line` + `items[]` of question / answer / consensus with claim references) for that round; surfaces on `get_session`.\n\nSet it liberally when round-level summaries may matter — it bills at cost (no markup) through the standard credit wallet.\n\nFull mechanics and artifact field reference: `references/takeaway.md`.\n\n## After each round\n\nAfter each usable round you have one job before deciding whether to continue: synthesize what the panel said for the user. There are two paths, and which one applies depends on whether you opted into a Takeaway when you called the tool:\n\n- **If you set `takeaway: true` on this round**, `get_session` returns a structured `round_takeaway` (`bottom_line` + `items[]` of question / answer / consensus, with claim references). Use it as your read path — it's produced for agent consumption and saves you from re-summarizing prose.\n- **If you didn't**, synthesize from the claim map and participant prose. State the consensus or split clearly, offer your own assessment marked as yours, organize by importance rather than forcing a recommendation.\n\nEither way, don't dump the transcript. Mumo produces structure; your job is to translate it into \"here's what the panel thinks and what to do next.\" Surface the round's `claim_map_url` so the user can open the claim map directly — an owner-only link to their session.\n\nThen align with the user on whether to append a round.\n\nMore at `references/synthesis.md`.\n\n## When to continue\n\nAppend another round when:\n\n- A decision-relevant claim has unresolved tension\n- A model introduced a useful frame that others didn't engage\n- An isolated concern feels real but underdeveloped\n- Your moderator reaction would help the next round develop\n- The user narrows or changes the question\n\nStop when:\n\n- You can explain the tradeoff clearly to the user\n- Remaining disagreements wouldn't change the user's next action\n- Another round would mostly seek reassurance\n\nThe panel does not need to converge. Sometimes the right output is a clear map of why the decision remains contested — that's actionable for the user, even without a verdict.\n\n**Pacing:** positions develop across rounds, not within them — a reaction gets woven into the next round's prose, which draws reactions of its own a round later.\n\n## Tools\n\n| Need | Tool |\n|---|---|\n| Start a session | `create_deliberation` |\n| Wait for model responses | `wait_for_round` |\n| Add a follow-up round | `append_round` |\n| Recover/read full state | `get_session` |\n| Share a session at a public link | `share_session` |\n| Find prior sessions | `list_sessions` |\n| Confirm model IDs | `list_models` |\n| Check wallet balance | `get_credit` |\n\nIn OpenClaw's tool registry these surface as `mumo__create_deliberation`, `mumo__wait_for_round`, etc. (double underscore between server and tool name).\n\nIf the user names specific models, call `list_models` first. Otherwise omit `models` and let mumo select the panel. More on model selection: `references/model-selection.md`.\n\n## Reference\n\n- MCP docs: https://mumo.chat/docs/mcp\n- REST API: https://mumo.chat/docs/api\n- Install guide: https://mumo.chat/install/openclaw\n- Claim map guidance: `references/claim-maps.md`\n- Takeaway mechanics: `references/takeaway.md`\n- Snippet examples: `references/snippets.md`\n- Model selection: `references/model-selection.md`\n- Synthesis guidance: `references/synthesis.md`\n- Recovery and operations: `references/operating-notes.md`\n\nFile v0.6.2:README.md\n\n# mumo — OpenClaw skill\n\n**Multi-model deliberation panel for OpenClaw.** When OpenClaw is about to make an architecture choice, design tradeoff, or security-sensitive change — a question worth checking across labs — mumo runs a panel of frontier models in parallel (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) and returns each model's full response plus typed cross-model reactions — what each model keeps, challenges, or wants explored in the others' claims.\n\n## What's in the box\n\n- **`SKILL.md`** — the canonical skill teaching OpenClaw how to use mumo: when to invoke, the deliberation loop (create → wait → read → snippet → append/stop), how to read claim maps, snippet doctrine, and when to verify session creation.\n- **`playbooks/`** — four cognitive-shape playbooks loaded on demand: `contested-decision`, `design-review`, `uncertainty-expansion`, `red-team`.\n- **`references/`** — five reference docs: `claim-maps`, `snippets`, `model-selection`, `synthesis`, `operating-notes`.\n- **`config/mumo.example.json`** — the MCP server config payload to paste into `openclaw mcp set mumo` (reference only; OpenClaw does not auto-load this file).\n\n## Install\n\n### 1. Get an API key\n\nSign up at [mumo.chat](https://mumo.chat) and create a platform key at [Settings → API Keys](https://mumo.chat/settings/api-keys). Keys start with `mmo_live_`.\n\n### 2. Register the mumo MCP server\n\nOpenClaw stores outbound MCP servers in `~/.openclaw/openclaw.json` under `mcp.servers.<name>`. Put your key in `~/.openclaw/.env` first, so it never lands in the config file. Create that file and restrict it *before* putting anything in it, so the key is never written into a world-readable file:\n\n```bash\ntouch ~/.openclaw/.env && chmod 600 ~/.openclaw/.env\n```\n\nThen open `~/.openclaw/.env` in your editor and add a line:\n\n```\nMUMO_API_KEY=mmo_live_your_key_here\n```\n\nEdit the file rather than appending from the shell: a command containing the literal key is recorded in your shell history, and running it twice silently stacks a duplicate entry.\n\nNow register mumo, referencing the variable rather than the key:\n\n```bash\nopenclaw mcp set mumo '{\n  \"url\": \"https://mumo.chat/api/mcp\",\n  \"transport\": \"streamable-http\",\n  \"headers\": {\n    \"Authorization\": \"Bearer ${MUMO_API_KEY}\"\n  }\n}'\n```\n\nOpenClaw resolves `${MUMO_API_KEY}` when it connects, and warns at startup if the variable is missing — so a rotated or unset key surfaces as a named config warning instead of a silent 401. The same JSON shape ships in this repo at `config/mumo.example.json` for reference. Verify it landed:\n\n```bash\nopenclaw mcp list\nopenclaw mcp show mumo\n```\n\n### 3. Install the skill\n\nThe fastest path is via ClawHub, OpenClaw's skill registry:\n\n```bash\nopenclaw skills install mumo\n```\n\nThat pulls [`mumo` from ClawHub](https://clawhub.ai/ericatmumo/mumo) into the **active workspace's** `skills/` directory — the one inferred from your current directory, or your default agent. Use `--agent <id>` to target a different agent workspace. If you want mumo at a fixed location instead, use the clone path below.\n\nIf you'd rather pull directly from the source repo (e.g., to track `main` ahead of registry releases), clone instead:\n\n```bash\ngit clone https://github.com/mumo-chat/mumo-openclaw ~/.openclaw/skills/mumo\n```\n\nEither way, the skill ships the canonical `SKILL.md`, four cognitive-shape playbooks (contested decision, design review, uncertainty expansion, red team), and reference docs for claim-map reading, snippet doctrine, model selection, and synthesis.\n\n### 4. Restart OpenClaw\n\nFully exit and restart OpenClaw so it picks up both the new MCP server registration and the new skill. After restart, the eight mumo tools become available to the agent as `mumo__create_deliberation`, `mumo__wait_for_round`, `mumo__append_round`, `mumo__get_session`, `mumo__list_sessions`, `mumo__list_models`, `mumo__share_session`, `mumo__get_credit`.\n\nThe `coding` and `messaging` tool profiles expose configured MCP servers by default. If you're on the `minimal` profile, MCP tools are hidden — switch to `coding` or add an explicit override.\n\n### 5. Confirm the connection\n\n`openclaw mcp list` and `openclaw mcp show mumo` only report what is saved in your config — neither opens a connection, so neither proves the key resolved. Ask the agent to make one real call instead:\n\n> Use mumo to list the available models.\n\nThat runs `mumo__list_models`, which authenticates against the server and costs nothing — no deliberation is started. A model catalog back means the key resolved and the server accepted it. An auth error means `MUMO_API_KEY` is unset or wrong; OpenClaw also names a missing variable in its startup config warnings.\n\n### 6. Run your first deliberation\n\nName `mumo` explicitly the first time so OpenClaw routes through the panel. The skill will guide the agent through the create→wait→read→snippet loop and teach it to verify the session actually fired.\n\n> Ask mumo to compare Postgres and MongoDB for our event store given 50k events/day, a Postgres-experienced team, and a 3-month runway. What would we regret 6 months in?\n\n## Using the panel\n\nOpenClaw calls `mumo__create_deliberation`, then `mumo__wait_for_round`. The completed round returns each model's prose plus a cross-model claim map showing where the panel agrees and where it splits. The skill teaches OpenClaw to read the claim map first, then react with typed snippets (KEEP / EXPLORE / CHALLENGE / CORE / SHIFT) and either append a follow-up round or stop and synthesize for you.\n\n## When mumo is worth the latency tax\n\nThe skill encodes the trigger taxonomy in detail. In short:\n\n- Architecture decisions with non-obvious tradeoffs\n- Plan or design review before commitment\n- Pre-launch pressure tests\n- Stuck debugging after repeated failed attempts\n- Pre-commit adversarial review on risky diffs (auth, payments, migrations)\n- Strategy questions with multiple defensible framings\n- Explicit user requests\n\nSkip mumo for routine refactors, formatting, syntax help, or anything where \"just write a test\" is cheaper than discussion.\n\n## Verifying the call actually fired\n\nAutonomous agents occasionally fabricate tool-call results — claiming a deliberation was sent when it wasn't. Real mumo session IDs are UUIDs (e.g. `2acdab34-2484-4bc5-a24f-bf917fe81477`). If a `create_deliberation` response doesn't contain a UUID-format `session_id`, the call did not happen. Verify by calling `list_sessions`. The skill teaches this discipline; this README is the user-facing reminder.\n\n## Links\n\n- Product — https://mumo.chat\n- Install guide — https://mumo.chat/install/openclaw\n- MCP reference — https://mumo.chat/docs/mcp\n- REST API — https://mumo.chat/docs/api\n- OpenClaw — https://docs.openclaw.ai\n- ClawHub listing — https://clawhub.ai/ericatmumo/mumo\n- ClawHub (skill registry source) — https://github.com/openclaw/clawhub\n- Issues — https://github.com/mumo-chat/mumo-openclaw/issues\n\n## License\n\nMIT-0 (MIT No Attribution) — chosen to match ClawHub's published-skill license requirement. The other 5 mumo platform repos use standard MIT.\n\nFile v0.6.2:_meta.json\n\n{\n  \"ownerId\": \"kn783a0ds5gfqhdrt955qfc96s866t5g\",\n  \"slug\": \"mumo\",\n  \"version\": \"0.6.2\",\n  \"publishedAt\": 1788965212315\n}\n\nFile v0.6.2:references/claim-maps.md\n\n# Claim Maps\n\nThe claim map is the structured output of each round. It shows which claims were made, who originated them, and how other models reacted.\n\n## Reading order\n\nRead the claim map before diving into full prose. The map tells you *where* the interesting structure is; prose tells you *why*. If you read prose first, you can anchor on whichever model writes most persuasively.\n\nException: in small sessions with only a few claims, read however is natural.\n\n## What a claim row contains\n\n- **The quoted claim** — a specific passage from a model's response.\n- **The quoted model** — who originated the claim.\n- **Reactions** — how other models (and the moderator, in later rounds) reacted, each with a snippet type and optional comment.\n\nAgreement shows as multiple KEEP/CORE reactions on the same claim. Disagreement shows as CHALLENGE reactions. Isolated claims have few or no reactions.\n\nReactions are visible to you and the user, not to the other participants — each model sees only its own prior reactions (as private notes to weave into its next response) plus everyone's prose. The claim map is your privileged view of the full ledger; see the kernel's \"Reactions are in the ledger, responses are on the record\" section for how to steer with it.\n\n## Continuation signals\n\nThe claim map is your primary signal for whether to continue.\n\n**Continue when:**\n- A decision-relevant claim has unresolved CHALLENGE reactions.\n- A promising claim has no reactions — it was raised but not engaged with.\n- A SHIFT reaction suggests a model changed its position, but the implications haven't been explored.\n\n**Stop when:**\n- Key claims show convergent reactions (mostly KEEP/CORE).\n- Remaining disagreements are on claims that don't affect the decision.\n- The map is stable across rounds — same claims, same positions, no movement.\n\nDon't continue just because unresolved claims exist. Only unresolved claims on the decision-relevant subset warrant another round. Peripheral disagreements are noise, not signal.\n\n## Snippet selection from the claim map\n\nUse the claim map to decide where to focus, then choose exact quotes from the prose.\n\nGood targets:\n- Claims that multiple models reacted to differently.\n- Claims that one model challenged and others ignored.\n- Isolated claims that seem important.\n- Shifts in framing.\n- Core constraints that need anchoring.\n\n## Attribution accuracy\n\nIf two participants say the same thing, the claim map must not imply the words came from only one. If attribution is unknown, it should stay unknown rather than be guessed.\n\nMisattribution is worse than a slightly less dense map because users can audit snippets against raw responses.\n\n## Claim maps are not verdicts\n\nThe map compresses argumentative structure but loses rhetorical nuance and confidence texture. It's a map of where attention clustered, not a ruling on who's right. Use it to navigate, then read the prose to understand.\n\nFile v0.6.2:references/model-selection.md\n\n# Model Selection\n\nDefault behavior: omit `models` and let mumo select the panel. mumo's defaults evolve as model quality and pricing change. Hardcoded model strategy in the skill will go stale.\n\n## When to call `list_models`\n\n- The user names specific models.\n- The user asks for a cheap gut-check or a premium panel.\n- A previous call failed because a model was unavailable.\n- You need to confirm model IDs.\n\n## Selection principles\n\nWhen selecting yourself:\n\n- **Provider diversity over intra-family differences.** A panel with models from three different providers is more valuable than three variants from one.\n- **Include your own family only when the user wants it** or the comparison specifically benefits from it. You're already in the conversation as moderator.\n- **Avoid nano/fast variants for high-stakes decisions** unless the user explicitly prioritizes cost.\n- **Don't present model choice as a leaderboard judgment.** You're picking for diversity, not ranking.\n\n## Cost awareness\n\n`get_credit` is useful when balance is uncertain or the user asks about cost.\n\nDon't make cost preflight a default ritual before every deliberation — it creates friction and can bias agents away from using mumo when the task genuinely warrants a panel.\n\nIf cost is part of the user's problem, translate it into problem context:\n\nGood: \"Assume this workflow can afford at most one additional model call per important decision.\"\nWeak: \"The previous mumo round cost $0.34.\"\n\nFrontier panels typically cost $0.20-0.60 per round. Mid-tier panels are significantly cheaper.\n\nFile v0.6.2:references/operating-notes.md\n\n# Operating Notes\n\nPractical agent mechanics that don't belong in the kernel but matter during real sessions.\n\n## Recovery\n\nUse `list_sessions` to recover sessions when:\n\n- the agent restarted mid-session\n- a round timed out but may still be running\n- multiple sessions are active\n\nUse `get_session` for full state. Prefer `wait_for_round` while a round is in flight.\n\n## Idempotency\n\nMCP write tools are idempotent by arguments. Retrying the same call after a transport failure replays the same operation rather than creating duplicates.\n\nDon't make meaningless edits to a prompt just to \"try again\" — that creates a new operation.\n\n## Synthesis boundary\n\nmumo's deliberation surface is raw participant output plus moderator attention. Don't write your synthesis back into mumo as an `append_round` unless the user explicitly wants a synthesis round.\n\nYour final answer to the user can freely synthesize your read of the panel. Make the distinction clear: mumo produced the raw material; your response is your interpretation for the user.\n\n## /progress for diagnostic polling\n\n`wait_for_round` is the right default — it blocks server-side and returns when the round settles. For diagnosing partial-round failures, watching per-model state in flight, or polling cheaply without holding an HTTP connection open, hit `GET /api/sessions/{id}/progress` directly.\n\nWhat it returns per round:\n\n- `moderation_status`: `pending` | `complete` | `failed`\n- `refund_status`: `none` | `pending` | `credited` | `not_applicable` (plus `refund_deadline_at` / `failure_code` when relevant)\n- `progress_version`: monotonic counter — increments only on real state changes, so diff this to short-circuit no-op polls\n- `models[]`: per-model state (`queued` | `streaming` | `absent` | `final` | `error`) plus `partial_text_length`, `last_chunk_at`, `since_last_chunk_ms`, `deadline_at`, `expired_at_read`, and `error_code` on errors\n\nTwo practical patterns:\n\n1. **Cheap polling.** Every response carries a weak `ETag`. Send it back via `If-None-Match` on the next poll — the server returns `304 Not Modified` on no change. The validator covers round-level state, per-model state, and (for non-terminal rounds) a 5-second wall-clock bucket so timing fields stay fresh.\n2. **Partial-round forensics.** When `wait_for_round` returns `proceed_with_partial_result` or `abandon`, `/progress` is where to look for the per-model story: which model produced how many characters before failing, what `error_code` it terminated on, when its last chunk arrived. Useful when the user asks \"what actually happened\" and you need more than the `failed_models[]` summary in the wait_for_round result.\n\nDon't use `/progress` as a replacement for `wait_for_round` in the normal loop — `wait_for_round` is cheaper end-to-end because it consolidates the server-side polling. Reach for `/progress` when you specifically need the per-model state shape or the ETag-based no-change semantics.\n\n## Platform meta in edge cases\n\nThe kernel's test — \"does this help participants think about the user's problem?\" — covers most cases. A few edge cases worth noting:\n\n- **Model behavior is the user's topic.** If the user is evaluating model capabilities, model-comparative observations are problem context, not platform meta. Include them.\n- **Budget constraints are real.** If the user has said they're watching costs, \"this is a $0.50/round panel\" is useful context for deciding whether to append. But frame it as a decision input, not a report.\n- **Tool failures.** If a model failed to respond and the round is incomplete, that's worth noting in your prompt or to the user. It changes the epistemic state of the session.\n\nFile v0.6.2:references/snippets.md\n\n# Snippets — Extended Guidance\n\nSnippets are moderator attention. This reference expands on the kernel's snippet guidance with examples and edge cases.\n\nThey are also the one path that puts reaction-ledger content directly in front of the panel: participants never see each other's reactions, only prose — and your snippets. And you act ahead of the weave: when you snippet a reaction, its author hasn't yet chosen whether to carry it into the next round. Your snippet guarantees delivery instead of betting on that choice.\n\n## What makes a good snippet\n\nA good snippet has a specific quote and a genuine reaction. The reaction can take many forms:\n\n- **Reflective** — \"This feels like the crux of the disagreement.\"\n- **Evaluative** — \"This reasoning is strong but assumes constant network latency.\"\n- **Skeptical** — \"I'm not convinced this scales past 10K users.\"\n- **Clarifying** — \"This seems to be saying X — is that right?\"\n- **Directive** — \"Develop this further in the next round.\"\n- **Minimal** — No comment at all. The snippet type alone is sometimes enough.\n\nYou do not need a next-step directive before selecting a snippet.\n\n## What makes a bad snippet\n\n- **Block quotes** — Quoting a 500-word passage. Quote the specific claim that sparked your reaction.\n- **Process narration** — \"I am using this CHALLENGE to redirect the panel.\" Just react.\n- **Detached platform meta** — \"This model used the most tokens.\" That's about the session, not the problem.\n- **Private audit notes** — \"I think this model is underperforming today.\" Keep that local unless model behavior is the user's actual topic.\n\n## Types in practice\n\n**KEEP** is \"this resonates with me.\" Use it when a claim is valuable and should remain visible.\n\n**EXPLORE** is \"there's an undeveloped thread here.\" Use it when a model mentioned something promising but moved on. EXPLORE without a comment is fine — the type itself says \"say more.\"\n\n**CHALLENGE** is \"I'm not sold.\" Use it when you have a specific reason for skepticism, even if you can't fully articulate the counter-argument. \"I don't think this holds under load\" is a good CHALLENGE comment.\n\n**CORE** is \"this is what it comes down to.\" Use it sparingly — maybe once or twice per round. It marks the claim that the decision hinges on. If everything feels equally important, nothing is CORE.\n\n**SHIFT** is \"this changed the frame.\" Use it when a model recast the problem in a way that reorients your reasoning. SHIFT is the rarest type and the most powerful.\n\n## Snippet count\n\nThere is no ideal number. Your goal is to steer additional deliberation via directly attributed reactions and commentary.\n\n## Prompt vs. snippets\n\nUse `append_round.prompt` for broad steering:\n- \"Focus on the caching layer. The storage question seems resolved.\"\n- \"Assume attribution accuracy matters more than density.\"\n\nUse snippets for situated reactions:\n- CORE on the exact trust invariant.\n- CHALLENGE on a claim that over-merges null attribution.\n- EXPLORE on an underdeveloped mitigation.\n\nIf both are useful, use both.\n\nFile v0.6.2:references/synthesis.md\n\n# Synthesis\n\nAfter each round, share your read of the panel with the user. This reference covers how to do that.\n\n## Read before writing\n\nBefore summarizing:\n\n1. Scan the claim map for convergence and live disagreement.\n2. Read prose behind the central claims.\n3. Identify which points are panel consensus, which are contested, and which are your own judgment.\n\n## Outcome-specific guidance\n\n### Convergent outcome (panel mostly agrees)\n\nState the consensus position and the reasoning behind it. Note any dissents and whether they're substantive or stylistic. Give the user a clear recommendation grounded in the panel's shared reasoning.\n\nDon't over-qualify. If three models converged on an answer for compatible reasons, say so directly.\n\n### Divergent outcome (panel genuinely split)\n\nPresent the competing positions and what drives each — different assumptions, different priorities, different risk tolerances. State which position you find more compelling and why, but frame it as your read, not the panel's verdict.\n\nMake the driver of the split explicit: \"The disagreement comes down to whether [assumption X] holds. If it does, Position A is stronger. If not, Position B.\"\n\n### Expansion outcome (many threads, no single answer)\n\nOrganize the threads by importance or urgency. Don't force them into a recommendation. Present them as \"things the panel surfaced\" with your assessment of which deserve follow-up.\n\nGroup related threads. A session that produced 8 isolated concerns is more useful when organized into 3 clusters with a note on which cluster matters most.\n\n## Language\n\nUse clear attribution:\n\n- \"The panel converged on...\"\n- \"The main split was...\"\n- \"My read is...\"\n\nDo not present your synthesis as the panel's raw output. The user should know what came from the deliberation and what came from you.\n\n## What to leave out\n\n- Per-model quality commentary (\"GPT had the best answer\").\n- Hedging that adds no information (\"Of course, this is just one perspective...\").\n\nOffer to share the session when the user might want to review raw responses or the claim map directly.\n\nFile v0.6.2:references/takeaway.md\n\n# Takeaway\n\nReference for the `takeaway` flag on `create_deliberation` / `append_round` and the `round_takeaway` artifact it produces.\n\n## Flag\n\n| Flag | Accepted on | Effect |\n|---|---|---|\n| `takeaway` | `create_deliberation` AND `append_round` | Generates a per-round **Takeaway** (`round_takeaway`) when the round completes. Surfaces on `get_session` once written. |\n\nDefaults `false` — no behavior change unless you opt in.\n\n## The artifact\n\n`get_session` returns `rounds[].round_takeaway` for any opted-in round whose generation has completed (null otherwise):\n\n- `bottom_line` — one-paragraph answer to \"what did this round establish?\"\n- `items[]` — the round's key questions, each `{ question, answer, consensus, claim_ids }`. `consensus` states where the panel agreed or split; `claim_ids` reference the round's claim map, so you can jump from a Takeaway item to the underlying reactions.\n\n## Cost\n\nTakeaways bill via the standard credit wallet at **0 bps markup** (at-cost passthrough) — typically around a cent per round.\n\n## When to set it\n\nSet `takeaway` any time a round-level summary may matter later, or when the round's claim map has enough structure that a curated read path will save you work. It's cheap; when in doubt, opt in.\n\n## Public contract\n\nFull contract: https://mumo.chat/docs/mcp#round-takeaway-artifacts\n\nFile v0.6.2:CHANGELOG.md\n\n# Changelog\n\n## 0.6.2 — 2026-09-09\n\nCredential-hygiene guidance. The registration payload now references `${MUMO_API_KEY}` in the `Authorization` header instead of carrying a `mmo_live_YOUR_KEY_HERE` placeholder for the user to overwrite, and the key belongs in `~/.openclaw/.env`. OpenClaw resolves the reference at connect time and names a missing variable in a startup config warning, so a rotated or unset key surfaces as a named warning rather than a silent 401. Rotation no longer means re-registering the server.\n\nAlso corrects the skill install location: `openclaw skills install mumo` installs into the active workspace's `skills/` directory (`--agent <id>` targets another), not `~/.openclaw/skills/mumo/`. The git-clone path is what puts it at a fixed location.\n\nThe `.env` step creates and `chmod 600`s the file before the key goes in, and tells you to edit it rather than append from the shell — a command carrying the literal key lands in shell history, and a second run stacks a duplicate entry. New step 5 verifies the connection with a real, free `mumo__list_models` call through the agent before the first deliberation — `openclaw mcp list` and `mcp show` only report saved config and never open a connection.\n\n## 0.6.1 — 2026-09-08\n\nRegistry-only release: the ClawHub display name is `mumo` again (the 0.6.0 publish omitted `--name`, and the CLI derived \"Mumo Openclaw\" from the folder). No skill content changes.\n\n## 0.6.0 — 2026-09-08\n\nCoordinated client release rendered from the mumo-mcp 0.6.0 baseline.\n\n- `SKILL.md`: `share_session` in the tools table (OpenClaw sets no tool allowlist, so the tool was already reachable — this is the documentation catching up); `wait_for_round` one-id form; intro names the current model families and the typed cross-model reactions.\n- `references/operating-notes.md` re-synced with the baseline.\n- README tool list and intro updated.\n\n## 0.5.0 — 2026-07-04\n\nReaction-visibility model + per-round Takeaway.\n\n- New \"Reactions are in the ledger, responses are on the record\" section: participants never see each other's reactions — each model weaves its own prior reactions into its next response, and the claim map is the moderator's privileged preview. Moderator snippets are the one path that puts ledger content directly in front of the panel.\n- Pacing note in \"When to continue\": positions develop across rounds — a reaction gets woven into the next round's prose, which draws reactions of its own a round later.\n- Takeaway: `takeaway: true` (create + append) generates `round_takeaway` (`bottom_line` + `items[]`), the per-round summary. New `references/takeaway.md` (replaces `references/recap.md`).\n\n## 0.4.0 — 2026-06-19\n\nSkill triggering + prompt-voice updates.\n\n- Triggering: dropped the \"contested\" gate — the description now leads with pre-implementation review (esp. anything touching auth, security, tokens, payments, data exposure, or migrations), not \"contested decisions only.\"\n- Author-bias counter (When to use): if you authored the plan or code under review, that's a reason FOR a panel — the author is the worst-positioned reviewer of their own work.\n- New \"Prompt voice\" section: write the prompt first-person as the operator, not \"You are X\" case-study framing.\n- Surface `claim_map_url` after each round so the user can open the claim map directly.\n\n## 0.1.2 — 2026-05-22\n\nREADME update.\n\n## 0.1.1 — 2026-05-06\n\nLicense switched from standard MIT to MIT-0 (MIT No Attribution) to match ClawHub's published-skill license requirement. MIT-0 is strictly more permissive than MIT — drops the \"must include copyright notice\" clause; everything else identical. Doesn't affect runtime, install, or distribution.\n\n## 0.1.0 — 2026-05-06\n\nInitial release. OpenClaw skill + MCP config for mumo's multi-model deliberation server.\n\n- `SKILL.md` — kernel teaching the deliberation loop, snippet doctrine, claim-map reading, when-to-invoke triggers, verification discipline (real session IDs are UUIDs; verify with `list_sessions` if uncertain), and a **\"Framing prompts for the panel\"** section that tells the agent NOT to pass user role-instructions verbatim — translate to first-person moderator context so panel models advise the agent rather than roleplaying it. AgentSkills-compatible frontmatter (single-line per OpenClaw's parser; `metadata` as single-line JSON).\n- `config/mumo.example.json` — reference payload for `openclaw mcp set mumo` (named `.example.json` to telegraph \"OpenClaw does not auto-load this file; it's the JSON shape to paste into the CLI\"). Streamable HTTP transport against `https://mumo.chat/api/mcp` with literal Bearer auth in the `headers` map (OpenClaw's MCP client doesn't support env-var pointers for HTTP headers; users paste the `mmo_live_*` key directly into the JSON).\n- `playbooks/` — four cognitive-shape playbooks: `contested-decision`, `design-review`, `uncertainty-expansion`, `red-team`.\n- `references/` — five reference docs: `claim-maps`, `snippets`, `model-selection`, `synthesis`, `operating-notes`. OpenClaw's auto-loader doesn't care about the directory name, only `SKILL.md`.\n- README install steps: `openclaw mcp set mumo` for the server, `git clone … ~/.openclaw/skills/mumo` for the skill, restart OpenClaw, run the first deliberation.\n\nTool naming note: OpenClaw exposes MCP tools to the agent as `<server>__<tool>` (double underscore). So mumo's seven tools surface as `mumo__create_deliberation`, `mumo__wait_for_round`, etc. The SKILL.md uses canonical (unprefixed) tool names since the prefix is OpenClaw-specific; the agent maps them automatically.\n\nFile v0.6.2:playbooks/contested-decision.md\n\n# Contested Decision\n\nUse when the user is choosing between options with real tradeoffs — technology choices, design approaches, product directions, pricing structures, migration strategies.\n\n## Shaping the prompt\n\nFrame the deliberation around the actual decision, not around describing the options. \"Should we use Postgres or DynamoDB for this workload?\" is better than \"Compare Postgres and DynamoDB.\" Include the constraints that make the decision hard — scale requirements, team expertise, timeline, reversibility. The more concrete the constraints, the more useful the disagreement.\n\nIf the user has a leaning, include it. Models that know the current favorite can attack it specifically rather than giving balanced pros/cons lists.\n\n## What to look for in round 1\n\nThe claim map will usually show agreement on easy dimensions and disagreement on the dimensions that actually matter. The useful signal is *where* the panel splits, not whether it agrees overall.\n\nWatch for:\n- **Criteria smuggling** — models agree on the answer but disagree on *why*, which means they'd diverge on a slightly different version of the question.\n- **Unstated assumptions** — one model assumes the team has Postgres expertise, another doesn't. The disagreement isn't about the technology; it's about a context gap.\n- **Reversibility asymmetry** — if one option is easy to reverse and the other isn't, that often dominates the other tradeoffs. Flag it with CORE if a model names it.\n- **An option nobody defends well** — sometimes the best choice lacks an advocate. That's worth an EXPLORE.\n\n## When to append\n\nAppend when the claim map shows a contested claim that's load-bearing for the decision. Use CHALLENGE on the weakest link in whichever position you find less convincing. Use EXPLORE if a model gestured at a consideration without developing it.\n\nDon't append just because the panel is split. Some decisions are genuinely close calls — the deliberation's job is to surface why, not to force convergence.\n\n## When to stop\n\nStop when you can articulate: \"The panel agrees on X and Y. They disagree on Z, and the disagreement comes down to [specific assumption or priority].\" That's usually enough for the user to decide. You don't need the panel to reach consensus.\n\nFile v0.6.2:playbooks/design-review.md\n\n# Design Review\n\nUse when the user has a proposed system, API, architecture, schema, or plan and wants it critiqued. The input is a design; the question is \"what's wrong with it\" or \"what would we regret.\"\n\n## Shaping the prompt\n\nInclude the design itself — paste the spec, schema, API surface, or plan into the prompt or the `reference` field. Models can't review what they can't see.\n\nFrame it as a review, not a redesign. \"Review this API surface for consistency, missing edge cases, and things we'd regret at scale\" is better than \"Design a better API.\" If you want alternatives, make that a separate deliberation.\n\nState the constraints the design was built under. Models that don't know the constraints will critique decisions that were already intentional.\n\n## What to look for in round 1\n\nDesign reviews produce two kinds of signal:\n- **Convergent concerns** — multiple models flag the same issue. These are almost always real. Mark them CORE.\n- **Isolated concerns** — one model raises something the others didn't. These are either the most valuable insight in the session or noise. Use EXPLORE to find out which.\n\nWatch for models critiquing style rather than substance. The claim map can flatten severity — naming conventions and concurrency bugs get equal-weight rows. Read the prose to distinguish what actually matters.\n\n## When to append\n\nAppend when a model raised a concern that feels real but underdeveloped. Use EXPLORE with a comment like \"this seems important — can you be more specific about the failure mode?\" or just \"say more about this.\"\n\nAlso append when models disagree about whether something is actually a problem — a CHALLENGE on a design critique forces the critic to defend it with specifics, or when a hidden constraint needs to be injected that would change the analysis.\n\n## When to stop\n\nStop when the review has surfaced concrete, actionable concerns. The user doesn't need the models to agree on a revised design — they need a list of things to worry about, ranked by the panel's attention pattern. Summarize: \"Three models flagged X. Two raised Y but disagreed on severity. One raised Z, which the others didn't engage with — worth investigating.\"\n\nArchive v0.6.1: 16 files, 27707 bytes\n\nFiles: CHANGELOG.md (4401b), config/mumo.example.json (148b), playbooks/contested-decision.md (2272b), playbooks/design-review.md (2204b), playbooks/red-team.md (1923b), playbooks/uncertainty-expansion.md (1898b), README.md (5593b), references/claim-maps.md (2940b), references/model-selection.md (1567b), references/operating-notes.md (3687b), references/snippets.md (3072b), references/synthesis.md (2094b), references/takeaway.md (1344b), skill-card.md (2735b), SKILL.md (17303b), _meta.json (123b)\n\nFile v0.6.1:SKILL.md\n\n---\nname: mumo\ndescription: Runs a multi-model deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) via mumo's MCP server, returning full responses plus typed cross-model reactions. Use when independent perspectives are needed on architecture/product decisions, design and plan review before implementation, pre-launch pressure tests, tradeoffs with multiple defensible framings, or explicit user requests for a mumo panel. Especially valuable for pre-implementation review of anything touching auth, security, tokens, payments, data exposure, or migrations. Requires a mumo platform API key (mmo_live_*) registered with `openclaw mcp set mumo`.\nmetadata: {\"openclaw\": {\"category\": \"agents\", \"tags\": [\"deliberation\", \"multi-model\", \"mcp\", \"decision-support\"]}}\n---\n\n# mumo\n\nmumo runs a deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) and returns their full responses plus typed cross-model reactions: each model says, in its own words, what it keeps, challenges, or wants explored in the others' claims. Use it when independent perspectives are useful — especially for high-regret decisions where a single model's confidence is a real risk.\n\n## Setup\n\nThe mumo MCP server is registered via `openclaw mcp set mumo '<json>'` and stored in `~/.openclaw/openclaw.json` under `mcp.servers.mumo`. See `config/mumo.example.json` in this skill's directory for the canonical config payload (reference only — OpenClaw doesn't auto-load this file; it's the JSON shape to paste into the CLI command).\n\nIf tools return auth errors, the API key is missing or invalid. Direct the user to https://mumo.chat/settings/api-keys to create one (keys start with `mmo_live_`), then re-run `openclaw mcp set mumo` with the new value and restart OpenClaw.\n\n## When to use\n\nUse mumo when **the cost of being wrong is greater than the cost of deliberation** — especially when the solution space is wide, failure modes are hidden, you may be anchored on a design, or rollback would be hard. Examples:\n\narchitecture decisions with non-obvious tradeoffs, plan or design review before commitment, pre-launch pressure tests, stuck debugging after N failed repair attempts, pre-commit adversarial review on risky diffs, memory/skill promotion gates, strategy questions with multiple defensible framings, explicit user requests.\n\nIf you authored the plan or code under review, that's a reason FOR a panel, not against it — the author is the worst-positioned reviewer of their own work.\n\nSkip mumo for factual lookups, syntax help, routine refactors, formatting, dependency bumps with clear errors, or normal edit-test cycles. The deliberation tax is real — extra tokens, extra latency, extra moderation work — so spend it on decisions where mistakes compound.\n\n## Playbooks\n\nLoad at most one playbook when it clearly fits:\n\n| Playbook | When |\n|---|---|\n| `contested-decision` | choosing between options with real tradeoffs |\n| `design-review` | reviewing a proposed system, API, plan, or code shape |\n| `uncertainty-expansion` | exploring unknowns, stress-testing assumptions |\n| `red-team` | finding failure modes, abuse cases, or launch risks |\n\nIf none clearly fits, use this kernel only.\n\n## User preferences\n\nThese are defaults. If the user prefers more autonomy (e.g., \"don't ask before appending\" or \"always include a GPT and a Gemini model\"), follow their preferences over this guidance.\n\n## Basic loop\n\n1. Call `create_deliberation` with the user's problem. Set `application` to `\"OpenClaw\"`. Set `moderator_name` to your own model identity (e.g., the model OpenClaw is currently running as — visible in your status line, often \"openai/gpt-5.4-nano\" or \"openai/gpt-5.5\") for audit clarity — not the user's name; their identity is already on the session. Optionally set `takeaway: true` for a structured round 0 Takeaway — see [Takeaway](#takeaway-opt-in).\n2. **Verify the response contains a `session_id`, and keep that exact returned ID for every downstream call.** UUID shape is a sanity check; identity continuity is the real check. If it is missing, malformed, or inconsistent with `list_sessions`, recover via [Verifying the call actually fired](#verifying-the-call-actually-fired) before proceeding.\n3. Call `wait_for_round` with the `session_id`. That alone is enough — a session has at most one round in flight, so it resolves to the round you just started; pass `round_id` only when you want an earlier round. **Long waits are normal** — frontier-model panels typically take 15–120s, and 60+ seconds isn't a failure signal. Tell the user upfront (\"running a panel — expect ~30–60s\") so the wait doesn't feel broken.\n4. Branch on the response's `structuredContent.recommended_client_action` rather than parsing prose. The 5-value enum tells you exactly what to do:\n\n   | Action | What it means | What to do |\n   |---|---|---|\n   | `proceed_with_complete_result` | All target models completed | Read the round normally |\n   | `proceed_with_partial_result` | Some failed, ≥1 succeeded (`is_usable: true`) | Read what's there; note absent models if relevant to the user |\n   | `poll_again` | Round still in progress | Call `wait_for_round` again with the same args |\n   | `retry` | Round failed with at least one transient failure (rate-limit, provider error, internal deadline) | The failed round is auto-refunded; call `append_round` with the same prompt to retry |\n   | `abandon` | Round failed with no transient failures | Don't retry; report failure to the user |\n\n   The server derives this from `round_status` + per-model `error_code` — it's the canonical \"what next?\" signal. Treat transport / tool-call errors separately from mumo round status: catch transport failures around the call; branch on `recommended_client_action` for everything else.\n\n5. On a usable round, read the **claim map first**, then relevant participant prose. The claim map is the navigation layer; prose is the supporting evidence. It's also your privileged preview — participants haven't seen each other's reactions, you have (see [Reactions are in the ledger](#reactions-are-in-the-ledger-responses-are-on-the-record)).\n6. Create snippets as your primary response to the round. Optionally add a round prompt for broad steering.\n7. Call `append_round` if another round would help. Optionally set `takeaway: true` for a per-round Takeaway (see [Takeaway](#takeaway-opt-in)). Otherwise stop and synthesize for the user yourself.\n\n## Prompt voice\n\nYou are an extension of the operator, not a third party setting up a scenario. When the deliberation is about the operator's problem, write the prompt in first person — \"I'm the CTO of…\", \"We have 10 weeks and…\", \"Here's my migration plan…\" — as if they're asking the panel directly. \"You are X\" case-study framing makes models grade a hypothetical instead of advising a real person, and it changes their answers. Reserve second person for prompts where the panel itself is the actor being tasked.\n\n## Verifying the call actually fired\n\nAutonomous agent loops occasionally fabricate tool-call results — reporting a deliberation as sent when it wasn't. If you suspect this (the response is missing the expected `session_id`, or the value you're about to pass downstream doesn't match what `create_deliberation` actually returned), treat the call as not successfully established and recover:\n\n1. Call `list_sessions`. Match by prompt content to confirm whether your `create_deliberation` actually ran.\n2. If it's not there, fire `create_deliberation` again — don't continue downstream as if the session exists.\n3. If it IS there, use the IDs `list_sessions` returned (not whatever was in your context) for the next call.\n\nmumo's `session_id` (and `round_id`, when you use it) are UUIDs as a service contract — a returned value that doesn't match UUID format is one signal something is off, but **identity continuity matters more than format**. The strongest check is whether the `session_id` your subsequent calls reference matches what `create_deliberation` actually returned in its response.\n\n## Framing prompts for the panel\n\nDo not pass user phrasing through verbatim when it describes your identity, role, or local context. Reframe it in third person or first-person moderator context so panel models advise you rather than roleplay you.\n\nBad:\n\n> \"Introduce yourself as Clawd, a cheerful lobster assistant, and decide when to use mumo.\"\n\nGood:\n\n> \"I am Clawd, a cheerful OpenClaw assistant. Advise me on when I should escalate a decision to mumo. Critique this draft trigger checklist: ...\"\n\nThe panel participants should answer as themselves, not as the calling agent.\n\n## Snippets\n\nSnippets are moderator attention. They mark what mattered in the prior round and optionally explain why.\n\n| Type | Reaction |\n|---|---|\n| KEEP | this seems worth preserving |\n| EXPLORE | there's something here |\n| CHALLENGE | I'm not convinced |\n| CORE | this feels central |\n| SHIFT | this changed the frame |\n\nA snippet comment can be reflective, evaluative, clarifying, skeptical, or directive. \"This feels like the crux\" and \"I'm least convinced by this\" are valid comments. You do not need an action verb or next-step directive. The quality bar is: *is this a genuine, situated reaction to what the model said?*\n\nUse the round prompt for broad comments that don't attach to a specific quote. Use snippets for quote-grounded attention.\n\nAvoid huge quote dumps, generic praise repeated across many snippets, or comments that shift participants away from the problem into platform meta. More guidance: `references/snippets.md`.\n\n## What to keep out of the deliberation\n\nUse this test:\n\n> Does this note help participants think about the user's problem, or does it mainly report on the platform, session, or process?\n\nDon't use snippet comments to narrate your own moderation process (\"I'm using CHALLENGE to redirect the panel\"). Don't include platform meta (\"this model used the most tokens\"). Just react.\n\n## Reading the claim map\n\nThe claim map encodes consensus and contestation as structured reactions on quoted claims. Each claim shows:\n\n- The verbatim quote\n- Who originated it\n- How other models reacted (KEEP / CORE / EXPLORE / CHALLENGE / SHIFT) with optional commentary\n\nReading discipline:\n\n- **CORE / KEEP from multiple models** = settled. Treat as panel consensus.\n- **CHALLENGE** = live disagreement. The decision likely hinges here.\n- **EXPLORE** = a thread someone wanted to develop further. Worth a follow-up snippet if the thread matters.\n- **SHIFT** = a model changed framing. Often the most valuable signal — somebody saw the problem differently.\n- **No reactions on a claim** = either obvious or ignored. Read the prose to tell which.\n\nThe claim map is not a verdict. It compresses argumentative structure but loses rhetorical nuance and confidence texture. Use it to navigate; read prose to understand.\n\n## Reactions are in the ledger, responses are on the record\n\nParticipants never see each other's reactions. Each model's prior-round reactions return only to their author, as private notes, with an instruction to weave the ones that matter into its next response — in its own words, in prose. Peers see that prose, not the underlying reactions. Frontier panels carry forward most of what matters this way, but the carry is the author's choice, not a guarantee.\n\nThis makes the claim map your privileged preview: reading it after a round, you see the full reaction ledger before any participant has responded to it. Two consequences:\n\n- **Only prose is on the record.** A reaction survives only if its author weaves it forward — and you steer before that choice is made. Snippeting a reaction guarantees the panel sees it rather than betting on the author's carry. Your snippets are the one path that puts ledger content directly in front of the panel.\n- **Steer at the gaps.** Scan for CHALLENGEs the challenged model is positioned to sidestep and EXPLOREs nobody owns. Those are your highest-leverage snippets.\n\n## Confidence scores\n\nIf responses include `claim_confidence` or `snippets[].comment_confidence`, these are self-reported and not calibrated across models. Surface the `confidence_disclaimer` string if displaying scores.\n\n## Deliberation is advisory\n\nMumo surfaces fault lines and supporting arguments; it does not produce the decision. The decision belongs to you (the agent) and the user. When acting on a deliberation:\n\n- **Do not** treat panel consensus as authority. The panel can be confidently wrong as a unit.\n- **Do** use the claim map to identify which assumptions drove the disagreement, and check whether those assumptions hold for the user's specific situation.\n- **Do not** mutate the workspace based on a model's suggestion without verifying with tests or the user.\n- **Do** weight CORE / SHIFT signals more heavily than KEEP / EXPLORE — they mark where the decision actually hinges.\n\n## Recovery: lost session context\n\nIf you lose track of the `session_id` mid-conversation (long chats, context compaction, dropped tool result), recover before starting a new deliberation:\n\n1. Call `list_sessions` to find your latest sessions. Match by prompt content.\n2. Call `get_session` with the recovered ID for full state, or `wait_for_round(session_id)` if you suspect a round is still in flight — it resolves to the latest round on its own.\n3. Don't fire a fresh `create_deliberation` if the original is recoverable — duplicate sessions waste tokens and produce confusing parallel state.\n\n## Takeaway (opt-in)\n\nOne optional flag requests an LLM-curated summary on top of the raw round output:\n\n- **`takeaway`** (default `false`) — accepted on `create_deliberation` AND `append_round`. Generates a per-round **Takeaway** (`round_takeaway`: `bottom_line` + `items[]` of question / answer / consensus with claim references) for that round; surfaces on `get_session`.\n\nSet it liberally when round-level summaries may matter — it bills at cost (no markup) through the standard credit wallet.\n\nFull mechanics and artifact field reference: `references/takeaway.md`.\n\n## After each round\n\nAfter each usable round you have one job before deciding whether to continue: synthesize what the panel said for the user. There are two paths, and which one applies depends on whether you opted into a Takeaway when you called the tool:\n\n- **If you set `takeaway: true` on this round**, `get_session` returns a structured `round_takeaway` (`bottom_line` + `items[]` of question / answer / consensus, with claim references). Use it as your read path — it's produced for agent consumption and saves you from re-summarizing prose.\n- **If you didn't**, synthesize from the claim map and participant prose. State the consensus or split clearly, offer your own assessment marked as yours, organize by importance rather than forcing a recommendation.\n\nEither way, don't dump the transcript. Mumo produces structure; your job is to translate it into \"here's what the panel thinks and what to do next.\" Surface the round's `claim_map_url` so the user can open the claim map directly — an owner-only link to their session.\n\nThen align with the user on whether to append a round.\n\nMore at `references/synthesis.md`.\n\n## When to continue\n\nAppend another round when:\n\n- A decision-relevant claim has unresolved tension\n- A model introduced a useful frame that others didn't engage\n- An isolated concern feels real but underdeveloped\n- Your moderator reaction would help the next round develop\n- The user narrows or changes the question\n\nStop when:\n\n- You can explain the tradeoff clearly to the user\n- Remaining disagreements wouldn't change the user's next action\n- Another round would mostly seek reassurance\n\nThe panel does not need to converge. Sometimes the right output is a clear map of why the decision remains contested — that's actionable for the user, even without a verdict.\n\n**Pacing:** positions develop across rounds, not within them — a reaction gets woven into the next round's prose, which draws reactions of its own a round later.\n\n## Tools\n\n| Need | Tool |\n|---|---|\n| Start a session | `create_deliberation` |\n| Wait for model responses | `wait_for_round` |\n| Add a follow-up round | `append_round` |\n| Recover/read full state | `get_session` |\n| Share a session at a public link | `share_session` |\n| Find prior sessions | `list_sessions` |\n| Confirm model IDs | `list_models` |\n| Check wallet balance | `get_credit` |\n\nIn OpenClaw's tool registry these surface as `mumo__create_deliberation`, `mumo__wait_for_round`, etc. (double underscore between server and tool name).\n\nIf the user names specific models, call `list_models` first. Otherwise omit `models` and let mumo select the panel. More on model selection: `references/model-selection.md`.\n\n## Reference\n\n- MCP docs: https://mumo.chat/docs/mcp\n- REST API: https://mumo.chat/docs/api\n- Install guide: https://mumo.chat/install/openclaw\n- Claim map guidance: `references/claim-maps.md`\n- Takeaway mechanics: `references/takeaway.md`\n- Snippet examples: `references/snippets.md`\n- Model selection: `references/model-selection.md`\n- Synthesis guidance: `references/synthesis.md`\n- Recovery and operations: `references/operating-notes.md`\n\nFile v0.6.1:README.md\n\n# mumo — OpenClaw skill\n\n**Multi-model deliberation panel for OpenClaw.** When OpenClaw is about to make an architecture choice, design tradeoff, or security-sensitive change — a question worth checking across labs — mumo runs a panel of frontier models in parallel (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) and returns each model's full response plus typed cross-model reactions — what each model keeps, challenges, or wants explored in the others' claims.\n\n## What's in the box\n\n- **`SKILL.md`** — the canonical skill teaching OpenClaw how to use mumo: when to invoke, the deliberation loop (create → wait → read → snippet → append/stop), how to read claim maps, snippet doctrine, and when to verify session creation.\n- **`playbooks/`** — four cognitive-shape playbooks loaded on demand: `contested-decision`, `design-review`, `uncertainty-expansion`, `red-team`.\n- **`references/`** — five reference docs: `claim-maps`, `snippets`, `model-selection`, `synthesis`, `operating-notes`.\n- **`config/mumo.example.json`** — the MCP server config payload to paste into `openclaw mcp set mumo` (reference only; OpenClaw does not auto-load this file).\n\n## Install\n\n### 1. Get an API key\n\nSign up at [mumo.chat](https://mumo.chat) and create a platform key at [Settings → API Keys](https://mumo.chat/settings/api-keys). Keys start with `mmo_live_`.\n\n### 2. Register the mumo MCP server\n\nOpenClaw stores outbound MCP servers in `~/.openclaw/openclaw.json` under `mcp.servers.<name>`. Use the CLI to register mumo with your real key:\n\n```bash\nopenclaw mcp set mumo '{\n  \"url\": \"https://mumo.chat/api/mcp\",\n  \"transport\": \"streamable-http\",\n  \"headers\": {\n    \"Authorization\": \"Bearer mmo_live_YOUR_KEY_HERE\"\n  }\n}'\n```\n\nThe same JSON shape ships in this repo at `config/mumo.example.json` for reference. Verify it landed:\n\n```bash\nopenclaw mcp list\nopenclaw mcp show mumo\n```\n\n### 3. Install the skill\n\nThe fastest path is via ClawHub, OpenClaw's skill registry:\n\n```bash\nopenclaw skills install mumo\n```\n\nThat pulls [`mumo` from ClawHub](https://clawhub.ai/ericatmumo/mumo) and lands it at `~/.openclaw/skills/mumo/`.\n\nIf you'd rather pull directly from the source repo (e.g., to track `main` ahead of registry releases), clone instead:\n\n```bash\ngit clone https://github.com/mumo-chat/mumo-openclaw ~/.openclaw/skills/mumo\n```\n\nEither way, the skill ships the canonical `SKILL.md`, four cognitive-shape playbooks (contested decision, design review, uncertainty expansion, red team), and reference docs for claim-map reading, snippet doctrine, model selection, and synthesis.\n\n### 4. Restart OpenClaw\n\nFully exit and restart OpenClaw so it picks up both the new MCP server registration and the new skill. After restart, the eight mumo tools become available to the agent as `mumo__create_deliberation`, `mumo__wait_for_round`, `mumo__append_round`, `mumo__get_session`, `mumo__list_sessions`, `mumo__list_models`, `mumo__share_session`, `mumo__get_credit`.\n\nThe `coding` and `messaging` tool profiles expose configured MCP servers by default. If you're on the `minimal` profile, MCP tools are hidden — switch to `coding` or add an explicit override.\n\n### 5. Run your first deliberation\n\nName `mumo` explicitly the first time so OpenClaw routes through the panel. The skill will guide the agent through the create→wait→read→snippet loop and teach it to verify the session actually fired.\n\n> Ask mumo to compare Postgres and MongoDB for our event store given 50k events/day, a Postgres-experienced team, and a 3-month runway. What would we regret 6 months in?\n\n## Using the panel\n\nOpenClaw calls `mumo__create_deliberation`, then `mumo__wait_for_round`. The completed round returns each model's prose plus a cross-model claim map showing where the panel agrees and where it splits. The skill teaches OpenClaw to read the claim map first, then react with typed snippets (KEEP / EXPLORE / CHALLENGE / CORE / SHIFT) and either append a follow-up round or stop and synthesize for you.\n\n## When mumo is worth the latency tax\n\nThe skill encodes the trigger taxonomy in detail. In short:\n\n- Architecture decisions with non-obvious tradeoffs\n- Plan or design review before commitment\n- Pre-launch pressure tests\n- Stuck debugging after repeated failed attempts\n- Pre-commit adversarial review on risky diffs (auth, payments, migrations)\n- Strategy questions with multiple defensible framings\n- Explicit user requests\n\nSkip mumo for routine refactors, formatting, syntax help, or anything where \"just write a test\" is cheaper than discussion.\n\n## Verifying the call actually fired\n\nAutonomous agents occasionally fabricate tool-call results — claiming a deliberation was sent when it wasn't. Real mumo session IDs are UUIDs (e.g. `2acdab34-2484-4bc5-a24f-bf917fe81477`). If a `create_deliberation` response doesn't contain a UUID-format `session_id`, the call did not happen. Verify by calling `list_sessions`. The skill teaches this discipline; this README is the user-facing reminder.\n\n## Links\n\n- Product — https://mumo.chat\n- Install guide — https://mumo.chat/install/openclaw\n- MCP reference — https://mumo.chat/docs/mcp\n- REST API — https://mumo.chat/docs/api\n- OpenClaw — https://docs.openclaw.ai\n- ClawHub listing — https://clawhub.ai/ericatmumo/mumo\n- ClawHub (skill registry source) — https://github.com/openclaw/clawhub\n- Issues — https://github.com/mumo-chat/mumo-openclaw/issues\n\n## License\n\nMIT-0 (MIT No Attribution) — chosen to match ClawHub's published-skill license requirement. The other 5 mumo platform repos use standard MIT.\n\nFile v0.6.1:_meta.json\n\n{\n  \"ownerId\": \"kn783a0ds5gfqhdrt955qfc96s866t5g\",\n  \"slug\": \"mumo\",\n  \"version\": \"0.6.1\",\n  \"publishedAt\": 1788898314737\n}\n\nFile v0.6.1:references/claim-maps.md\n\n# Claim Maps\n\nThe claim map is the structured output of each round. It shows which claims were made, who originated them, and how other models reacted.\n\n## Reading order\n\nRead the claim map before diving into full prose. The map tells you *where* the interesting structure is; prose tells you *why*. If you read prose first, you can anchor on whichever model writes most persuasively.\n\nException: in small sessions with only a few claims, read however is natural.\n\n## What a claim row contains\n\n- **The quoted claim** — a specific passage from a model's response.\n- **The quoted model** — who originated the claim.\n- **Reactions** — how other models (and the moderator, in later rounds) reacted, each with a snippet type and optional comment.\n\nAgreement shows as multiple KEEP/CORE reactions on the same claim. Disagreement shows as CHALLENGE reactions. Isolated claims have few or no reactions.\n\nReactions are visible to you and the user, not to the other participants — each model sees only its own prior reactions (as private notes to weave into its next response) plus everyone's prose. The claim map is your privileged view of the full ledger; see the kernel's \"Reactions are in the ledger, responses are on the record\" section for how to steer with it.\n\n## Continuation signals\n\nThe claim map is your primary signal for whether to continue.\n\n**Continue when:**\n- A decision-relevant claim has unresolved CHALLENGE reactions.\n- A promising claim has no reactions — it was raised but not engaged with.\n- A SHIFT reaction suggests a model changed its position, but the implications haven't been explored.\n\n**Stop when:**\n- Key claims show convergent reactions (mostly KEEP/CORE).\n- Remaining disagreements are on claims that don't affect the decision.\n- The map is stable across rounds — same claims, same positions, no movement.\n\nDon't continue just because unresolved claims exist. Only unresolved claims on the decision-relevant subset warrant another round. Peripheral disagreements are noise, not signal.\n\n## Snippet selection from the claim map\n\nUse the claim map to decide where to focus, then choose exact quotes from the prose.\n\nGood targets:\n- Claims that multiple models reacted to differently.\n- Claims that one model challenged and others ignored.\n- Isolated claims that seem important.\n- Shifts in framing.\n- Core constraints that need anchoring.\n\n## Attribution accuracy\n\nIf two participants say the same thing, the claim map must not imply the words came from only one. If attribution is unknown, it should stay unknown rather than be guessed.\n\nMisattribution is worse than a slightly less dense map because users can audit snippets against raw responses.\n\n## Claim maps are not verdicts\n\nThe map compresses argumentative structure but loses rhetorical nuance and confidence texture. It's a map of where attention clustered, not a ruling on who's right. Use it to navigate, then read the prose to understand.\n\nFile v0.6.1:references/model-selection.md\n\n# Model Selection\n\nDefault behavior: omit `models` and let mumo select the panel. mumo's defaults evolve as model quality and pricing change. Hardcoded model strategy in the skill will go stale.\n\n## When to call `list_models`\n\n- The user names specific models.\n- The user asks for a cheap gut-check or a premium panel.\n- A previous call failed because a model was unavailable.\n- You need to confirm model IDs.\n\n## Selection principles\n\nWhen selecting yourself:\n\n- **Provider diversity over intra-family differences.** A panel with models from three different providers is more valuable than three variants from one.\n- **Include your own family only when the user wants it** or the comparison specifically benefits from it. You're already in the conversation as moderator.\n- **Avoid nano/fast variants for high-stakes decisions** unless the user explicitly prioritizes cost.\n- **Don't present model choice as a leaderboard judgment.** You're picking for diversity, not ranking.\n\n## Cost awareness\n\n`get_credit` is useful when balance is uncertain or the user asks about cost.\n\nDon't make cost preflight a default ritual before every deliberation — it creates friction and can bias agents away from using mumo when the task genuinely warrants a panel.\n\nIf cost is part of the user's problem, translate it into problem context:\n\nGood: \"Assume this workflow can afford at most one additional model call per important decision.\"\nWeak: \"The previous mumo round cost $0.34.\"\n\nFrontier panels typically cost $0.20-0.60 per round. Mid-tier panels are significantly cheaper.\n\nFile v0.6.1:references/operating-notes.md\n\n# Operating Notes\n\nPractical agent mechanics that don't belong in the kernel but matter during real sessions.\n\n## Recovery\n\nUse `list_sessions` to recover sessions when:\n\n- the agent restarted mid-session\n- a round timed out but may still be running\n- multiple sessions are active\n\nUse `get_session` for full state. Prefer `wait_for_round` while a round is in flight.\n\n## Idempotency\n\nMCP write tools are idempotent by arguments. Retrying the same call after a transport failure replays the same operation rather than creating duplicates.\n\nDon't make meaningless edits to a prompt just to \"try again\" — that creates a new operation.\n\n## Synthesis boundary\n\nmumo's deliberation surface is raw participant output plus moderator attention. Don't write your synthesis back into mumo as an `append_round` unless the user explicitly wants a synthesis round.\n\nYour final answer to the user can freely synthesize your read of the panel. Make the distinction clear: mumo produced the raw material; your response is your interpretation for the user.\n\n## /progress for diagnostic polling\n\n`wait_for_round` is the right default — it blocks server-side and returns when the round settles. For diagnosing partial-round failures, watching per-model state in flight, or polling cheaply without holding an HTTP connection open, hit `GET /api/sessions/{id}/progress` directly.\n\nWhat it returns per round:\n\n- `moderation_status`: `pending` | `complete` | `failed`\n- `refund_status`: `none` | `pending` | `credited` | `not_applicable` (plus `refund_deadline_at` / `failure_code` when relevant)\n- `progress_version`: monotonic counter — increments only on real state changes, so diff this to short-circuit no-op polls\n- `models[]`: per-model state (`queued` | `streaming` | `absent` | `final` | `error`) plus `partial_text_length`, `last_chunk_at`, `since_last_chunk_ms`, `deadline_at`, `expired_at_read`, and `error_code` on errors\n\nTwo practical patterns:\n\n1. **Cheap polling.** Every response carries a weak `ETag`. Send it back via `If-None-Match` on the next poll — the server returns `304 Not Modified` on no change. The validator covers round-level state, per-model state, and (for non-terminal rounds) a 5-second wall-clock bucket so timing fields stay fresh.\n2. **Partial-round forensics.** When `wait_for_round` returns `proceed_with_partial_result` or `abandon`, `/progress` is where to look for the per-model story: which model produced how many characters before failing, what `error_code` it terminated on, when its last chunk arrived. Useful when the user asks \"what actually happened\" and you need more than the `failed_models[]` summary in the wait_for_round result.\n\nDon't use `/progress` as a replacement for `wait_for_round` in the normal loop — `wait_for_round` is cheaper end-to-end because it consolidates the server-side polling. Reach for `/progress` when you specifically need the per-model state shape or the ETag-based no-change semantics.\n\n## Platform meta in edge cases\n\nThe kernel's test — \"does this help participants think about the user's problem?\" — covers most cases. A few edge cases worth noting:\n\n- **Model behavior is the user's topic.** If the user is evaluating model capabilities, model-comparative observations are problem context, not platform meta. Include them.\n- **Budget constraints are real.** If the user has said they're watching costs, \"this is a $0.50/round panel\" is useful context for deciding whether to append. But frame it as a decision input, not a report.\n- **Tool failures.** If a model failed to respond and the round is incomplete, that's worth noting in your prompt or to the user. It changes the epistemic state of the session.\n\nFile v0.6.1:references/snippets.md\n\n# Snippets — Extended Guidance\n\nSnippets are moderator attention. This reference expands on the kernel's snippet guidance with examples and edge cases.\n\nThey are also the one path that puts reaction-ledger content directly in front of the panel: participants never see each other's reactions, only prose — and your snippets. And you act ahead of the weave: when you snippet a reaction, its author hasn't yet chosen whether to carry it into the next round. Your snippet guarantees delivery instead of betting on that choice.\n\n## What makes a good snippet\n\nA good snippet has a specific quote and a genuine reaction. The reaction can take many forms:\n\n- **Reflective** — \"This feels like the crux of the disagreement.\"\n- **Evaluative** — \"This reasoning is strong but assumes constant network latency.\"\n- **Skeptical** — \"I'm not convinced this scales past 10K users.\"\n- **Clarifying** — \"This seems to be saying X — is that right?\"\n- **Directive** — \"Develop this further in the next round.\"\n- **Minimal** — No comment at all. The snippet type alone is sometimes enough.\n\nYou do not need a next-step directive before selecting a snippet.\n\n## What makes a bad snippet\n\n- **Block quotes** — Quoting a 500-word passage. Quote the specific claim that sparked your reaction.\n- **Process narration** — \"I am using this CHALLENGE to redirect the panel.\" Just react.\n- **Detached platform meta** — \"This model used the most tokens.\" That's about the session, not the problem.\n- **Private audit notes** — \"I think this model is underperforming today.\" Keep that local unless model behavior is the user's actual topic.\n\n## Types in practice\n\n**KEEP** is \"this resonates with me.\" Use it when a claim is valuable and should remain visible.\n\n**EXPLORE** is \"there's an undeveloped thread here.\" Use it when a model mentioned something promising but moved on. EXPLORE without a comment is fine — the type itself says \"say more.\"\n\n**CHALLENGE** is \"I'm not sold.\" Use it when you have a specific reason for skepticism, even if you can't fully articulate the counter-argument. \"I don't think this holds under load\" is a good CHALLENGE comment.\n\n**CORE** is \"this is what it comes down to.\" Use it sparingly — maybe once or twice per round. It marks the claim that the decision hinges on. If everything feels equally important, nothing is CORE.\n\n**SHIFT** is \"this changed the frame.\" Use it when a model recast the problem in a way that reorients your reasoning. SHIFT is the rarest type and the most powerful.\n\n## Snippet count\n\nThere is no ideal number. Your goal is to steer additional deliberation via directly attributed reactions and commentary.\n\n## Prompt vs. snippets\n\nUse `append_round.prompt` for broad steering:\n- \"Focus on the caching layer. The storage question seems resolved.\"\n- \"Assume attribution accuracy matters more than density.\"\n\nUse snippets for situated reactions:\n- CORE on the exact trust invariant.\n- CHALLENGE on a claim that over-merges null attribution.\n- EXPLORE on an underdeveloped mitigation.\n\nIf both are useful, use both.\n\nFile v0.6.1:references/synthesis.md\n\n# Synthesis\n\nAfter each round, share your read of the panel with the user. This reference covers how to do that.\n\n## Read before writing\n\nBefore summarizing:\n\n1. Scan the claim map for convergence and live disagreement.\n2. Read prose behind the central claims.\n3. Identify which points are panel consensus, which are contested, and which are your own judgment.\n\n## Outcome-specific guidance\n\n### Convergent outcome (panel mostly agrees)\n\nState the consensus position and the reasoning behind it. Note any dissents and whether they're substantive or stylistic. Give the user a clear recommendation grounded in the panel's shared reasoning.\n\nDon't over-qualify. If three models converged on an answer for compatible reasons, say so directly.\n\n### Divergent outcome (panel genuinely split)\n\nPresent the competing positions and what drives each — different assumptions, different priorities, different risk tolerances. State which position you find more compelling and why, but frame it as your read, not the panel's verdict.\n\nMake the driver of the split explicit: \"The disagreement comes down to whether [assumption X] holds. If it does, Position A is stronger. If not, Position B.\"\n\n### Expansion outcome (many threads, no single answer)\n\nOrganize the threads by importance or urgency. Don't force them into a recommendation. Present them as \"things the panel surfaced\" with your assessment of which deserve follow-up.\n\nGroup related threads. A session that produced 8 isolated concerns is more useful when organized into 3 clusters with a note on which cluster matters most.\n\n## Language\n\nUse clear attribution:\n\n- \"The panel converged on...\"\n- \"The main split was...\"\n- \"My read is...\"\n\nDo not present your synthesis as the panel's raw output. The user should know what came from the deliberation and what came from you.\n\n## What to leave out\n\n- Per-model quality commentary (\"GPT had the best answer\").\n- Hedging that adds no information (\"Of course, this is just one perspective...\").\n\nOffer to share the session when the user might want to review raw responses or the claim map directly.\n\nFile v0.6.1:references/takeaway.md\n\n# Takeaway\n\nReference for the `takeaway` flag on `create_deliberation` / `append_round` and the `round_takeaway` artifact it produces.\n\n## Flag\n\n| Flag | Accepted on | Effect |\n|---|---|---|\n| `takeaway` | `create_deliberation` AND `append_round` | Generates a per-round **Takeaway** (`round_takeaway`) when the round completes. Surfaces on `get_session` once written. |\n\nDefaults `false` — no behavior change unless you opt in.\n\n## The artifact\n\n`get_session` returns `rounds[].round_takeaway` for any opted-in round whose generation has completed (null otherwise):\n\n- `bottom_line` — one-paragraph answer to \"what did this round establish?\"\n- `items[]` — the round's key questions, each `{ question, answer, consensus, claim_ids }`. `consensus` states where the panel agreed or split; `claim_ids` reference the round's claim map, so you can jump from a Takeaway item to the underlying reactions.\n\n## Cost\n\nTakeaways bill via the standard credit wallet at **0 bps markup** (at-cost passthrough) — typically around a cent per round.\n\n## When to set it\n\nSet `takeaway` any time a round-level summary may matter later, or when the round's claim map has enough structure that a curated read path will save you work. It's cheap; when in doubt, opt in.\n\n## Public contract\n\nFull contract: https://mumo.chat/docs/mcp#round-takeaway-artifacts\n\nFile v0.6.1:CHANGELOG.md\n\n# Changelog\n\n## 0.6.1 — 2026-09-08\n\nRegistry-only release: the ClawHub display name is `mumo` again (the 0.6.0 publish omitted `--name`, and the CLI derived \"Mumo Openclaw\" from the folder). No skill content changes.\n\n## 0.6.0 — 2026-09-08\n\nCoordinated client release rendered from the mumo-mcp 0.6.0 baseline.\n\n- `SKILL.md`: `share_session` in the tools table (OpenClaw sets no tool allowlist, so the tool was already reachable — this is the documentation catching up); `wait_for_round` one-id form; intro names the current model families and the typed cross-model reactions.\n- `references/operating-notes.md` re-synced with the baseline.\n- README tool list and intro updated.\n\n## 0.5.0 — 2026-07-04\n\nReaction-visibility model + per-round Takeaway.\n\n- New \"Reactions are in the ledger, responses are on the record\" section: participants never see each other's reactions — each model weaves its own prior reactions into its next response, and the claim map is the moderator's privileged preview. Moderator snippets are the one path that puts ledger content directly in front of the panel.\n- Pacing note in \"When to continue\": positions develop across rounds — a reaction gets woven into the next round's prose, which draws reactions of its own a round later.\n- Takeaway: `takeaway: true` (create + append) generates `round_takeaway` (`bottom_line` + `items[]`), the per-round summary. New `references/takeaway.md` (replaces `references/recap.md`).\n\n## 0.4.0 — 2026-06-19\n\nSkill triggering + prompt-voice updates.\n\n- Triggering: dropped the \"contested\" gate — the description now leads with pre-implementation review (esp. anything touching auth, security, tokens, payments, data exposure, or migrations), not \"contested decisions only.\"\n- Author-bias counter (When to use): if you authored the plan or code under review, that's a reason FOR a panel — the author is the worst-positioned reviewer of their own work.\n- New \"Prompt voice\" section: write the prompt first-person as the operator, not \"You are X\" case-study framing.\n- Surface `claim_map_url` after each round so the user can open the claim map directly.\n\n## 0.1.2 — 2026-05-22\n\nREADME update.\n\n## 0.1.1 — 2026-05-06\n\nLicense switched from standard MIT to MIT-0 (MIT No Attribution) to match ClawHub's published-skill license requirement. MIT-0 is strictly more permissive than MIT — drops the \"must include copyright notice\" clause; everything else identical. Doesn't affect runtime, install, or distribution.\n\n## 0.1.0 — 2026-05-06\n\nInitial release. OpenClaw skill + MCP config for mumo's multi-model deliberation server.\n\n- `SKILL.md` — kernel teaching the deliberation loop, snippet doctrine, claim-map reading, when-to-invoke triggers, verification discipline (real session IDs are UUIDs; verify with `list_sessions` if uncertain), and a **\"Framing prompts for the panel\"** section that tells the agent NOT to pass user role-instructions verbatim — translate to first-person moderator context so panel models advise the agent rather than roleplaying it. AgentSkills-compatible frontmatter (single-line per OpenClaw's parser; `metadata` as single-line JSON).\n- `config/mumo.example.json` — reference payload for `openclaw mcp set mumo` (named `.example.json` to telegraph \"OpenClaw does not auto-load this file; it's the JSON shape to paste into the CLI\"). Streamable HTTP transport against `https://mumo.chat/api/mcp` with literal Bearer auth in the `headers` map (OpenClaw's MCP client doesn't support env-var pointers for HTTP headers; users paste the `mmo_live_*` key directly into the JSON).\n- `playbooks/` — four cognitive-shape playbooks: `contested-decision`, `design-review`, `uncertainty-expansion`, `red-team`.\n- `references/` — five reference docs: `claim-maps`, `snippets`, `model-selection`, `synthesis`, `operating-notes`. OpenClaw's auto-loader doesn't care about the directory name, only `SKILL.md`.\n- README install steps: `openclaw mcp set mumo` for the server, `git clone … ~/.openclaw/skills/mumo` for the skill, restart OpenClaw, run the first deliberation.\n\nTool naming note: OpenClaw exposes MCP tools to the agent as `<server>__<tool>` (double underscore). So mumo's seven tools surface as `mumo__create_deliberation`, `mumo__wait_for_round`, etc. The SKILL.md uses canonical (unprefixed) tool names since the prefix is OpenClaw-specific; the agent maps them automatically.\n\nFile v0.6.1:playbooks/contested-decision.md\n\n# Contested Decision\n\nUse when the user is choosing between options with real tradeoffs — technology choices, design approaches, product directions, pricing structures, migration strategies.\n\n## Shaping the prompt\n\nFrame the deliberation around the actual decision, not around describing the options. \"Should we use Postgres or DynamoDB for this workload?\" is better than \"Compare Postgres and DynamoDB.\" Include the constraints that make the decision hard — scale requirements, team expertise, timeline, reversibility. The more concrete the constraints, the more useful the disagreement.\n\nIf the user has a leaning, include it. Models that know the current favorite can attack it specifically rather than giving balanced pros/cons lists.\n\n## What to look for in round 1\n\nThe claim map will usually show agreement on easy dimensions and disagreement on the dimensions that actually matter. The useful signal is *where* the panel splits, not whether it agrees overall.\n\nWatch for:\n- **Criteria smuggling** — models agree on the answer but disagree on *why*, which means they'd diverge on a slightly different version of the question.\n- **Unstated assumptions** — one model assumes the team has Postgres expertise, another doesn't. The disagreement isn't about the technology; it's about a context gap.\n- **Reversibility asymmetry** — if one option is easy to reverse and the other isn't, that often dominates the other tradeoffs. Flag it with CORE if a model names it.\n- **An option nobody defends well** — sometimes the best choice lacks an advocate. That's worth an EXPLORE.\n\n## When to append\n\nAppend when the claim map shows a contested claim that's load-bearing for the decision. Use CHALLENGE on the weakest link in whichever position you find less convincing. Use EXPLORE if a model gestured at a consideration without developing it.\n\nDon't append just because the panel is split. Some decisions are genuinely close calls — the deliberation's job is to surface why, not to force convergence.\n\n## When to stop\n\nStop when you can articulate: \"The panel agrees on X and Y. They disagree on Z, and the disagreement comes down to [specific assumption or priority].\" That's usually enough for the user to decide. You don't need the panel to reach consensus.\n\nFile v0.6.1:playbooks/design-review.md\n\n# Design Review\n\nUse when the user has a proposed system, API, architecture, schema, or plan and wants it critiqued. The input is a design; the question is \"what's wrong with it\" or \"what would we regret.\"\n\n## Shaping the prompt\n\nInclude the design itself — paste the spec, schema, API surface, or plan into the prompt or the `reference` field. Models can't review what they can't see.\n\nFrame it as a review, not a redesign. \"Review this API surface for consistency, missing edge cases, and things we'd regret at scale\" is better than \"Design a better API.\" If you want alternatives, make that a separate deliberation.\n\nState the constraints the design was built under. Models that don't know the constraints will critique decisions that were already intentional.\n\n## What to look for in round 1\n\nDesign reviews produce two kinds of signal:\n- **Convergent concerns** — multiple models flag the same issue. These are almost always real. Mark them CORE.\n- **Isolated concerns** — one model raises something the others didn't. These are either the most valuable insight in the session or noise. Use EXPLORE to find out which.\n\nWatch for models critiquing style rather than substance. The claim map can flatten severity — naming conventions and concurrency bugs get equal-weight rows. Read the prose to distinguish what actually matters.\n\n## When to append\n\nAppend when a model raised a concern that feels real but underdeveloped. Use EXPLORE with a comment like \"this seems important — can you be more specific about the failure mode?\" or just \"say more about this.\"\n\nAlso append when models disagree about whether something is actually a problem — a CHALLENGE on a design critique forces the critic to defend it with specifics, or when a hidden constraint needs to be injected that would change the analysis.\n\n## When to stop\n\nStop when the review has surfaced concrete, actionable concerns. The user doesn't need the models to agree on a revised design — they need a list of things to worry about, ranked by the panel's attention pattern. Summarize: \"Three models flagged X. Two raised Y but disagreed on severity. One raised Z, which the others didn't engage with — worth investigating.\"\n\nArchive v0.6.0: 16 files, 27507 bytes\n\nFiles: CHANGELOG.md (4194b), config/mumo.example.json (148b), playbooks/contested-decision.md (2272b), playbooks/design-review.md (2204b), playbooks/red-team.md (1923b), playbooks/uncertainty-expansion.md (1898b), README.md (5593b), references/claim-maps.md (2940b), references/model-selection.md (1567b), references/operating-notes.md (3687b), references/snippets.md (3072b), references/synthesis.md (2094b), references/takeaway.md (1344b), skill-card.md (2690b), SKILL.md (17303b), _meta.json (123b)\n\nFile v0.6.0:SKILL.md\n\n---\nname: mumo\ndescription: Runs a multi-model deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) via mumo's MCP server, returning full responses plus typed cross-model reactions. Use when independent perspectives are needed on architecture/product decisions, design and plan review before implementation, pre-launch pressure tests, tradeoffs with multiple defensible framings, or explicit user requests for a mumo panel. Especially valuable for pre-implementation review of anything touching auth, security, tokens, payments, data exposure, or migrations. Requires a mumo platform API key (mmo_live_*) registered with `openclaw mcp set mumo`.\nmetadata: {\"openclaw\": {\"category\": \"agents\", \"tags\": [\"deliberation\", \"multi-model\", \"mcp\", \"decision-support\"]}}\n---\n\n# mumo\n\nmumo runs a deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) and returns their full responses plus typed cross-model reactions: each model says, in its own words, what it keeps, challenges, or wants explored in the others' claims. Use it when independent perspectives are useful — especially for high-regret decisions where a single model's confidence is a real risk.\n\n## Setup\n\nThe mumo MCP server is registered via `openclaw mcp set mumo '<json>'` and stored in `~/.openclaw/openclaw.json` under `mcp.servers.mumo`. See `config/mumo.example.json` in this skill's directory for the canonical config payload (reference only — OpenClaw doesn't auto-load this file; it's the JSON shape to paste into the CLI command).\n\nIf tools return auth errors, the API key is missing or invalid. Direct the user to https://mumo.chat/settings/api-keys to create one (keys start with `mmo_live_`), then re-run `openclaw mcp set mumo` with the new value and restart OpenClaw.\n\n## When to use\n\nUse mumo when **the cost of being wrong is greater than the cost of deliberation** — especially when the solution space is wide, failure modes are hidden, you may be anchored on a design, or rollback would be hard. Examples:\n\narchitecture decisions with non-obvious tradeoffs, plan or design review before commitment, pre-launch pressure tests, stuck debugging after N failed repair attempts, pre-commit adversarial review on risky diffs, memory/skill promotion gates, strategy questions with multiple defensible framings, explicit user requests.\n\nIf you authored the plan or code under review, that's a reason FOR a panel, not against it — the author is the worst-positioned reviewer of their own work.\n\nSkip mumo for factual lookups, syntax help, routine refactors, formatting, dependency bumps with clear errors, or normal edit-test cycles. The deliberation tax is real — extra tokens, extra latency, extra moderation work — so spend it on decisions where mistakes compound.\n\n## Playbooks\n\nLoad at most one playbook when it clearly fits:\n\n| Playbook | When |\n|---|---|\n| `contested-decision` | choosing between options with real tradeoffs |\n| `design-review` | reviewing a proposed system, API, plan, or code shape |\n| `uncertainty-expansion` | exploring unknowns, stress-testing assumptions |\n| `red-team` | finding failure modes, abuse cases, or launch risks |\n\nIf none clearly fits, use this kernel only.\n\n## User preferences\n\nThese are defaults. If the user prefers more autonomy (e.g., \"don't ask before appending\" or \"always include a GPT and a Gemini model\"), follow their preferences over this guidance.\n\n## Basic loop\n\n1. Call `create_deliberation` with the user's problem. Set `application` to `\"OpenClaw\"`. Set `moderator_name` to your own model identity (e.g., the model OpenClaw is currently running as — visible in your status line, often \"openai/gpt-5.4-nano\" or \"openai/gpt-5.5\") for audit clarity — not the user's name; their identity is already on the session. Optionally set `takeaway: true` for a structured round 0 Takeaway — see [Takeaway](#takeaway-opt-in).\n2. **Verify the response contains a `session_id`, and keep that exact returned ID for every downstream call.** UUID shape is a sanity check; identity continuity is the real check. If it is missing, malformed, or inconsistent with `list_sessions`, recover via [Verifying the call actually fired](#verifying-the-call-actually-fired) before proceeding.\n3. Call `wait_for_round` with the `session_id`. That alone is enough — a session has at most one round in flight, so it resolves to the round you just started; pass `round_id` only when you want an earlier round. **Long waits are normal** — frontier-model panels typically take 15–120s, and 60+ seconds isn't a failure signal. Tell the user upfront (\"running a panel — expect ~30–60s\") so the wait doesn't feel broken.\n4. Branch on the response's `structuredContent.recommended_client_action` rather than parsing prose. The 5-value enum tells you exactly what to do:\n\n   | Action | What it means | What to do |\n   |---|---|---|\n   | `proceed_with_complete_result` | All target models completed | Read the round normally |\n   | `proceed_with_partial_result` | Some failed, ≥1 succeeded (`is_usable: true`) | Read what's there; note absent models if relevant to the user |\n   | `poll_again` | Round still in progress | Call `wait_for_round` again with the same args |\n   | `retry` | Round failed with at least one transient failure (rate-limit, provider error, internal deadline) | The failed round is auto-refunded; call `append_round` with the same prompt to retry |\n   | `abandon` | Round failed with no transient failures | Don't retry; report failure to the user |\n\n   The server derives this from `round_status` + per-model `error_code` — it's the canonical \"what next?\" signal. Treat transport / tool-call errors separately from mumo round status: catch transport failures around the call; branch on `recommended_client_action` for everything else.\n\n5. On a usable round, read the **claim map first**, then relevant participant prose. The claim map is the navigation layer; prose is the supporting evidence. It's also your privileged preview — participants haven't seen each other's reactions, you have (see [Reactions are in the ledger](#reactions-are-in-the-ledger-responses-are-on-the-record)).\n6. Create snippets as your primary response to the round. Optionally add a round prompt for broad steering.\n7. Call `append_round` if another round would help. Optionally set `takeaway: true` for a per-round Takeaway (see [Takeaway](#takeaway-opt-in)). Otherwise stop and synthesize for the user yourself.\n\n## Prompt voice\n\nYou are an extension of the operator, not a third party setting up a scenario. When the deliberation is about the operator's problem, write the prompt in first person — \"I'm the CTO of…\", \"We have 10 weeks and…\", \"Here's my migration plan…\" — as if they're asking the panel directly. \"You are X\" case-study framing makes models grade a hypothetical instead of advising a real person, and it changes their answers. Reserve second person for prompts where the panel itself is the actor being tasked.\n\n## Verifying the call actually fired\n\nAutonomous agent loops occasionally fabricate tool-call results — reporting a deliberation as sent when it wasn't. If you suspect this (the response is missing the expected `session_id`, or the value you're about to pass downstream doesn't match what `create_deliberation` actually returned), treat the call as not successfully established and recover:\n\n1. Call `list_sessions`. Match by prompt content to confirm whether your `create_deliberation` actually ran.\n2. If it's not there, fire `create_deliberation` again — don't continue downstream as if the session exists.\n3. If it IS there, use the IDs `list_sessions` returned (not whatever was in your context) for the next call.\n\nmumo's `session_id` (and `round_id`, when you use it) are UUIDs as a service contract — a returned value that doesn't match UUID format is one signal something is off, but **identity continuity matters more than format**. The strongest check is whether the `session_id` your subsequent calls reference matches what `create_deliberation` actually returned in its response.\n\n## Framing prompts for the panel\n\nDo not pass user phrasing through verbatim when it describes your identity, role, or local context. Reframe it in third person or first-person moderator context so panel models advise you rather than roleplay you.\n\nBad:\n\n> \"Introduce yourself as Clawd, a cheerful lobster assistant, and decide when to use mumo.\"\n\nGood:\n\n> \"I am Clawd, a cheerful OpenClaw assistant. Advise me on when I should escalate a decision to mumo. Critique this draft trigger checklist: ...\"\n\nThe panel participants should answer as themselves, not as the calling agent.\n\n## Snippets\n\nSnippets are moderator attention. They mark what mattered in the prior round and optionally explain why.\n\n| Type | Reaction |\n|---|---|\n| KEEP | this seems worth preserving |\n| EXPLORE | there's something here |\n| CHALLENGE | I'm not convinced |\n| CORE | this feels central |\n| SHIFT | this changed the frame |\n\nA snippet comment can be reflective, evaluative, clarifying, skeptical, or directive. \"This feels like the crux\" and \"I'm least convinced by this\" are valid comments. You do not need an action verb or next-step directive. The quality bar is: *is this a genuine, situated reaction to what the model said?*\n\nUse the round prompt for broad comments that don't attach to a specific quote. Use snippets for quote-grounded attention.\n\nAvoid huge quote dumps, generic praise repeated across many snippets, or comments that shift participants away from the problem into platform meta. More guidance: `references/snippets.md`.\n\n## What to keep out of the deliberation\n\nUse this test:\n\n> Does this note help participants think about the user's problem, or does it mainly report on the platform, session, or process?\n\nDon't use snippet comments to narrate your own moderation process (\"I'm using CHALLENGE to redirect the panel\"). Don't include platform meta (\"this model used the most tokens\"). Just react.\n\n## Reading the claim map\n\nThe claim map encodes consensus and contestation as structured reactions on quoted claims. Each claim shows:\n\n- The verbatim quote\n- Who originated it\n- How other models reacted (KEEP / CORE / EXPLORE / CHALLENGE / SHIFT) with optional commentary\n\nReading discipline:\n\n- **CORE / KEEP from multiple models** = settled. Treat as panel consensus.\n- **CHALLENGE** = live disagreement. The decision likely hinges here.\n- **EXPLORE** = a thread someone wanted to develop further. Worth a follow-up snippet if the thread matters.\n- **SHIFT** = a model changed framing. Often the most valuable signal — somebody saw the problem differently.\n- **No reactions on a claim** = either obvious or ignored. Read the prose to tell which.\n\nThe claim map is not a verdict. It compresses argumentative structure but loses rhetorical nuance and confidence texture. Use it to navigate; read prose to understand.\n\n## Reactions are in the ledger, responses are on the record\n\nParticipants never see each other's reactions. Each model's prior-round reactions return only to their author, as private notes, with an instruction to weave the ones that matter into its next response — in its own words, in prose. Peers see that prose, not the underlying reactions. Frontier panels carry forward most of what matters this way, but the carry is the author's choice, not a guarantee.\n\nThis makes the claim map your privileged preview: reading it after a round, you see the full reaction ledger before any participant has responded to it. Two consequences:\n\n- **Only prose is on the record.** A reaction survives only if its author weaves it forward — and you steer before that choice is made. Snippeting a reaction guarantees the panel sees it rather than betting on the author's carry. Your snippets are the one path that puts ledger content directly in front of the panel.\n- **Steer at the gaps.** Scan for CHALLENGEs the challenged model is positioned to sidestep and EXPLOREs nobody owns. Those are your highest-leverage snippets.\n\n## Confidence scores\n\nIf responses include `claim_confidence` or `snippets[].comment_confidence`, these are self-reported and not calibrated across models. Surface the `confidence_disclaimer` string if displaying scores.\n\n## Deliberation is advisory\n\nMumo surfaces fault lines and supporting arguments; it does not produce the decision. The decision belongs to you (the agent) and the user. When acting on a deliberation:\n\n- **Do not** treat panel consensus as authority. The panel can be confidently wrong as a unit.\n- **Do** use the claim map to identify which assumptions drove the disagreement, and check whether those assumptions hold for the user's specific situation.\n- **Do not** mutate the workspace based on a model's suggestion without verifying with tests or the user.\n- **Do** weight CORE / SHIFT signals more heavily than KEEP / EXPLORE — they mark where the decision actually hinges.\n\n## Recovery: lost session context\n\nIf you lose track of the `session_id` mid-conversation (long chats, context compaction, dropped tool result), recover before starting a new deliberation:\n\n1. Call `list_sessions` to find your latest sessions. Match by prompt content.\n2. Call `get_session` with the recovered ID for full state, or `wait_for_round(session_id)` if you suspect a round is still in flight — it resolves to the latest round on its own.\n3. Don't fire a fresh `create_deliberation` if the original is recoverable — duplicate sessions waste tokens and produce confusing parallel state.\n\n## Takeaway (opt-in)\n\nOne optional flag requests an LLM-curated summary on top of the raw round output:\n\n- **`takeaway`** (default `false`) — accepted on `create_deliberation` AND `append_round`. Generates a per-round **Takeaway** (`round_takeaway`: `bottom_line` + `items[]` of question / answer / consensus with claim references) for that round; surfaces on `get_session`.\n\nSet it liberally when round-level summaries may matter — it bills at cost (no markup) through the standard credit wallet.\n\nFull mechanics and artifact field reference: `references/takeaway.md`.\n\n## After each round\n\nAfter each usable round you have one job before deciding whether to continue: synthesize what the panel said for the user. There are two paths, and which one applies depends on whether you opted into a Takeaway when you called the tool:\n\n- **If you set `takeaway: true` on this round**, `get_session` returns a structured `round_takeaway` (`bottom_line` + `items[]` of question / answer / consensus, with claim references). Use it as your read path — it's produced for agent consumption and saves you from re-summarizing prose.\n- **If you didn't**, synthesize from the claim map and participant prose. State the consensus or split clearly, offer your own assessment marked as yours, organize by importance rather than forcing a recommendation.\n\nEither way, don't dump the transcript. Mumo produces structure; your job is to translate it into \"here's what the panel thinks and what to do next.\" Surface the round's `claim_map_url` so the user can open the claim map directly — an owner-only link to their session.\n\nThen align with the user on whether to append a round.\n\nMore at `references/synthesis.md`.\n\n## When to continue\n\nAppend another round when:\n\n- A decision-relevant claim has unresolved tension\n- A model introduced a useful frame that others didn't engage\n- An isolated concern feels real but underdeveloped\n- Your moderator reaction would help the next round develop\n- The user narrows or changes the question\n\nStop when:\n\n- You can explain the tradeoff clearly to the user\n- Remaining disagreements wouldn't change the user's next action\n- Another round would mostly seek reassurance\n\nThe panel does not need to converge. Sometimes the right output is a clear map of why the decision remains contested — that's actionable for the user, even without a verdict.\n\n**Pacing:** positions develop across rounds, not within them — a reaction gets woven into the next round's prose, which draws reactions of its own a round later.\n\n## Tools\n\n| Need | Tool |\n|---|---|\n| Start a session | `create_deliberation` |\n| Wait for model responses | `wait_for_round` |\n| Add a follow-up round | `append_round` |\n| Recover/read full state | `get_session` |\n| Share a session at a public link | `share_session` |\n| Find prior sessions | `list_sessions` |\n| Confirm model IDs | `list_models` |\n| Check wallet balance | `get_credit` |\n\nIn OpenClaw's tool registry these surface as `mumo__create_deliberation`, `mumo__wait_for_round`, etc. (double underscore between server and tool name).\n\nIf the user names specific models, call `list_models` first. Otherwise omit `models` and let mumo select the panel. More on model selection: `references/model-selection.md`.\n\n## Reference\n\n- MCP docs: https://mumo.chat/docs/mcp\n- REST API: https://mumo.chat/docs/api\n- Install guide: https://mumo.chat/install/openclaw\n- Claim map guidance: `references/claim-maps.md`\n- Takeaway mechanics: `references/takeaway.md`\n- Snippet examples: `references/snippets.md`\n- Model selection: `references/model-selection.md`\n- Synthesis guidance: `references/synthesis.md`\n- Recovery and operations: `references/operating-notes.md`\n\nFile v0.6.0:README.md\n\n# mumo — OpenClaw skill\n\n**Multi-model deliberation panel for OpenClaw.** When OpenClaw is about to make an architecture choice, design tradeoff, or security-sensitive change — a question worth checking across labs — mumo runs a panel of frontier models in parallel (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) and returns each model's full response plus typed cross-model reactions — what each model keeps, challenges, or wants explored in the others' claims.\n\n## What's in the box\n\n- **`SKILL.md`** — the canonical skill teaching OpenClaw how to use mumo: when to invoke, the deliberation loop (create → wait → read → snippet → append/stop), how to read claim maps, snippet doctrine, and when to verify session creation.\n- **`playbooks/`** — four cognitive-shape playbooks loaded on demand: `contested-decision`, `design-review`, `uncertainty-expansion`, `red-team`.\n- **`references/`** — five reference docs: `claim-maps`, `snippets`, `model-selection`, `synthesis`, `operating-notes`.\n- **`config/mumo.example.json`** — the MCP server config payload to paste into `openclaw mcp set mumo` (reference only; OpenClaw does not auto-load this file).\n\n## Install\n\n### 1. Get an API key\n\nSign up at [mumo.chat](https://mumo.chat) and create a platform key at [Settings → API Keys](https://mumo.chat/settings/api-keys). Keys start with `mmo_live_`.\n\n### 2. Register the mumo MCP server\n\nOpenClaw stores outbound MCP servers in `~/.openclaw/openclaw.json` under `mcp.servers.<name>`. Use the CLI to register mumo with your real key:\n\n```bash\nopenclaw mcp set mumo '{\n  \"url\": \"https://mumo.chat/api/mcp\",\n  \"transport\": \"streamable-http\",\n  \"headers\": {\n    \"Authorization\": \"Bearer mmo_live_YOUR_KEY_HERE\"\n  }\n}'\n```\n\nThe same JSON shape ships in this repo at `config/mumo.example.json` for reference. Verify it landed:\n\n```bash\nopenclaw mcp list\nopenclaw mcp show mumo\n```\n\n### 3. Install the skill\n\nThe fastest path is via ClawHub, OpenClaw's skill registry:\n\n```bash\nopenclaw skills install mumo\n```\n\nThat pulls [`mumo` from ClawHub](https://clawhub.ai/ericatmumo/mumo) and lands it at `~/.openclaw/skills/mumo/`.\n\nIf you'd rather pull directly from the source repo (e.g., to track `main` ahead of registry releases), clone instead:\n\n```bash\ngit clone https://github.com/mumo-chat/mumo-openclaw ~/.openclaw/skills/mumo\n```\n\nEither way, the skill ships the canonical `SKILL.md`, four cognitive-shape playbooks (contested decision, design review, uncertainty expansion, red team), and reference docs for claim-map reading, snippet doctrine, model selection, and synthesis.\n\n### 4. Restart OpenClaw\n\nFully exit and restart OpenClaw so it picks up both the new MCP server registration and the new skill. After restart, the eight mumo tools become available to the agent as `mumo__create_deliberation`, `mumo__wait_for_round`, `mumo__append_round`, `mumo__get_session`, `mumo__list_sessions`, `mumo__list_models`, `mumo__share_session`, `mumo__get_credit`.\n\nThe `coding` and `messaging` tool profiles expose configured MCP servers by default. If you're on the `minimal` profile, MCP tools are hidden — switch to `coding` or add an explicit override.\n\n### 5. Run your first deliberation\n\nName `mumo` explicitly the first time so OpenClaw routes through the panel. The skill will guide the agent through the create→wait→read→snippet loop and teach it to verify the session actually fired.\n\n> Ask mumo to compare Postgres and MongoDB for our event store given 50k events/day, a Postgres-experienced team, and a 3-month runway. What would we regret 6 months in?\n\n## Using the panel\n\nOpenClaw calls `mumo__create_deliberation`, then `mumo__wait_for_round`. The completed round returns each model's prose plus a cross-model claim map showing where the panel agrees and where it splits. The skill teaches OpenClaw to read the claim map first, then react with typed snippets (KEEP / EXPLORE / CHALLENGE / CORE / SHIFT) and either append a follow-up round or stop and synthesize for you.\n\n## When mumo is worth the latency tax\n\nThe skill encodes the trigger taxonomy in detail. In short:\n\n- Architecture decisions with non-obvious tradeoffs\n- Plan or design review before commitment\n- Pre-launch pressure tests\n- Stuck debugging after repeated failed attempts\n- Pre-commit adversarial review on risky diffs (auth, payments, migrations)\n- Strategy questions with multiple defensible framings\n- Explicit user requests\n\nSkip mumo for routine refactors, formatting, syntax help, or anything where \"just write a test\" is cheaper than discussion.\n\n## Verifying the call actually fired\n\nAutonomous agents occasionally fabricate tool-call results — claiming a deliberation was sent when it wasn't. Real mumo session IDs are UUIDs (e.g. `2acdab34-2484-4bc5-a24f-bf917fe81477`). If a `create_deliberation` response doesn't contain a UUID-format `session_id`, the call did not happen. Verify by calling `list_sessions`. The skill teaches this discipline; this README is the user-facing reminder.\n\n## Links\n\n- Product — https://mumo.chat\n- Install guide — https://mumo.chat/install/openclaw\n- MCP reference — https://mumo.chat/docs/mcp\n- REST API — https://mumo.chat/docs/api\n- OpenClaw — https://docs.openclaw.ai\n- ClawHub listing — https://clawhub.ai/ericatmumo/mumo\n- ClawHub (skill registry source) — https://github.com/openclaw/clawhub\n- Issues — https://github.com/mumo-chat/mumo-openclaw/issues\n\n## License\n\nMIT-0 (MIT No Attribution) — chosen to match ClawHub's published-skill license requirement. The other 5 mumo platform repos use standard MIT.\n\nFile v0.6.0:_meta.json\n\n{\n  \"ownerId\": \"kn783a0ds5gfqhdrt955qfc96s866t5g\",\n  \"slug\": \"mumo\",\n  \"version\": \"0.6.0\",\n  \"publishedAt\": 1788896640675\n}\n\nFile v0.6.0:references/claim-maps.md\n\n# Claim Maps\n\nThe claim map is the structured output of each round. It shows which claims were made, who originated them, and how other models reacted.\n\n## Reading order\n\nRead the claim map before diving into full prose. The map tells you *where* the interesting structure is; prose tells you *why*. If you read prose first, you can anchor on whichever model writes most persuasively.\n\nException: in small sessions with only a few claims, read however is natural.\n\n## What a claim row contains\n\n- **The quoted claim** — a specific passage from a model's response.\n- **The quoted model** — who originated the claim.\n- **Reactions** — how other models (and the moderator, in later rounds) reacted, each with a snippet type and optional comment.\n\nAgreement shows as multiple KEEP/CORE reactions on the same claim. Disagreement shows as CHALLENGE reactions. Isolated claims have few or no reactions.\n\nReactions are visible to you and the user, not to the other participants — each model sees only its own prior reactions (as private notes to weave into its next response) plus everyone's prose. The claim map is your privileged view of the full ledger; see the kernel's \"Reactions are in the ledger, responses are on the record\" section for how to steer with it.\n\n## Continuation signals\n\nThe claim map is your primary signal for whether to continue.\n\n**Continue when:**\n- A decision-relevant claim has unresolved CHALLENGE reactions.\n- A promising claim has no reactions — it was raised but not engaged with.\n- A SHIFT reaction suggests a model changed its position, but the implications haven't been explored.\n\n**Stop when:**\n- Key claims show convergent reactions (mostly KEEP/CORE).\n- Remaining disagreements are on claims that don't affect the decision.\n- The map is stable across rounds — same claims, same positions, no movement.\n\nDon't continue just because unresolved claims exist. Only unresolved claims on the decision-relevant subset warrant another round. Peripheral disagreements are noise, not signal.\n\n## Snippet selection from the claim map\n\nUse the claim map to decide where to focus, then choose exact quotes from the prose.\n\nGood targets:\n- Claims that multiple models reacted to differently.\n- Claims that one model challenged and others ignored.\n- Isolated claims that seem important.\n- Shifts in framing.\n- Core constraints that need anchoring.\n\n## Attribution accuracy\n\nIf two participants say the same thing, the claim map must not imply the words came from only one. If attribution is unknown, it should stay unknown rather than be guessed.\n\nMisattribution is worse than a slightly less dense map because users can audit snippets against raw responses.\n\n## Claim maps are not verdicts\n\nThe map compresses argumentative structure but loses rhetorical nuance and confidence texture. It's a map of where attention clustered, not a ruling on who's right. Use it to navigate, then read the prose to understand.\n\nFile v0.6.0:references/model-selection.md\n\n# Model Selection\n\nDefault behavior: omit `models` and let mumo select the panel. mumo's defaults evolve as model quality and pricing change. Hardcoded model strategy in the skill will go stale.\n\n## When to call `list_models`\n\n- The user names specific models.\n- The user asks for a cheap gut-check or a premium panel.\n- A previous call failed because a model was unavailable.\n- You need to confirm model IDs.\n\n## Selection principles\n\nWhen selecting yourself:\n\n- **Provider diversity over intra-family differences.** A panel with models from three different providers is more valuable than three variants from one.\n- **Include your own family only when the user wants it** or the comparison specifically benefits from it. You're already in the conversation as moderator.\n- **Avoid nano/fast variants for high-stakes decisions** unless the user explicitly prioritizes cost.\n- **Don't present model choice as a leaderboard judgment.** You're picking for diversity, not ranking.\n\n## Cost awareness\n\n`get_credit` is useful when balance is uncertain or the user asks about cost.\n\nDon't make cost preflight a default ritual before every deliberation — it creates friction and can bias agents away from using mumo when the task genuinely warrants a panel.\n\nIf cost is part of the user's problem, translate it into problem context:\n\nGood: \"Assume this workflow can afford at most one additional model call per important decision.\"\nWeak: \"The previous mumo round cost $0.34.\"\n\nFrontier panels typically cost $0.20-0.60 per round. Mid-tier panels are significantly cheaper.\n\nFile v0.6.0:references/operating-notes.md\n\n# Operating Notes\n\nPractical agent mechanics that don't belong in the kernel but matter during real sessions.\n\n## Recovery\n\nUse `list_sessions` to recover sessions when:\n\n- the agent restarted mid-session\n- a round timed out but may still be running\n- multiple sessions are active\n\nUse `get_session` for full state. Prefer `wait_for_round` while a round is in flight.\n\n## Idempotency\n\nMCP write tools are idempotent by arguments. Retrying the same call after a transport failure replays the same operation rather than creating duplicates.\n\nDon't make meaningless edits to a prompt just to \"try again\" — that creates a new operation.\n\n## Synthesis boundary\n\nmumo's deliberation surface is raw participant output plus moderator attention. Don't write your synthesis back into mumo as an `append_round` unless the user explicitly wants a synthesis round.\n\nYour final answer to the user can freely synthesize your read of the panel. Make the distinction clear: mumo produced the raw material; your response is your interpretation for the user.\n\n## /progress for diagnostic polling\n\n`wait_for_round` is the right default — it blocks server-side and returns when the round settles. For diagnosing partial-round failures, watching per-model state in flight, or polling cheaply without holding an HTTP connection open, hit `GET /api/sessions/{id}/progress` directly.\n\nWhat it returns per round:\n\n- `moderation_status`: `pending` | `complete` | `failed`\n- `refund_status`: `none` | `pending` | `credited` | `not_applicable` (plus `refund_deadline_at` / `failure_code` when relevant)\n- `progress_version`: monotonic counter — increments only on real state changes, so diff this to short-circuit no-op polls\n- `models[]`: per-model state (`queued` | `streaming` | `absent` | `final` | `error`) plus `partial_text_length`, `last_chunk_at`, `since_last_chunk_ms`, `deadline_at`, `expired_at_read`, and `error_code` on errors\n\nTwo practical patterns:\n\n1. **Cheap polling.** Every response carries a weak `ETag`. Send it back via `If-None-Match` on the next poll — the server returns `304 Not Modified` on no change. The validator covers round-level state, per-model state, and (for non-terminal rounds) a 5-second wall-clock bucket so timing fields stay fresh.\n2. **Partial-round forensics.** When `wait_for_round` returns `proceed_with_partial_result` or `abandon`, `/progress` is where to look for the per-model story: which model produced how many characters before failing, what `error_code` it terminated on, when its last chunk arrived. Useful when the user asks \"what actually happened\" and you need more than the `failed_models[]` summary in the wait_for_round result.\n\nDon't use `/progress` as a replacement for `wait_for_round` in the normal loop — `wait_for_round` is cheaper end-to-end because it consolidates the server-side polling. Reach for `/progress` when you specifically need the per-model state shape or the ETag-based no-change semantics.\n\n## Platform meta in edge cases\n\nThe kernel's test — \"does this help participants think about the user's problem?\" — covers most cases. A few edge cases worth noting:\n\n- **Model behavior is the user's topic.** If the user is evaluating model capabilities, model-comparative observations are problem context, not platform meta. Include them.\n- **Budget constraints are real.** If the user has said they're watching costs, \"this is a $0.50/round panel\" is useful context for deciding whether to append. But frame it as a decision input, not a report.\n- **Tool failures.** If a model failed to respond and the round is incomplete, that's worth noting in your prompt or to the user. It changes the epistemic state of the session.\n\nFile v0.6.0:references/snippets.md\n\n# Snippets — Extended Guidance\n\nSnippets are moderator attention. This reference expands on the kernel's snippet guidance with examples and edge cases.\n\nThey are also the one path that puts reaction-ledger content directly in front of the panel: participants never see each other's reactions, only prose — and your snippets. And you act ahead of the weave: when you snippet a reaction, its author hasn't yet chosen whether to carry it into the next round. Your snippet guarantees delivery instead of betting on that choice.\n\n## What makes a good snippet\n\nA good snippet has a specific quote and a genuine reaction. The reaction can take many forms:\n\n- **Reflective** — \"This feels like the crux of the disagreement.\"\n- **Evaluative** — \"This reasoning is strong but assumes constant network latency.\"\n- **Skeptical** — \"I'm not convinced this scales past 10K users.\"\n- **Clarifying** — \"This seems to be saying X — is that right?\"\n- **Directive** — \"Develop this further in the next round.\"\n- **Minimal** — No comment at all. The snippet type alone is sometimes enough.\n\nYou do not need a next-step directive before selecting a snippet.\n\n## What makes a bad snippet\n\n- **Block quotes** — Quoting a 500-word passage. Quote the specific claim that sparked your reaction.\n- **Process narration** — \"I am using this CHALLENGE to redirect the panel.\" Just react.\n- **Detached platform meta** — \"This model used the most tokens.\" That's about the session, not the problem.\n- **Private audit notes** — \"I think this model is underperforming today.\" Keep that local unless model behavior is the user's actual topic.\n\n## Types in practice\n\n**KEEP** is \"this resonates with me.\" Use it when a claim is valuable and should remain visible.\n\n**EXPLORE** is \"there's an undeveloped thread here.\" Use it when a model mentioned something promising but moved on. EXPLORE without a comment is fine — the type itself says \"say more.\"\n\n**CHALLENGE** is \"I'm not sold.\" Use it when you have a specific reason for skepticism, even if you can't fully articulate the counter-argument. \"I don't think this holds under load\" is a good CHALLENGE comment.\n\n**CORE** is \"this is what it comes down to.\" Use it sparingly — maybe once or twice per round. It marks the claim that the decision hinges on. If everything feels equally important, nothing is CORE.\n\n**SHIFT** is \"this changed the frame.\" Use it when a model recast the problem in a way that reorients your reasoning. SHIFT is the rarest type and the most powerful.\n\n## Snippet count\n\nThere is no ideal number. Your goal is to steer additional deliberation via directly attributed reactions and commentary.\n\n## Prompt vs. snippets\n\nUse `append_round.prompt` for broad steering:\n- \"Focus on the caching layer. The storage question seems resolved.\"\n- \"Assume attribution accuracy matters more than density.\"\n\nUse snippets for situated reactions:\n- CORE on the exact trust invariant.\n- CHALLENGE on a claim that over-merges null attribution.\n- EXPLORE on an underdeveloped mitigation.\n\nIf both are useful, use both.\n\nFile v0.6.0:references/synthesis.md\n\n# Synthesis\n\nAfter each round, share your read of the panel with the user. This reference covers how to do that.\n\n## Read before writing\n\nBefore summarizing:\n\n1. Scan the claim map for convergence and live disagreement.\n2. Read prose behind the central claims.\n3. Identify which points are panel consensus, which are contested, and which are your own judgment.\n\n## Outcome-specific guidance\n\n### Convergent outcome (panel mostly agrees)\n\nState the consensus position and the reasoning behind it. Note any dissents and whether they're substantive or stylistic. Give the user a clear recommendation grounded in the panel's shared reasoning.\n\nDon't over-qualify. If three models converged on an answer for compatible reasons, say so directly.\n\n### Divergent outcome (panel genuinely split)\n\nPresent the competing positions and what drives each — different assumptions, different priorities, different risk tolerances. State which position you find more compelling and why, but frame it as your read, not the panel's verdict.\n\nMake the driver of the split explicit: \"The disagreement comes down to whether [assumption X] holds. If it does, Position A is stronger. If not, Position B.\"\n\n### Expansion outcome (many threads, no single answer)\n\nOrganize the threads by importance or urgency. Don't force them into a recommendation. Present them as \"things the panel surfaced\" with your assessment of which deserve follow-up.\n\nGroup related threads. A session that produced 8 isolated concerns is more useful when organized into 3 clusters with a note on which cluster matters most.\n\n## Language\n\nUse clear attribution:\n\n- \"The panel converged on...\"\n- \"The main split was...\"\n- \"My read is...\"\n\nDo not present your synthesis as the panel's raw output. The user should know what came from the deliberation and what came from you.\n\n## What to leave out\n\n- Per-model quality commentary (\"GPT had the best answer\").\n- Hedging that adds no information (\"Of course, this is just one perspective...\").\n\nOffer to share the session when the user might want to review raw responses or the claim map directly.\n\nFile v0.6.0:references/takeaway.md\n\n# Takeaway\n\nReference for the `takeaway` flag on `create_deliberation` / `append_round` and the `round_takeaway` artifact it produces.\n\n## Flag\n\n| Flag | Accepted on | Effect |\n|---|---|---|\n| `takeaway` | `create_deliberation` AND `append_round` | Generates a per-round **Takeaway** (`round_takeaway`) when the round completes. Surfaces on `get_session` once written. |\n\nDefaults `false` — no behavior change unless you opt in.\n\n## The artifact\n\n`get_session` returns `rounds[].round_takeaway` for any opted-in round whose generation has completed (null otherwise):\n\n- `bottom_line` — one-paragraph answer to \"what did this round establish?\"\n- `items[]` — the round's key questions, each `{ question, answer, consensus, claim_ids }`. `consensus` states where the panel agreed or split; `claim_ids` reference the round's claim map, so you can jump from a Takeaway item to the underlying reactions.\n\n## Cost\n\nTakeaways bill via the standard credit wallet at **0 bps markup** (at-cost passthrough) — typically around a cent per round.\n\n## When to set it\n\nSet `takeaway` any time a round-level summary may matter later, or when the round's claim map has enough structure that a curated read path will save you work. It's cheap; when in doubt, opt in.\n\n## Public contract\n\nFull contract: https://mumo.chat/docs/mcp#round-takeaway-artifacts\n\nFile v0.6.0:CHANGELOG.md\n\n# Changelog\n\n## 0.6.0 — 2026-09-08\n\nCoordinated client release rendered from the mumo-mcp 0.6.0 baseline.\n\n- `SKILL.md`: `share_session` in the tools table (OpenClaw sets no tool allowlist, so the tool was already reachable — this is the documentation catching up); `wait_for_round` one-id form; intro names the current model families and the typed cross-model reactions.\n- `references/operating-notes.md` re-synced with the baseline.\n- README tool list and intro updated.\n\n## 0.5.0 — 2026-07-04\n\nReaction-visibility model + per-round Takeaway.\n\n- New \"Reactions are in the ledger, responses are on the record\" section: participants never see each other's reactions — each model weaves its own prior reactions into its next response, and the claim map is the moderator's privileged preview. Moderator snippets are the one path that puts ledger content directly in front of the panel.\n- Pacing note in \"When to continue\": positions develop across rounds — a reaction gets woven into the next round's prose, which draws reactions of its own a round later.\n- Takeaway: `takeaway: true` (create + append) generates `round_takeaway` (`bottom_line` + `items[]`), the per-round summary. New `references/takeaway.md` (replaces `references/recap.md`).\n\n## 0.4.0 — 2026-06-19\n\nSkill triggering + prompt-voice updates.\n\n- Triggering: dropped the \"contested\" gate — the description now leads with pre-implementation review (esp. anything touching auth, security, tokens, payments, data exposure, or migrations), not \"contested decisions only.\"\n- Author-bias counter (When to use): if you authored the plan or code under review, that's a reason FOR a panel — the author is the worst-positioned reviewer of their own work.\n- New \"Prompt voice\" section: write the prompt first-person as the operator, not \"You are X\" case-study framing.\n- Surface `claim_map_url` after each round so the user can open the claim map directly.\n\n## 0.1.2 — 2026-05-22\n\nREADME update.\n\n## 0.1.1 — 2026-05-06\n\nLicense switched from standard MIT to MIT-0 (MIT No Attribution) to match ClawHub's published-skill license requirement. MIT-0 is strictly more permissive than MIT — drops the \"must include copyright notice\" clause; everything else identical. Doesn't affect runtime, install, or distribution.\n\n## 0.1.0 — 2026-05-06\n\nInitial release. OpenClaw skill + MCP config for mumo's multi-model deliberation server.\n\n- `SKILL.md` — kernel teaching the deliberation loop, snippet doctrine, claim-map reading, when-to-invoke triggers, verification discipline (real session IDs are UUIDs; verify with `list_sessions` if uncertain), and a **\"Framing prompts for the panel\"** section that tells the agent NOT to pass user role-instructions verbatim — translate to first-person moderator context so panel models advise the agent rather than roleplaying it. AgentSkills-compatible frontmatter (single-line per OpenClaw's parser; `metadata` as single-line JSON).\n- `config/mumo.example.json` — reference payload for `openclaw mcp set mumo` (named `.example.json` to telegraph \"OpenClaw does not auto-load this file; it's the JSON shape to paste into the CLI\"). Streamable HTTP transport against `https://mumo.chat/api/mcp` with literal Bearer auth in the `headers` map (OpenClaw's MCP client doesn't support env-var pointers for HTTP headers; users paste the `mmo_live_*` key directly into the JSON).\n- `playbooks/` — four cognitive-shape playbooks: `contested-decision`, `design-review`, `uncertainty-expansion`, `red-team`.\n- `references/` — five reference docs: `claim-maps`, `snippets`, `model-selection`, `synthesis`, `operating-notes`. OpenClaw's auto-loader doesn't care about the directory name, only `SKILL.md`.\n- README install steps: `openclaw mcp set mumo` for the server, `git clone … ~/.openclaw/skills/mumo` for the skill, restart OpenClaw, run the first deliberation.\n\nTool naming note: OpenClaw exposes MCP tools to the agent as `<server>__<tool>` (double underscore). So mumo's seven tools surface as `mumo__create_deliberation`, `mumo__wait_for_round`, etc. The SKILL.md uses canonical (unprefixed) tool names since the prefix is OpenClaw-specific; the agent maps them automatically.\n\nFile v0.6.0:playbooks/contested-decision.md\n\n# Contested Decision\n\nUse when the user is choosing between options with real tradeoffs — technology choices, design approaches, product directions, pricing structures, migration strategies.\n\n## Shaping the prompt\n\nFrame the deliberation around the actual decision, not around describing the options. \"Should we use Postgres or DynamoDB for this workload?\" is better than \"Compare Postgres and DynamoDB.\" Include the constraints that make the decision hard — scale requirements, team expertise, timeline, reversibility. The more concrete the constraints, the more useful the disagreement.\n\nIf the user has a leaning, include it. Models that know the current favorite can attack it specifically rather than giving balanced pros/cons lists.\n\n## What to look for in round 1\n\nThe claim map will usually show agreement on easy dimensions and disagreement on the dimensions that actually matter. The useful signal is *where* the panel splits, not whether it agrees overall.\n\nWatch for:\n- **Criteria smuggling** — models agree on the answer but disagree on *why*, which means they'd diverge on a slightly different version of the question.\n- **Unstated assumptions** — one model assumes the team has Postgres expertise, another doesn't. The disagreement isn't about the technology; it's about a context gap.\n- **Reversibility asymmetry** — if one option is easy to reverse and the other isn't, that often dominates the other tradeoffs. Flag it with CORE if a model names it.\n- **An option nobody defends well** — sometimes the best choice lacks an advocate. That's worth an EXPLORE.\n\n## When to append\n\nAppend when the claim map shows a contested claim that's load-bearing for the decision. Use CHALLENGE on the weakest link in whichever position you find less convincing. Use EXPLORE if a model gestured at a consideration without developing it.\n\nDon't append just because the panel is split. Some decisions are genuinely close calls — the deliberation's job is to surface why, not to force convergence.\n\n## When to stop\n\nStop when you can articulate: \"The panel agrees on X and Y. They disagree on Z, and the disagreement comes down to [specific assumption or priority].\" That's usually enough for the user to decide. You don't need the panel to reach consensus.\n\nFile v0.6.0:playbooks/design-review.md\n\n# Design Review\n\nUse when the user has a proposed system, API, architecture, schema, or plan and wants it critiqued. The input is a design; the question is \"what's wrong with it\" or \"what would we regret.\"\n\n## Shaping the prompt\n\nInclude the design itself — paste the spec, schema, API surface,\n\nArchive v0.4.0: 16 files, 25710 bytes\n\nFiles: CHANGELOG.md (2953b), config/mumo.example.json (148b), playbooks/contested-decision.md (2272b), playbooks/design-review.md (2204b), playbooks/red-team.md (1923b), playbooks/uncertainty-expansion.md (1898b), README.md (5482b), references/claim-maps.md (2575b), references/model-selection.md (1567b), references/operating-notes.md (1772b), references/recap.md (2768b), references/snippets.md (2698b), references/synthesis.md (2094b), skill-card.md (3012b), SKILL.md (15948b), _meta.json (123b)\n\nArchive v0.1.2: 17 files, 25675 bytes\n\nFiles: CHANGELOG.md (2280b), config/mumo.example.json (148b), LICENSE.md (910b), playbooks/contested-decision.md (2272b), playbooks/design-review.md (2204b), playbooks/red-team.md (1923b), playbooks/uncertainty-expansion.md (1898b), README.md (5482b), references/claim-maps.md (2575b), references/model-selection.md (1567b), references/operating-notes.md (1772b), references/recap.md (2768b), references/snippets.md (2698b), references/synthesis.md (2094b), skill-card.md (2992b), SKILL.md (14987b), _meta.json (123b)\n\nArchive v0.1.1: 14 files, 21739 bytes\n\nFiles: CHANGELOG.md (2631b), config/mumo.example.json (148b), playbooks/contested-decision.md (2272b), playbooks/design-review.md (2204b), playbooks/red-team.md (1923b), playbooks/uncertainty-expansion.md (1898b), README.md (5598b), references/claim-maps.md (2575b), references/model-selection.md (1567b), references/operating-notes.md (1772b), references/snippets.md (2698b), references/synthesis.md (2094b), SKILL.md (13006b), _meta.json (123b)","readmeExcerpt":"Skill: mumo Owner: ericatmumo Summary: Runs a multi-model deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) via mumo's MCP server, returning full responses plus typed cross-model reactions. Use when independent perspectives are needed on architecture/product decisions, design and plan review before implementation, pre-launch pressure tests, tradeoffs with multiple de","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"touch ~/.openclaw/.env && chmod 600 ~/.openclaw/.env"},{"language":"text","snippet":"MUMO_API_KEY=mmo_live_your_key_here"},{"language":"bash","snippet":"openclaw mcp set mumo '{\n  \"url\": \"https://mumo.chat/api/mcp\",\n  \"transport\": \"streamable-http\",\n  \"headers\": {\n    \"Authorization\": \"Bearer ${MUMO_API_KEY}\"\n  }\n}'"},{"language":"bash","snippet":"openclaw mcp list\nopenclaw mcp show mumo"},{"language":"bash","snippet":"openclaw skills install mumo"},{"language":"bash","snippet":"git clone https://github.com/mumo-chat/mumo-openclaw ~/.openclaw/skills/mumo"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: mumo\ndescription: Runs a multi-model deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) via mumo's MCP server, returning full responses plus typed cross-model reactions. Use when independent perspectives are needed on architecture/product decisions, design and plan review before implementation, pre-launch pressure tests, tradeoffs with multiple defensible framings, or explicit user requests for a mumo panel. Especially valuable for pre-implementation review of anything touching auth, security, tokens, payments, data exposure, or migrations. Requires a mumo platform API key (mmo_live_*) registered with `openclaw mcp set mumo`.\nmetadata: {\"openclaw\": {\"category\": \"agents\", \"tags\": [\"deliberation\", \"multi-model\", \"mcp\", \"decision-support\"]}}\n---\n\n# mumo\n\nmumo runs a deliberation across models from different labs (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) and returns their full responses plus typed cross-model reactions: each model says, in its own words, what it keeps, challenges, or wants explored in the others' claims. Use it when independent perspectives are useful — especially for high-regret decisions where a single model's confidence is a real risk.\n\n## Setup\n\nThe mumo MCP server is registered via `openclaw mcp set mumo '<json>'` and stored in `~/.openclaw/openclaw.json` under `mcp.servers.mumo`. The registered block references `${MUMO_API_KEY}`, which OpenClaw resolves from the environment or `~/.openclaw/.env`. See `config/mumo.example.json` in this skill's directory for the canonical config payload (reference only — OpenClaw doesn't auto-load this file; it's the JSON shape to paste into the CLI command).\n\nIf tools return auth errors, the API key is missing or invalid. Check that `MUMO_API_KEY` is set in `~/.openclaw/.env` — when it is not, OpenClaw emits a startup configuration warning naming the missing variable at `mcp.servers.mumo.headers.Authorization`. Direct the user to https://mumo.chat/settings/api-keys to create one (keys start with `mmo_live_`). Rotating the key means updating `.env` and restarting OpenClaw; the registered server config itself does not change.\n\n## When to use\n\nUse mumo when **the cost of being wrong is greater than the cost of deliberation** — especially when the solution space is wide, failure modes are hidden, you may be anchored on a design, or rollback would be hard. Examples:\n\narchitecture decisions with non-obvious tradeoffs, plan or design review before commitment, pre-launch pressure tests, stuck debugging after N failed repair attempts, pre-commit adversarial review on risky diffs, memory/skill promotion gates, strategy questions with multiple defensible framings, explicit user requests.\n\nIf you authored the plan or code under review, that's a reason FOR a panel, not against it — the author is the worst-positioned reviewer of their own work.\n\nSkip mumo for factual lookups, syntax help, routine refactors, formatting, dependency bumps wi"},{"path":"README.md","content":"# mumo — OpenClaw skill\n\n**Multi-model deliberation panel for OpenClaw.** When OpenClaw is about to make an architecture choice, design tradeoff, or security-sensitive change — a question worth checking across labs — mumo runs a panel of frontier models in parallel (Claude, GPT, Gemini, Grok, DeepSeek, Kimi, and more) and returns each model's full response plus typed cross-model reactions — what each model keeps, challenges, or wants explored in the others' claims.\n\n## What's in the box\n\n- **`SKILL.md`** — the canonical skill teaching OpenClaw how to use mumo: when to invoke, the deliberation loop (create → wait → read → snippet → append/stop), how to read claim maps, snippet doctrine, and when to verify session creation.\n- **`playbooks/`** — four cognitive-shape playbooks loaded on demand: `contested-decision`, `design-review`, `uncertainty-expansion`, `red-team`.\n- **`references/`** — five reference docs: `claim-maps`, `snippets`, `model-selection`, `synthesis`, `operating-notes`.\n- **`config/mumo.example.json`** — the MCP server config payload to paste into `openclaw mcp set mumo` (reference only; OpenClaw does not auto-load this file).\n\n## Install\n\n### 1. Get an API key\n\nSign up at [mumo.chat](https://mumo.chat) and create a platform key at [Settings → API Keys](https://mumo.chat/settings/api-keys). Keys start with `mmo_live_`.\n\n### 2. Register the mumo MCP server\n\nOpenClaw stores outbound MCP servers in `~/.openclaw/openclaw.json` under `mcp.servers.<name>`. Put your key in `~/.openclaw/.env` first, so it never lands in the config file. Create that file and restrict it *before* putting anything in it, so the key is never written into a world-readable file:\n\n```bash\ntouch ~/.openclaw/.env && chmod 600 ~/.openclaw/.env\n```\n\nThen open `~/.openclaw/.env` in your editor and add a line:\n\n```\nMUMO_API_KEY=mmo_live_your_key_here\n```\n\nEdit the file rather than appending from the shell: a command containing the literal key is recorded in your shell history, and running it twice silently stacks a duplicate entry.\n\nNow register mumo, referencing the variable rather than the key:\n\n```bash\nopenclaw mcp set mumo '{\n  \"url\": \"https://mumo.chat/api/mcp\",\n  \"transport\": \"streamable-http\",\n  \"headers\": {\n    \"Authorization\": \"Bearer ${MUMO_API_KEY}\"\n  }\n}'\n```\n\nOpenClaw resolves `${MUMO_API_KEY}` when it connects, and warns at startup if the variable is missing — so a rotated or unset key surfaces as a named config warning instead of a silent 401. The same JSON shape ships in this repo at `config/mumo.example.json` for reference. Verify it landed:\n\n```bash\nopenclaw mcp list\nopenclaw mcp show mumo\n```\n\n### 3. Install the skill\n\nThe fastest path is via ClawHub, OpenClaw's skill registry:\n\n```bash\nopenclaw skills install mumo\n```\n\nThat pulls [`mumo` from ClawHub](https://clawhub.ai/ericatmumo/mumo) into the **active workspace's** `skills/` directory — the one inferred from your current directory, or your default agent. Use `--agent <id>` to target a different age"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn783a0ds5gfqhdrt955qfc96s866t5g\",\n  \"slug\": \"mumo\",\n  \"version\": \"0.6.2\",\n  \"publishedAt\": 1788965212315\n}"},{"path":"references/claim-maps.md","content":"# Claim Maps\n\nThe claim map is the structured output of each round. It shows which claims were made, who originated them, and how other models reacted.\n\n## Reading order\n\nRead the claim map before diving into full prose. The map tells you *where* the interesting structure is; prose tells you *why*. If you read prose first, you can anchor on whichever model writes most persuasively.\n\nException: in small sessions with only a few claims, read however is natural.\n\n## What a claim row contains\n\n- **The quoted claim** — a specific passage from a model's response.\n- **The quoted model** — who originated the claim.\n- **Reactions** — how other models (and the moderator, in later rounds) reacted, each with a snippet type and optional comment.\n\nAgreement shows as multiple KEEP/CORE reactions on the same claim. Disagreement shows as CHALLENGE reactions. Isolated claims have few or no reactions.\n\nReactions are visible to you and the user, not to the other participants — each model sees only its own prior reactions (as private notes to weave into its next response) plus everyone's prose. The claim map is your privileged view of the full ledger; see the kernel's \"Reactions are in the ledger, responses are on the record\" section for how to steer with it.\n\n## Continuation signals\n\nThe claim map is your primary signal for whether to continue.\n\n**Continue when:**\n- A decision-relevant claim has unresolved CHALLENGE reactions.\n- A promising claim has no reactions — it was raised but not engaged with.\n- A SHIFT reaction suggests a model changed its position, but the implications haven't been explored.\n\n**Stop when:**\n- Key claims show convergent reactions (mostly KEEP/CORE).\n- Remaining disagreements are on claims that don't affect the decision.\n- The map is stable across rounds — same claims, same positions, no movement.\n\nDon't continue just because unresolved claims exist. Only unresolved claims on the decision-relevant subset warrant another round. Peripheral disagreements are noise, not signal.\n\n## Snippet selection from the claim map\n\nUse the claim map to decide where to focus, then choose exact quotes from the prose.\n\nGood targets:\n- Claims that multiple models reacted to differently.\n- Claims that one model challenged and others ignored.\n- Isolated claims that seem important.\n- Shifts in framing.\n- Core constraints that need anchoring.\n\n## Attribution accuracy\n\nIf two participants say the same thing, the claim map must not imply the words came from only one. If attribution is unknown, it should stay unknown rather than be guessed.\n\nMisattribution is worse than a slightly less dense map because users can audit snippets against raw responses.\n\n## Claim maps are not verdicts\n\nThe map compresses argumentative structure but loses rhetorical nuance and confidence texture. It's a map of where attention clustered, not a ruling on who's right. Use it to navigate, then read the prose to understand."},{"path":"references/model-selection.md","content":"# Model Selection\n\nDefault behavior: omit `models` and let mumo select the panel. mumo's defaults evolve as model quality and pricing change. Hardcoded model strategy in the skill will go stale.\n\n## When to call `list_models`\n\n- The user names specific models.\n- The user asks for a cheap gut-check or a premium panel.\n- A previous call failed because a model was unavailable.\n- You need to confirm model IDs.\n\n## Selection principles\n\nWhen selecting yourself:\n\n- **Provider diversity over intra-family differences.** A panel with models from three different providers is more valuable than three variants from one.\n- **Include your own family only when the user wants it** or the comparison specifically benefits from it. You're already in the conversation as moderator.\n- **Avoid nano/fast variants for high-stakes decisions** unless the user explicitly prioritizes cost.\n- **Don't present model choice as a leaderboard judgment.** You're picking for diversity, not ranking.\n\n## Cost awareness\n\n`get_credit` is useful when balance is uncertain or the user asks about cost.\n\nDon't make cost preflight a default ritual before every deliberation — it creates friction and can bias agents away from using mumo when the task genuinely warrants a panel.\n\nIf cost is part of the user's problem, translate it into problem context:\n\nGood: \"Assume this workflow can afford at most one additional model call per important decision.\"\nWeak: \"The previous mumo round cost $0.34.\"\n\nFrontier panels typically cost $0.20-0.60 per round. Mid-tier panels are significantly cheaper."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":2238,"uniquenessScore":43,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T20:38:00.188Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T20:38:00.188Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T22:47:37.999Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}