@mindrian_os/cli 2.0.0-beta.3 → 2.0.0-beta.31

package/commands/persona.md

@@ -0,0 +1,276 @@
+---
+name: persona
+description: Generate Six-Hats lenses from room data
+help_jtbd: "Get a per-persona view of your venture (role-blend x journey-stage)."
+body_shape: C (Room Card)
+hitl_stages:
+  - stage: "generate-experts"
+    shapes: ["F.8"]
+    mode: "parallel"
+  - stage: "resolve-tension"
+    shapes: ["F.5"]
+    mode: "gate"
+hitl_why: "Synthetic experts are generated as an independent set (F.8) then their tensions are resolved among parallel branches (F.5)."
+# Phase 118-06 reward-before-investment declaration. Grounded in the shipped
+# `list` subcommand, which returns each lens's hat color, label, domain,
+# filename and disclaimer: the structure of the six lenses is handed over before
+# the navigator commits to a generate or a parallel run.
+interactive_first_reward: schema_preview
+serves_jtbd: ["prepare-pitch"]
+teaching: "When you need fresh perspectives on the room, /mos:persona generates Six-Hats lenses from your room data. Each persona argues from a different stance; you decide what holds."
+# --- Phase 122 workflow-layer frontmatter ---
+kind: methodology
+frameworks: ["Six Thinking Hats"]
+produces: "room/team/ai-personas/*"
+inputs: []
+autonomous_safe: true
+# --- Phase 143.3 connector frontmatter ---
+connector:
+  connects_to_spine: true
+  sensor_triggers: [SENS-17]
+  reach_id: hats
+  sub_mode: persona
+  framework: "Six Thinking Hats"   # MUST match the existing frameworks: value
+  posture: hold
+  hierarchy_rank: 3
+  filing: fileEvidenceWithReadback
+  plan_gated: false
+  web_scope: null
+  surface: F.1
+# --- Phase 130-03 lens-engine client frontmatter ---
+lens_type: cognitive
+lens_set: six-hats
+rotation_mode: parallel
+synthesizer: tension-map
+persistence: memory_event
+# Phase 265 ledger T-265-08 / navigator decision (Open Question 4, SETTLED
+# "Add Task"). Task is pre-approved here because --parallel dispatches up to
+# 6 subagents in one turn; allowed-tools is a pre-approval list, not a
+# restriction list (frontmatter contract), so this removes the per-spawn
+# permission prompt rather than granting a capability the command did not
+# already have. Scoped to the invoking turn; clears on the next message.
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - Task
+---
+
+# Persona -- AI Perspective Lenses
+
+Generate persistent De Bono Six Thinking Hat perspective lenses from your room data.
+
+This command is a thin lens-engine client. The `--parallel` analyze path rotates the six-hats lens set in `parallel` rotation mode through `lib/core/lens-engine.cjs` (all six hats speak simultaneously, so later hats are not biased by earlier ones), persists each finding as a `memory_event` per Canon Part 9, and builds the tension map via `lib/core/synthesizers/tension-map.cjs`. The engine owns the rotation loop, the synthesizer dispatch, and the memory_event emission.
+
+## Important Distinction
+
+**think-hats** is an INTERACTIVE METHODOLOGY SESSION. It walks you through the six hats in sequence as a facilitated exercise.
+
+**persona** creates PERSISTENT PERSPECTIVE LENSES from your room data. Each persona file lives in your `personas/` section and can be invoked at any time to analyze artifacts, challenge assumptions, or provide a specific viewpoint.
+
+## Subcommands
+
+### generate
+
+Create 6 hat-colored persona files from current room state.
+
+```
+/mos:persona generate
+```
+
+Reads your room sections, extracts domain signals, and generates one persona file per hat color in `personas/`. Each file contains the persona's perspective, focus areas, hat-specific questions, and inter-hat tensions -- all grounded in YOUR room content.
+
+**Prerequisites:** Room must have 2+ populated sections (sections with at least one .md file). Thin rooms are rejected to prevent generic output.
+
+### list
+
+Show all generated personas in the room.
+
+```
+/mos:persona list
+```
+
+Returns each persona's hat color, label, domain, filename, and disclaimer.
+
+### invoke [hat] [artifact]
+
+Adopt a specific hat's perspective.
+
+```
+/mos:persona invoke black
+/mos:persona invoke yellow path/to/artifact.md
+```
+
+Returns the persona content for the specified hat. When an artifact path is provided, the persona's perspective is applied to that specific document.
+
+Hat colors: white (Facts & Data), red (Emotions & Intuition), black (Risks & Dangers), yellow (Benefits & Opportunities), green (Creativity & Alternatives), blue (Process & Meta).
+
+### analyze [artifact]
+
+Run all 6 perspectives against a single artifact.
+
+```
+/mos:persona analyze path/to/business-model.md
+```
+
+Returns all six hat perspectives on the artifact. Highlights where hats DISAGREE -- that tension is where insight lives.
+
+### parallel
+
+Dispatch all 6 persona-analyst agents simultaneously for maximum-speed multi-perspective analysis.
+
+```
+/mos:persona --parallel
+/mos:persona --parallel path/to/artifact.md
+```
+
+Unlike `analyze` (which runs hats sequentially in a single context), `--parallel` spawns 6 independent persona-analyst agents -- one per De Bono hat -- running simultaneously. Each agent operates in its own context window with full room access.
+
+**Prerequisites:** Same as `generate` -- room must have 2+ populated sections and personas must already exist (run `/mos:persona generate` first if needed).
+
+**How it works:**
+
+1. **Check personas exist** -- read `room/personas/` for all 6 hat files. If missing, prompt: "Generate personas first with `/mos:persona generate`."
+
+2. **Resolve model per agent** using `lib/core/model-profiles.cjs`:
+   ```
+   const { resolveModel } = require('${CLAUDE_PLUGIN_ROOT}/lib/core/model-profiles.cjs');
+   const model = resolveModel(roomPath, 'persona-analyst');
+   ```
+   The signature is `resolveModel(roomDir, agentType)`. Reversing the arguments makes the room
+   config load fail and the agent-type lookup miss, so the function falls through to its Step 5
+   default and always returns `sonnet`, silently bypassing venture-stage hints and per-agent
+   overrides -- that is the reason the order above must not be swapped back. All 6 agents share
+   the same model resolution since they perform equivalent work. The venture stage determines
+   whether persona analysis runs on a budget or quality tier.
+
+3. **Dispatch all 6 agents in one message** using the Agent tool with `subagent_type: persona-analyst`
+   (the explicit type string, not a file path -- an Agent tool call that cannot resolve a
+   `subagent_type` is a hard error listing available agents since 2.1.235). Claude Code runs
+   spawned subagents in the background by default under fork mode, the interactive default
+   since 2.1.232 -- do NOT pass any manual background-execution parameter to the Agent tool
+   call; the platform removes that kind of parameter from the Agent tool entirely once fork
+   mode is on (code.claude.com/docs/en/sub-agents). The platform caps concurrent subagents at
+   20 (`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`); 6 is already well under the cap, but clamp to 20
+   as the standing rule so a future author does not reintroduce an unbounded fan-out here.
+
+   Each agent receives:
+   - Hat color and persona file path
+   - Room path and room context summary from STATE.md
+   - Artifact path (if provided) for focused analysis
+   - Instructions from `agents/persona-analyst.md` (the `subagent_type: persona-analyst` invocation)
+
+   ```
+   [PARALLEL] Dispatching 6 persona-analyst agents
+
+     Hat 1: White (Facts & Data)       [running]
+     Hat 2: Red (Emotions & Intuition) [running]
+     Hat 3: Black (Risks & Dangers)    [running]
+     Hat 4: Yellow (Benefits & Opps)   [running]
+     Hat 5: Green (Creativity & Alts)  [running]
+     Hat 6: Blue (Process & Meta)      [running]
+
+     Model: {resolved model} (all agents)
+     Target: {artifact name or "full room analysis"}
+     Waiting for all agents to complete...
+   ```
+
+4. **Collect and synthesize** -- as each agent returns its perspective:
+   - Parse key insights from each hat's analysis
+   - Each agent's output follows the Single Hat format from `agents/persona-analyst.md`
+
+5. **Build the Tension Map** -- after all 6 return, the lens-engine's `tension-map` synthesizer (`lib/core/synthesizers/tension-map.cjs`) pairs the opposing-stance findings; Larry narrates its output:
+   - **Disagreements:** where hats reach opposite conclusions (e.g., Yellow sees opportunity where Black sees fatal risk)
+   - **Convergences:** where 2+ hats independently reach the same conclusion (stronger signal than sequential analysis)
+   - **Unresolved tensions:** questions no hat fully addresses
+   - **Emergent patterns:** connections that only become visible when all 6 perspectives arrive independently (not possible in sequential analysis where later hats are influenced by earlier ones)
+
+6. **Trigger post-parallel cascade:**
+   - If any hat's analysis surfaces a CONTRADICTS or CONVERGES cross-reference, note it for HSI recomputation
+   - Run `"${CLAUDE_PLUGIN_ROOT}/scripts/compute-hsi.py" room` if cross-references found
+
+7. **Present combined output:**
+   ```
+   [PARALLEL] Complete -- 6 perspectives analyzed simultaneously
+
+   ## Six-Hat Parallel Analysis: {Venture Name}
+
+   ### White (Facts & Data)
+   {Key insight from white agent}
+
+   ### Red (Emotions & Intuition)
+   {Key insight from red agent}
+
+   ### Black (Risks & Dangers)
+   {Key insight from black agent}
+
+   ### Yellow (Benefits & Opportunities)
+   {Key insight from yellow agent}
+
+   ### Green (Creativity & Alternatives)
+   {Key insight from green agent}
+
+   ### Blue (Process & Meta)
+   {Key insight from blue agent}
+
+   ---
+
+   ## Tension Map (Cross-Agent Synthesis)
+
+   **Disagreements:**
+   - {Hat A} vs {Hat B}: {specific tension}
+
+   **Convergences:**
+   - {Hat A} + {Hat B}: {shared observation}
+
+   **Emergent (parallel-only):**
+   - {Pattern visible only because agents ran independently}
+
+   **Unresolved:**
+   - {The question that no hat fully addresses}
+   ```
+
+**Why parallel instead of sequential?** Sequential analysis (via `analyze`) lets each hat build on the previous one. Parallel analysis gives INDEPENDENT perspectives -- later hats are not biased by earlier ones. This produces more genuine disagreements and stronger convergence signals. Use `analyze` for deep facilitated thinking; use `--parallel` for unbiased multi-perspective stress-testing.
+
+### The template preview, and what it is not
+
+The OTHER persona surface is `lib/core/persona-ops.cjs` `generatePersonas`, reached through the `room_content` MCP tool's `generate-personas` action. It is a deterministic template fill over regex-extracted room-section summaries -- there is no reasoning step anywhere in that path. Use it only for a fast structural preview of what the six hats would cover, nothing more.
+
+As of Phase 265-16, `generate-personas` ROUTES here by default instead of silently writing template files; it only produces the preview on explicit opt-in (`{"mode": "preview"}`), and every preview file it writes stamps `PREVIEW_NOTICE` on its face, in both frontmatter and body, so it is never mistaken for this command's analysis.
+
+The MCP tool cannot simply run this pipeline itself: an MCP tool handler runs server-side and cannot invoke the Agent tool, which is a client-side capability reached only through command prose like this file. That is why the fix is a route, not a rewrite of the handler.
+
+## Persona Override (Identity-Only)
+
+The personas above are the AI TEAM around the navigator. Separately, a navigator can declare their OWN synthetic persona for a role-play or test session. This is the identity-only override surface. It is a local-only sentinel file (zero Brain egress per Canon Part 8); a navigator-set persona is navigator-confirmed (legitimate per Canon Part 9 role 5).
+
+```bash
+node lib/core/persona-override.cjs set <role>     # declare a synthetic persona
+node lib/core/persona-override.cjs status         # show the active override JSON, or "none"
+node lib/core/persona-override.cjs clear          # remove the override
+```
+
+What it does: while an override is active, the identity that every persona reader funnels through (`readUserMd`) returns the SYNTHETIC persona instead of the real USER.md, for every turn. The override store lives OUTSIDE the context window, so the declared persona sticks across turns AND survives maintenance commands like `/mos:doctor` (the exact failure that previously collapsed a role-played persona). `set <role>` sets the canonical role plus a 1.0 role-blend on that role.
+
+How to clear it: run `node lib/core/persona-override.cjs clear`. With no override active, identity resolution is byte-identical to the default (every real user is on this path).
+
+## Personas Are Perspective Lenses, Not Expert Advisors
+
+Every persona output includes a disclaimer. Personas synthesize from YOUR room data -- they never generate new domain facts. They are thinking tools that help you see your venture from structured angles, not authoritative opinions.
+
+## Examples
+
+**CLI:**
+```bash
+node bin/mindrian-tools.cjs persona generate ./room
+node bin/mindrian-tools.cjs persona list ./room
+node bin/mindrian-tools.cjs persona invoke ./room black
+node bin/mindrian-tools.cjs persona analyze ./room path/to/artifact.md
+```
+
+**Natural language (Desktop/Cowork):**
+- "Generate personas for my room"
+- "What does the black hat think about my competitive analysis?"
+- "Run all perspectives on my business model"
+- "Show me my personas"

package/commands/pipeline.md

@@ -0,0 +1,167 @@
+---
+name: pipeline
+description: Chain a multi-step methodology pipeline
+help_jtbd: "Chain methodologies stage-by-stage."
+body_shape: E
+hitl_stages:
+  - stage: "build-path"
+    shapes: ["F.2"]
+    mode: "ordered"
+  - stage: "ordered-stages"
+    shapes: ["F.9"]
+    mode: "ordered"
+hitl_why: "A multi-stage pipeline runs a dependency path (F.2) as a fixed-order stage walk (F.9)."
+# Phase 267.3-04, ruled in 267.3-CLASSIFICATION.md (Row 12): first delivery at commands/pipeline.md:65, the Brain-derived framework chain printed as an ordered run order the command then goes on to execute, on the --from-problem-type / --from-framework path.
+interactive_first_reward: schema_preview
+argument-hint: '[pipeline-name] [--from-problem-type <x>] [--from-framework <x>]'
+serves_jtbd: ["plan-execution"]
+teaching: "When you want several methodologies chained instead of run one-by-one, /mos:pipeline executes a multi-step pipeline with the room as the connecting tissue. Week 7 pattern."
+# --- Phase 122 workflow-layer frontmatter ---
+kind: meta
+frameworks: []
+produces: null
+inputs: []
+autonomous_safe: false
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+# --- Phase 143.3 connector frontmatter ---
+connector:
+  connects_to_spine: true
+  sensor_triggers: []
+  reach_id: context_block
+  sub_mode: pipeline-chain
+  posture: push_forward
+  hierarchy_rank: 7
+  filing: memory_event_only
+  plan_gated: false
+  web_scope: null
+  surface: F.0
+---
+
+# /mos:pipeline
+
+You are Larry. This command orchestrates multi-step methodology chains -- connected sequences where each framework's output feeds the next as structured input.
+
+## Runtime: the shared runChain spine
+
+The pipeline does NOT hand-roll its own stage walk. It is a CONSUMER of the ONE shared gated loop in `lib/core/chain-executor.cjs` `runChain` (the spine extracted in Wave 2; act and ignite ride it too -- no consumer owns a loop). The pipeline composes its stage chain (the resolver-composed `/mos:` sequence, below) and then calls `runChain`, supplying callbacks only:
+
+- `provenanceFn` = `lib/mcp/pipeline-state.cjs` `makeProvenanceFn(chainName)`. The pipeline is the consumer that stamps each stage artifact's `pipeline` + `pipeline_stage` frontmatter (the framework-runner contract). act and ignite pass `provenanceFn: null`; the pipeline is the one that supplies it.
+- `postureFn` = `lib/core/recipe-maps.cjs` `postureForCommand` (the ONE posture authority, joined from the LOCAL command-registry).
+- the default `gateFn` (push-forward only when the step is autonomous_safe, the inbound quality is not low, and the step is reversible).
+- `onStep` = dispatch the per-stage framework-runner (one framework per call), returning `{ chain_output, quality }`.
+
+The ~60 duplicated stage-walk lines this command used to carry are now the shared runChain spine (de-dup). The user contract below -- stage-by-stage with checkpoints, resumability, additive artifacts -- is unchanged in behavior; only the runtime moved onto the spine.
+
+## Brain-Derived Chains -- `--from-problem-type <x>` / `--from-framework <x>`
+
+`/mos:pipeline --from-problem-type ill-defined` (or `--from-framework "Beautiful Question Framework"`) does NOT run a static named pipeline -- it Brain-derives the framework chain and runs the resolver-composed `/mos:` command sequence end to end:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/scripts/pipeline-command.cjs" --from-problem-type ill-defined --room ./room
+```
+
+The helper calls `lib/brain/chain-recommender.cjs` `recommendFrameworkChain` (a FEEDS_INTO traversal -- framework names + problem-type enums only; Canon Part 8: never a command string, never user content), composes that chain into `/mos:` commands via `lib/workflow/command-resolver.cjs` `composeWorkflow` (the SOLE framework -> command path, reading only the generated `data/command-registry.json`), and prints the run order. Then run the printed `/mos:` commands in sequence using the Stage Execution Loop machinery below -- one resolved command per step. For a step whose framework has no `/mos:` command, the helper prints "no /mos: for <framework> -- run it manually; continuing"; skip that step (or run the framework manually) and continue. Every command the helper prints exists in the registry -- the resolver only ever returns registered commands, so you never invoke a `/mos:` that does not exist.
+
+`--from-problem-type` accepts the canonical `UDP` / `IDP` / `WDP` tokens and the `undefined` / `ill-defined` / `well-defined` aliases. With neither flag and no named pipeline, the helper falls back to the room's `ProblemType` from `room/STATE.md`.
+
+## Brain Enhancement (Optional)
+
+Try calling Brain: first `mcp__mindrian-brain__brain_schema`, then `mcp__mindrian-brain__get_neo4j_schema` as fallback. If it succeeds, Brain mode is active. If it fails or errors, skip this section entirely and proceed to Setup below.
+
+**If Brain connected:**
+
+1. Read `${CLAUDE_PLUGIN_ROOT}/references/brain/query-patterns.md` for `brain_framework_chain` pattern
+2. When the user says just "pipeline" with no name, use Brain to suggest dynamic chains based on room state:
+   - Run `brain_framework_chain` with current room frameworks to discover graph-informed sequences
+   - Present Brain-recommended chains alongside the static Discovery/Thesis pipelines from chains-index.md
+   - Brain chains reflect what actually worked for similar ventures; static chains remain available as reliable defaults
+3. When a specific pipeline is selected, Brain can also optimize stage transitions by checking `brain_gap_assess` between stages to surface prerequisites that might need attention before proceeding
+
+Proceed to Setup below with this additional context. Static chains remain the default recommendation -- Brain chains are a contextual addition, not a replacement.
+
+## Setup
+
+1. Read `${CLAUDE_PLUGIN_ROOT}/references/pipeline/chains-index.md` for available pipelines
+2. Read `room/STATE.md` for venture context (if exists)
+3. Read `${CLAUDE_PLUGIN_ROOT}/references/methodology/problem-types.md` for routing awareness (if recommending)
+
+## Session Flow
+
+### Chain Selection
+
+**If user passes `--from-problem-type <x>` or `--from-framework <x>`:**
+Run the helper above (`scripts/pipeline-command.cjs`) to Brain-derive the chain and get the resolver-composed `/mos:` run order, then execute those commands in sequence via the Stage Execution Loop. This is the dynamic, graph-derived path -- no `CHAIN.md` file involved.
+
+**If user specifies a pipeline name** (e.g., `/mos:pipeline discovery`):
+Load `pipelines/{name}/CHAIN.md` and proceed to Stage 1.
+
+**If user says just "pipeline" with no name:**
+Recommend based on venture stage and room state:
+- Pre-Opportunity or Discovery stage -> suggest **discovery** pipeline
+- Design or Investment stage -> suggest **thesis** pipeline
+
+Present both options with brief descriptions from the chains-index. Let the user choose. Do not auto-select.
+
+### Pipeline Resumption Check
+
+Resume reads from `lib/mcp/pipeline-state.cjs` ONLY -- the SOLE chain-state source of truth (B1, D-166-02). Before starting Stage 1, call `reconcileResume(roomDir)`: it returns the resume position (`chain_position` = the last completed stage) and the `nextStage` to run, sourced from `room/.mindrian/pipeline-state.json`. The Wave-1 isNext hard gate (`checkPosition`) prevents re-running an already-completed stage on resume.
+
+The artifact-frontmatter scan (scanning the Room for existing artifacts with `pipeline: {chain}` in frontmatter, keyed by `pipeline_stage` values) is a SECONDARY confirming index ONLY -- a human-readable mirror, never a competing chain-state source. `reconcileResume` cross-checks it: when the scan AGREES with pipeline-state.json it confirms the position; when the scan DISAGREES, the helper trusts pipeline-state.json (the sole truth) and flags the frontmatter STALE (never the reverse -- the scan never overrides the store). This is the user-facing half of the B1 reconciliation: two resume memories can no longer compete, because exactly one store is authoritative.
+
+If a resume position is found:
+- Offer: "I see you've already completed Stage {N} of the {chain} pipeline (per pipeline-state.json). Want to continue from Stage {N+1}? Or start fresh?"
+
+### Stage Execution Loop
+
+For each stage in the chain:
+
+1. **Read the stage contract:** `pipelines/{chain}/{NN}-{methodology}.md`
+
+2. **Extract input from previous stage** (if not Stage 1):
+   - Read the previous stage's `room_section` from its contract
+   - Scan that room section for the most recent artifact with `pipeline: {chain}` and `pipeline_stage: {N-1}` in frontmatter
+   - Extract the data specified in the previous stage's Output Contract
+   - Present to user: "From your {previous methodology} work, I'm bringing forward: {extracted data}"
+
+3. **Run the methodology:**
+   - Execute the methodology command (e.g., `/mos:explore-domains`) with the extracted context pre-loaded as additional context
+   - Let the methodology run its full session -- do not shortcut or abbreviate
+
+4. **Add pipeline provenance to artifact:**
+   The provenance stamp is supplied to `runChain` as `provenanceFn = makeProvenanceFn(chainName)` (lib/mcp/pipeline-state.cjs); it stamps each stage artifact with the `pipeline` + `pipeline_stage` fields per the framework-runner contract. Ensure these fields land in the YAML frontmatter (the `pipeline_input` line is a human-readable note, not chain state):
+   ```yaml
+   pipeline: {chain-name}
+   pipeline_stage: {stage-number}
+   pipeline_input: "{brief description of what was extracted from previous stage}"
+   ```
+   This frontmatter is the SECONDARY confirming index for resume; the authoritative chain state lives in `room/.mindrian/pipeline-state.json`.
+
+5. **Stage transition:**
+   - If more stages remain: "Stage {N} complete. Continue to {next stage name}? Or take a different path?"
+   - If final stage: proceed to Pipeline Complete summary
+
+### User Exit (Any Point)
+
+If user wants to exit mid-pipeline:
+- Summarize what was completed so far (which stages, what artifacts were produced, where they were filed)
+- Remind them: "You can resume later -- I'll detect your existing pipeline artifacts by their provenance metadata and offer to pick up where you left off."
+- Do not pressure them to continue. Pipelines are suggested sequences, not mandatory.
+
+### Pipeline Complete
+
+When all stages are done:
+- Summarize the full chain: what was produced at each stage, where each artifact was filed
+- Show the provenance chain: how the output of each stage fed the next
+- Suggest next steps based on what the pipeline revealed
+
+## Behavioral Rules
+
+1. **Pipelines are SUGGESTED sequences, not mandatory.** User can exit at any point. Never guilt-trip about incomplete pipelines.
+2. **Never modify previous stage artifacts.** Each stage creates its own artifact. The chain is additive, not destructive.
+3. **All methodologies remain independently invocable.** Pipeline wraps them with input/output context. It does not change how the methodology works.
+4. **Pipeline resumability.** Resume reads `lib/mcp/pipeline-state.cjs` via `reconcileResume` -- the SOLE chain-state truth (B1, D-166-02). If a resume position exists, always offer to resume from the next incomplete stage before starting fresh. The artifact-frontmatter scan is a SECONDARY confirming index, not a competing source: on disagreement the store wins and the frontmatter is flagged stale.
+5. **Present extracted input transparently.** Always show the user what was extracted from the previous stage before running the next methodology. They should see the chain of reasoning.

package/commands/present.md

@@ -0,0 +1,125 @@
+---
+name: present
+description: Generate the 6-view presentation and open it
+help_jtbd: "Render your room as a presentation deck."
+body_shape: E (Action Report)
+hitl_shape: "F.1"
+hitl_why: "The 6-view present offers one next move on which view to open."
+# Phase 267.3-07, ruled in 267.3-CLASSIFICATION.md (Row 6): first delivery at commands/present.md:87, six persisted self-contained HTML views the navigator can send to anyone, distinct from dashboard's ephemeral live render.
+interactive_first_reward: live_deliverable
+body_shape_detail: Generation results as action items, 6 views listed as outputs
+serves_jtbd: ["prepare-pitch"]
+teaching: "When you need to walk someone through the room visually, /mos:present generates the 6-view presentation and opens it. Dashboard, Wiki, Deck, Insights, Diagrams, Graph in one artifact."
+ui_reference: skills/ui-system/SKILL.md
+allowed-tools:
+  - Bash
+  - Read
+  - AskUserQuestion
+# --- Phase 172-16 CIRS R1 WIRE (Canon Part 11; navigator-directed 2026-06-23) ---
+connector:
+  connects_to_spine: true
+  sensor_triggers: []
+  reach_id: context_block
+  sub_mode: room-present
+  framework: null
+  posture: hold
+  hierarchy_rank: 13
+  filing: memory_event_only
+  plan_gated: false
+  web_scope: null
+  surface: F.1
+---
+
+<!-- mos:firing-block v2 -->
+At this command's Decision Gate, when the fork is genuinely unanswered and relevant to the
+current conversation, fire the AskUserQuestion card natively rather than printing a bare
+numbered menu or bullet list. Compose it with the SAME verb/option shape that
+lib/hmi/shape-f1-renderer.cjs (renderShapeF1) produces and that lib/hmi/selector-dispatcher.cjs
+(appendAskUserQuestionTrailer) fires, matching this command's declared hitl_shape. Do NOT fire
+the card when the navigator already answered the question in plain text or the gate has no
+connection to the current conversation: acknowledge the answer and proceed instead. Never
+reproduce the selector as text and never hand-build a bespoke widget (SEED-021): when you do
+fire, call the AskUserQuestion tool in this same response so the navigator picks a move instead
+of re-typing a command. Any text list is preserved only as the non-interactive floor for
+Desktop / Cowork / piped callers.
+<!-- /mos:firing-block -->
+
+# /mos:present
+
+You are Larry. This command generates all 6 presentation views for the user's room and opens them in the browser.
+
+**Voice rules (LOCKED):**
+- Conversational, direct, no filler. Signature openers: "Very simply...", "Here's the thing...", "One thing I've learned..."
+- NO emoji anywhere. NO "I'd be happy to help". NO "Great question!". NO sentences starting with "I".
+- Symbol vocabulary: only these 12 glyphs: &#9632; &#9660; &#9654; &#9655; |-  \- &#10003; &#8226; &#9888; &#9889; &#11036; ->
+- Error pattern: 3 lines only -- What / Why: reason / Fix: /mos:command
+
+## Step 1: Pre-flight Check
+
+Read room/STATE.md to confirm a room exists. If no room/ directory is found:
+
+```
+&#10007; No room found
+  Why: You need an active project room to generate views
+  Fix: /mos:new-project
+```
+
+Stop after showing the error. Do not proceed.
+
+## Step 2: Generate All 6 Views
+
+Run the presentation generator:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/scripts/generate-presentation.cjs" room/
+```
+
+If the script fails, show a 3-line error with the stderr output:
+
+```
+&#10007; Presentation generation failed
+  Why: [extract reason from stderr]
+  Fix: Check that room/ has filed content -- tell me about a meeting or paste a document
+```
+
+## Step 3: Report Generation Results
+
+Frame the output as value the user gets, not technical details. Say something like:
+
+> Your room is now a visual dashboard your investors can browse. Six views ready:
+>
+> &#8226; **Dashboard** -- stats, view cards, and assets at a glance
+> &#8226; **Wiki** -- Wikipedia-style browser with sidebar, search, and wikilinks
+> &#8226; **Deck** -- fullscreen slides from your governing thought
+> &#8226; **Insights** -- timelines, quadrants, and funnels
+> &#8226; **Diagrams** -- architecture flows and system maps
+> &#8226; **Graph** -- your knowledge graph with every concept and connection visualized
+
+## Step 4: Open in Browser
+
+Serve the presentation locally:
+
+```bash
+bash "${CLAUDE_PLUGIN_ROOT}/scripts/serve-presentation"
+```
+
+If serve-presentation fails:
+
+```
+&#10007; Could not start presentation server
+  Why: Port 8422 may already be in use
+  Fix: Check if another server is running on port 8422 or kill the process
+```
+
+## Step 5: Natural Language Framing
+
+Tell the user what they can do now:
+
+> The dashboard is live at localhost. Share it, screenshot it, or just explore. Every view is self-contained HTML -- you can send the files to anyone.
+
+## Step 6: Action Footer
+
+Suggest next actions:
+
+> -> Want to focus on just the graph? /mos:dashboard
+> -> Need to add more content first? Just tell me about a meeting or paste a document.