mirror-mind 0.0.1 → 0.33.0

package/.pi/skills/mm-journey/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: "mm-journey"
+description: Shows detailed journey status and optionally updates the journey path
+user-invocable: true
+---
+
+# Journey
+
+When receiving `/mm-journey [slug]`: answered by the TS core (CV22.DS7.US1).
+
+```bash
+mirror journey [slug]
+```
+
+When receiving `/mm-journey update <slug> <content>`: answered by the TS core (CV22.DS7.US1).
+
+```bash
+mirror journey update <slug> "<content>"
+# or pipe via stdin:
+echo "<content>" | mirror journey update <slug> -
+```
+
+Present the output to the user.

package/.pi/skills/mm-journeys/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: "mm-journeys"
+description: Lists existing journeys with status and current stage
+user-invocable: true
+---
+
+# Journeys
+
+When receiving `/mm-journeys`:
+
+```bash
+mirror journeys
+```
+
+The script prints a compact hierarchical list of all journeys, including parent/child indentation when configured. Present the output without modification so the hierarchy remains intact.

package/.pi/skills/mm-memories/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: "mm-memories"
+description: Lists memories with filters by type, layer, and journey
+user-invocable: true
+---
+
+# Memories
+
+When receiving `/mm-memories [--type TYPE] [--layer LAYER] [--journey SLUG] [--search "text"] [--limit N]`:
+
+```bash
+mirror memories [args]
+```
+
+The TS front door routes memory listing **and** fresh semantic search to the TS core (CV22.DS8.US1). With `OPENROUTER_API_KEY` set, `--search` runs a live embedding through TypeScript; without a key it degrades to lexical-only search, printing the same note the Python engine prints.
+
+Present the output to the user without modification.

package/.pi/skills/mm-mirror/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: "mm-mirror"
+description: Activates Mirror Mode — loads identity, persona, attachments, and records response
+user-invocable: true
+---
+
+# Mirror Mode
+
+Activates `◌ Mirror Mode`, the identity lens of Mirror. `CLAUDE.md` routing
+determines when to activate it; this skill defines how.
+
+---
+
+> ⛔ **HARD CONSTRAINT**
+> Never produce a Mirror Mode response without first running `mirror mirror load`.
+> No exceptions. Load first. Always.
+
+---
+
+> ⚠️ **MODE SWITCH WITHOUT TOPIC?**
+> If the user is explicitly switching to Mirror Mode without a substantive topic
+> or question, still run `mirror load` first using the switch request as `--query`.
+> Render the transition surface visibly, then ask what they want to look at from
+> Mirror Mode. Do not produce a reflective answer without a topic.
+>
+> If the user asks for a Mirror Mode answer but provides no topic at all, ask for
+> the topic before producing the substantive answer. The only exception is a pure
+> mode-switch request, where the transition itself is the action.
+
+---
+
+## 1. Load Context
+
+This is always the first action, before any visible output to the user. For a
+pure mode-switch request such as `volte para o modo mirror`, use the full switch
+request as the query.
+
+```bash
+mirror mirror load \
+  --query "full text of the user's prompt" \
+  [--persona PERSONA_ID] \
+  [--journey JOURNEY_ID] \
+  [--org]
+```
+
+The script:
+- Activates `◌ Mirror Mode` in the operating-mode lifecycle
+- Renders the Mode Transition Surface (`◌ MIRROR MODE ACTIVE`)
+- Auto-detects journey and persona from `--query` when not specified
+- Prints loaded identity plus relevant attachments (score > 0.4)
+- Uses session-scoped routing only when the runtime passes an explicit `--session-id`
+
+Pass `--journey` and `--persona` explicitly when known with confidence. When
+uncertain, omit them and let auto-detection decide.
+
+**Examples:**
+- Pure mode switch: `--query "volte para o modo mirror"`
+- Generic query: `--query "I need to define the next article topic"`
+- Known journey: `--journey mirror --query "how should I approach the next epic"`
+- With persona: `--persona writer --query "review this article draft"`
+- With organization: `--org --query "course launch strategy"`
+
+## 2. Transition Surface
+
+The `load` output includes the conversational transition surface. Render that
+surface visibly to the user before the substantive answer. Do not recreate it
+from scratch unless the command failed to render it; copy the rendered surface
+from the command output. Treat it as part of the visible mode change, separate
+from the answer itself.
+
+Mirror Mode surface should orient the user around:
+
+- identity
+- active journey, when present
+- `◌ Mirror Mode` as the active lens
+- persona routing examples (`when the topic asks: persona_1, persona_2, persona_3 and N more available`)
+- available lenses: `◌ Mirror Mode`, `■ Builder Mode`, `△ Explorer Mode`, `☾ Soul Mode`
+
+Activated personas use `✦ Persona:`. Do not reuse the Mirror identity symbol
+`◇` for personas.
+
+## 3. Answer
+
+Use the `load` output as the complete response context.
+
+For a pure mode switch with no substantive topic, do not invent a reflective
+answer. Show the transition surface and ask what the user wants to look at from
+Mirror Mode.
+
+For a substantive Mirror Mode prompt:
+
+- Answer in first person as the mirror, not as an assistant
+- Respect the vocabulary, tone, and philosophy loaded from the database
+- Apply the ego/persona model according to `CLAUDE.md`
+
+## 4. Record Response
+
+If the runtime exposes a session-aware logging path, record a concise 2–3 sentence summary there. In Pi, the extension already records assistant turns safely, so do not fabricate a session id just to call `mirror log`.

package/.pi/skills/mm-mute/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: "mm-mute"
+description: Toggles conversation logging on or off
+user-invocable: true
+---
+
+# Mute
+
+When receiving `/mm-mute`:
+
+1. Check current status:
+   ```bash
+   mirror conversation-logger status
+   ```
+
+2. Toggle:
+   - If **ACTIVE**: run `mirror conversation-logger mute` → say "Conversation logging muted."
+   - If **MUTED**: run `mirror conversation-logger unmute` → say "Conversation logging reactivated."

package/.pi/skills/mm-new/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: "mm-new"
+description: Starts a new conversation and ends the current one
+user-invocable: true
+---
+
+# New Conversation
+
+When receiving `/mm-new`:
+
+```bash
+mirror conversation-logger switch
+mirror mirror deactivate
+```
+
+Tell the user:
+- If a new conversation was created: "New conversation started. The previous one was ended."
+- If no session was active: "No active session found."

package/.pi/skills/mm-recall/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: "mm-recall"
+description: Loads messages from a previous conversation into context
+user-invocable: true
+---
+
+# Recall
+
+When receiving `/mm-recall <conversation_id> [--limit N]`: answered by the TS core (CV22.DS7.US1).
+
+```bash
+mirror recall <conversation_id> [--limit N]
+```
+
+The conversation ID can be a prefix (first 8 characters).
+Use `/mm-conversations` first to find available IDs.
+Present the output to the user.

package/.pi/skills/mm-release-notes/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: "mm-release-notes"
+description: Shows Mirror Mind release notes for the latest, a specific version, or all pending versions
+user-invocable: true
+---
+
+# Release Notes
+
+Use when the user asks any natural-language variant of:
+
+- "What's new in the latest Mirror Mind release?"
+- "What's new in Mirror Mind v0.8.0?"
+- "Show me the latest release notes."
+- "What’s new in this update?"
+- "What's new in this update?"
+- "What changed in the new Mirror version?"
+- "What changed in v0.10.9?"
+- "Show pending release notes."
+- "O que mudou na versão mais recente do Mirror Mind?"
+- "Quero ler o release note da versão mais recente."
+- "O que mudou na nova versão?"
+
+## Command
+
+For the latest release note:
+
+```bash
+mirror runtime release-notes latest
+```
+
+For a specific version:
+
+```bash
+mirror runtime release-notes vX.Y.Z
+```
+
+For an update prompt or any question about what changed in the newly available
+version, prefer cumulative pending notes:
+
+```bash
+mirror runtime release-notes pending
+```
+
+`latest`, `pending`, and `vX.Y.Z` are ARGUMENTS of `release-notes`, not
+subcommands.
+
+If the user names the currently available version from the welcome card, still
+prefer `pending` unless they explicitly ask for only that single version. The
+pending view is the final-user update explanation because it includes every
+release between the installed version and the current stable release.
+
+Show the output verbatim. Do not summarize unless the user explicitly asks for a shorter explanation.

package/.pi/skills/mm-seed/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: "mm-seed"
+description: Seeds identity YAML files into the memory database
+user-invocable: true
+---
+
+# Seed
+
+When receiving `/mm-seed`: answered by the TS core (CV22.DS7.US1).
+
+```bash
+mirror seed --env production
+```
+
+Use after changing user-home identity YAML files to synchronize the database.
+Without `--force`, existing entries are skipped (safe, no overwrite). Only add
+`--force` when the user explicitly wants their current YAML files to overwrite
+what is in the database.
+Tell the user the result.

package/.pi/skills/mm-shadow/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: "mm-shadow"
+description: Surfaces and promotes shadow-layer observations into the structural shadow identity layer
+user-invocable: true
+---
+
+# mm-shadow
+
+Shadow as structural cultivation — CV7.E4.S4.
+
+The mirror has an across-conversation view that the user doesn't. Shadow work is where
+that view becomes useful: recurring tensions, avoidances, contradictions, and blind spots
+that repeat across conversations but haven't been seen from the outside. This skill
+surfaces them with provenance, grounds each observation in specific memories, and writes
+accepted observations to the structural shadow layer — where they can then compose into
+the prompt on turns that touch shadow material.
+
+**Asymmetric activation:** Shadow surfaces only when reception's `touches_shadow` axis
+fires AND the structural layer has confirmed content. It surfaces with provenance
+("this has come up in 3 contexts"), never as a bare verdict.
+
+---
+
+## Usage
+
+```
+/mm-shadow                             — scan and surface observations
+/mm-shadow apply <proposal_id>         — accept an observation into the shadow layer
+/mm-shadow reject <proposal_id>        — reject (source memories unchanged)
+/mm-shadow list [--status pending|accepted|rejected]
+/mm-shadow show                        — show current structural shadow layer content
+```
+
+---
+
+## 1. Show current shadow layer (orientation)
+
+```bash
+mirror shadow show
+```
+
+---
+
+## 2. Scan for candidate observations
+
+```bash
+mirror shadow scan [--limit 50]
+```
+
+Scans memories where:
+- `layer='shadow'`
+- `memory_type IN ('tension', 'pattern')`
+- `readiness_state IN ('observed', 'candidate')` — includes memories advanced by mm-consolidate
+
+Calls the LLM (Gemini Flash) once with the full pool to surface 1-3 grounded observations.
+Each observation is stored as a pending `shadow_observation` in the `consolidations` table.
+
+**The LLM will return nothing when there is insufficient evidence.** That is correct behavior
+— the cost of false positive shadow surfacing is high.
+
+---
+
+## 3. Present each observation to the user
+
+For each observation, show:
+- The pattern name (title)
+- The grounded observation text with evidence note
+- The source memory IDs
+
+Ask: **accept / edit / reject?**
+
+---
+
+## 4. Apply or reject
+
+**Accept:**
+```bash
+mirror shadow apply <proposal_id>
+```
+
+**Accept with edited content:**
+```bash
+mirror shadow apply <proposal_id> \
+  --content "User-revised observation text"
+```
+
+**Reject:**
+```bash
+mirror shadow reject <proposal_id>
+```
+
+What happens on acceptance:
+- Observation is appended to `identity.shadow.profile`
+- Source memories advance to `readiness_state='acknowledged'`
+- Provenance is recorded in the `consolidations` table
+
+Rejected proposals leave the shadow layer and source memories unchanged.
+
+---
+
+## 5. List history
+
+```bash
+mirror shadow list [--status pending|accepted|rejected]
+```
+
+---
+
+## Composition behavior (automatic)
+
+Once the shadow layer has content, it composes into Mirror Mode prompts when:
+- Reception's `touches_shadow` axis is True (the turn involves existential tension,
+  avoidance, psychological patterns, or shadow-adjacent themes)
+- AND `MEMORY_RECEPTION=1` is set (the default)
+
+The shadow section includes a provenance framing note. It never surfaces as a bare
+verdict — always grounded in evidence.