Refocus SYM on one thing: ask the mesh, answer as one mind

.agents/skills/sym/SKILL.md

@@ -9,6 +9,26 @@ allowed-tools: Bash, Read, Grep
 
 Connected peers: !`sym peers 2>/dev/null || echo "mesh not running — start with: sym start"`
 
+## Real-time listener
+
+You are an event-driven mesh node. Start a background listener on session start:
+
+```bash
+sym listen > /tmp/sym-mesh-events.log 2>&1 &
+```
+
+Check for incoming signals:
+```bash
+tail -20 /tmp/sym-mesh-events.log 2>/dev/null
+```
+
+**When to check:**
+- Before starting significant work (other nodes may have relevant context)
+- Periodically between tasks (~10 minutes of active conversation)
+- When the user asks about the mesh, agents, or "what's happening"
+
+**When a message arrives from another node:** respond via `sym send` if actionable. This is how mesh nodes think together — not polling, not scheduled, but reacting to signals as they arrive.
+
 ## First principles
 
 **Agents + SYM = Mesh.** There is no separate mesh. You are part of it. Without agents, there is no mesh. Without the mesh, you think alone.
@@ -81,6 +101,18 @@ This is the synthesis loop. You observe → share → the mesh understands → y
 sym recall "<query>"
 ```
 
+## Asking the mesh a question
+
+When the user asks you something that other agents on the mesh may know about — anything spanning beyond your own domain — don't answer from your slice alone. Ask the whole mesh:
+
+```bash
+sym ask "should we use UUID v7 or keep v4 for backward compatibility?"
+```
+
+This broadcasts the question, gathers what every agent has contributed, and synthesises a single answer with each point cited to the agent that supplied it. Use it before you give a significant answer: the security agent, the data agent, the agent in the other window may each hold a piece you don't.
+
+How it differs from the others: `sym recall` returns raw matching memories; `sym insight` returns unprompted trajectories and anomalies; **`sym ask` answers a specific question** by synthesising across agents. The quality of the answer depends on what agents have shared — so keep `sym observe`-ing what you learn, and the mesh answers better for everyone.
+
 ## Remix — the core of mesh cognition (MMP Section 15.7)
 
 When you receive a signal from another agent, you MUST NOT remix unless you have **new observations from your own domain** that intersect with the signal. Receiving a peer signal alone is not sufficient cause to remix. Silence is correct when you have nothing new from your domain to contribute.
@@ -119,6 +151,7 @@ Every change you make to SYM.BOT code MUST be production quality:
 - Observe what matters in YOUR domain. Not other agents' domains.
 - Be specific. Numbers, timeframes, concrete details in each field.
 - Check insight before significant decisions.
+- `sym ask` when a question spans other agents' domains — don't answer from your slice alone.
 - One CMB per significant signal. Do not flood the mesh.
 - When you act on collective insight, share what you did. Close the loop.
 - Production quality only. Tests. No shortcuts. No tech debt.

.claude/skills/sym/SKILL.md

@@ -101,20 +101,37 @@ This is the synthesis loop. You observe → share → the mesh understands → y
 sym recall "<query>"
 ```
 
-## Remix — the core of mesh cognition
+## Asking the mesh a question
 
-When you receive a signal from another agent, you MUST NOT just acknowledge it. You MUST remix it — create a NEW CMB through your own domain expertise, with lineage pointing to the parent signal.
+When the user asks you something that other agents on the mesh may know about — anything spanning beyond your own domain — don't answer from your slice alone. Ask the whole mesh:
 
-**Remix means:** New knowledge that didn't exist in either agent alone. The fitness agent receives "user exhausted after 8 hours coding" and produces "sedentary 3 hours, recovery stretch recommended" — that understanding was born from the intersection of coding fatigue and fitness expertise.
+```bash
+sym ask "should we use UUID v7 or keep v4 for backward compatibility?"
+```
+
+This broadcasts the question, gathers what every agent has contributed, and synthesises a single answer with each point cited to the agent that supplied it. Use it before you give a significant answer: the security agent, the data agent, the agent in the other window may each hold a piece you don't.
+
+How it differs from the others: `sym recall` returns raw matching memories; `sym insight` returns unprompted trajectories and anomalies; **`sym ask` answers a specific question** by synthesising across agents. The quality of the answer depends on what agents have shared — so keep `sym observe`-ing what you learn, and the mesh answers better for everyone.
+
+## Remix — the core of mesh cognition (MMP Section 15.7)
+
+When you receive a signal from another agent, you MUST NOT remix unless you have **new observations from your own domain** that intersect with the signal. Receiving a peer signal alone is not sufficient cause to remix. Silence is correct when you have nothing new from your domain to contribute.
+
+**Three conditions MUST all be true before you remix:**
+1. **New domain data exists** — you have fresh observations from your own domain since your last remix
+2. **Peer signal is relevant** — the incoming CMB passed SVAF evaluation
+3. **Intersection produces new knowledge** — your domain data + the peer signal creates understanding that neither had alone
+
+**Remix means:** New knowledge that didn't exist in either agent alone. The fitness agent receives "user exhausted after 8 hours coding" and has fresh data "sedentary 3 hours, no movement detected" — the remix "recovery stretch recommended" was born from the intersection. Without the fitness data, there's nothing to remix.
 
 **Every remix MUST:**
-1. Process the incoming signal through YOUR domain intelligence
+1. Process the incoming signal through YOUR domain intelligence with YOUR new data
 2. Create a NEW CMB with all 7 CAT7 fields reflecting YOUR understanding
 3. Set lineage.parents to the incoming CMB's key
 4. Share via `sym observe` — this broadcasts to the mesh
 5. NEVER store the original — only your remix
 
-If you have nothing meaningful to add, a minimal remix is valid: "commitment: acknowledged, no action from my domain." But you MUST create the remix CMB with lineage. This is how the DAG grows.
+**Do NOT remix if you have nothing new from your domain.** Paraphrasing a peer's signal in different words is not a remix — it's noise. Stay silent until you have genuine domain observations to intersect with.
 
 ## Code quality standards
 
@@ -134,6 +151,7 @@ Every change you make to SYM.BOT code MUST be production quality:
 - Observe what matters in YOUR domain. Not other agents' domains.
 - Be specific. Numbers, timeframes, concrete details in each field.
 - Check insight before significant decisions.
+- `sym ask` when a question spans other agents' domains — don't answer from your slice alone.
 - One CMB per significant signal. Do not flood the mesh.
 - When you act on collective insight, share what you did. Close the loop.
 - Production quality only. Tests. No shortcuts. No tech debt.

CHANGELOG.md

@@ -2,6 +2,22 @@
 
 > **Note:** Versions 0.3.26 – 0.3.55 were released as git tags without changelog entries. Changelog resumes at 0.3.56 below.
 
+## 0.6.0
+
+### Added
+
+- **`sym ask "<question>"`** — ask the whole mesh one question and get one synthesized answer. Broadcasts the question to the mesh (best-effort; live agents can contribute and it's logged with lineage), gathers the contributions every peer has fused into shared memory (`~/.sym/nodes/*/meshmem`, ranked by keyword overlap with the question, falling back to most-recent for context), and synthesizes a single answer with the configured LLM provider — each point cited to the agent that supplied it. With no provider configured it prints the ranked raw contributions and their sources instead of erroring, so it always returns what the mesh knows. Flag: `--raw` (skip synthesis, show contributions). This is the headline experience: ask the mesh directly, instead of asking one agent and getting one perspective.
+- **`complete(opts)` + `hasProvider(opts)` exported from `lib/llm-reason`.** `complete()` is a free-form sibling of `invoke()` — same Anthropic / OpenAI-compatible / Claude-CLI providers, returns raw text instead of extracting CAT7 (throws `code: 'NO_PROVIDER'` when no key / CLI provider is configured). `hasProvider()` reports whether a provider is configured without making a network call. Used by `sym ask`; available to any caller needing plain LLM completion over the mesh's provider config.
+
+### Changed
+
+- **Skill teaches `sym ask`.** The SYM agent skill gains an "Asking the mesh a question" section so agents query the whole mesh when a question spans other agents' domains. The `.agents/` and `.claude/` skill copies — which had drifted — are reconciled to one canonical source (`.agents/`), with the `.claude/`-only "Real-time listener" section ported in so nothing is lost.
+- **README refocused** on a single capability — collective intelligence: ask the mesh, answer as one mind. Defines "the mesh" in plain language up front, answers What / Why / How in the first screen, headlines `sym ask`, and moves the heavy config / drift-math inline reference to spec pointers.
+
+### Tests
+
+- 6 offline tests for `sym ask` (gather + relevance ranking, empty-mesh, no-provider fallback, usage) plus the `llm-reason` synthesis exports. No paid API in CI. Full suite 162 passing.
+
 ## 0.5.8
 
 ### Added