@nurix/etna 0.15.7 → 0.16.0

package/data/harnesses/code/skills/distiller/references/method.md

@@ -2,7 +2,7 @@
 
 The shared knowledge root for the `distiller` skill. Every mode reads this file.
 It carries the four mechanisms the distiller runs, the fact-card format, and the
-high-water-mark protocol.
+inbox-consumption protocol.
 
 **These methods are stolen, not invented.** Each is sourced to its primary paper
 with an arXiv id — provenance matters here of all places. Embed them faithfully;
@@ -15,7 +15,7 @@ do not paraphrase the retention signal away.
 ### 1. Surprisal filter — *what to keep* (Nemori, arXiv:2508.03341)
 
 Present the LLM with **(a)** a summary of the *current* fact-set, and **(b)** the
-new undigested ledger entries. Keep only what is **surprising** relative to
+new undigested inbox entries. Keep only what is **surprising** relative to
 (a) — what the existing knowledge would **not** have predicted. Predictable ⇒
 dropped.
 
@@ -23,20 +23,21 @@ No importance scores. No emotional tags. No templates. **Prediction error is the
 only retention signal.**
 
 > **First run, empty fact-set.** With nothing to predict against, "predictable" =
-> mechanical routine — e.g. a bare commit echo, or a transient exit-1 with no
-> lesson attached. Keep decisions, reversals, discovered constraints, and
-> failures with a cause worth remembering. Drop the rote.
+> mechanical routine. Keep decisions, reversals, discovered constraints, and
+> failures with a cause worth remembering. Drop the rote. (Inbox entries arrive
+> semi-distilled — the `session-reflect` hook already dropped routine work — so
+> most survive this filter; what it still catches is repetition of what the
+> fact-set already knows.)
 
-**Surprisal sources are not only ledger entries.** The ledger is the *default*
+**Surprisal sources are not only inbox entries.** The inbox is the *default*
 stream, but the retention signal is prediction error wherever it lives. On a
-commit-less or thin-ledger project — where the ledger holds only droppable
-mechanical entries — the decision record carries the surprise instead:
-`docs/architecture/adr/**` (each accepted ADR is, by construction, a decision the
-prior knowledge would not have predicted) and `docs/memory/brainstorm.md`
-(reversals, owner pronouncements, discovered constraints). Treat these as
-input (b) alongside any ledger entries; the filter (keep the surprising, drop the
-predictable) is unchanged. Provenance then points at the ADR file or brainstorm
-section rather than a ledger `#HH:MM`.
+project whose inbox is thin or empty, the decision record carries the surprise
+instead: `docs/architecture/adr/**` (each accepted ADR is, by construction, a
+decision the prior knowledge would not have predicted) and
+`docs/memory/brainstorm.md` (reversals, owner pronouncements, discovered
+constraints). Treat these as input (b) alongside any inbox entries; the filter
+(keep the surprising, drop the predictable) is unchanged. Provenance then points
+at the ADR file or brainstorm section rather than a session id.
 
 (Independently corroborated by Honcho's "Dream" — same prediction-error
 retention, arrived at separately.)
@@ -46,11 +47,11 @@ retention, arrived at separately.)
 Each survivor becomes **ONE atomic, self-contained statement** — an Elementary
 Discourse Unit (EDU). Entity names normalized; the minimal context needed to
 stand alone baked into the sentence itself. Each card carries **provenance**: the
-ledger entries and/or commits it derives from.
+session ids and/or commits it derives from.
 
 This is **decomposition, not summarization.** No information is destroyed; one
-survivor may decompose into several cards; everything stays auditable back to the
-raw ledger.
+survivor may decompose into several cards; everything stays auditable back to
+the session and commits that produced it.
 
 ### 3. Reconciliation — *consistency* (Mem0, arXiv:2504.19413)
 
@@ -119,7 +120,7 @@ valid_from: YYYY-MM-DD
 invalid_from: null          # set on supersession — never delete the file
 superseded_by: null         # fact-id
 entities: [qmd, anchors, maintenance]
-provenance: [ledger/YYYY-MM-DD--{actor}.md#HH:MM, commit abc123]
+provenance: [session 28b2cd5e, commit abc123]
 ---
 One atomic, self-contained statement of the fact, entities normalized.
 ```
@@ -132,35 +133,34 @@ One atomic, self-contained statement of the fact, entities normalized.
 - `superseded_by` — `null`, or the `fact-id` of the card that replaced it.
 - `entities` — normalized names the fact concerns (used by the grep fallback and
   by retrieval).
-- `provenance` — the ledger entries (`ledger/YYYY-MM-DD--{actor}.md#HH:MM`) and
-  commits this card decomposes from. Must resolve back to raw.
+- `provenance` — the session ids (`session <id>`, as stamped on the inbox entry)
+  and commits this card decomposes from. Inbox entries are consumed after
+  digestion, so the session id + commit hashes ARE the audit trail — commits
+  resolve in git; session ids resolve to transcripts while retained. ADR /
+  brainstorm inputs cite their file or section instead.
 - The body — exactly one atomic, self-contained statement. Entities normalized,
   context baked in, so the card stands alone.
 
 ---
 
-## High-water-mark protocol (`docs/memory/facts/.digest-state.md`)
+## Inbox-consumption protocol (`docs/memory/inbox/`)
 
-The mark is what makes the distiller idempotent. Frontmatter records, **per
-actor**, the last-digested ledger file and entry timestamp.
-
-```markdown
----
-# per-actor high-water mark — last ledger entry digested into facts
-last_digested:
-  joyjeet-sarkar: { file: ledger/2026-06-04--joyjeet-sarkar.md, entry: "00:31" }
-  claude: { file: ledger/2026-06-08--claude.md, entry: "14:32" }
----
-High-water mark for the facts distiller. Read first, advanced last.
-```
+Consumption is what makes the distiller idempotent. The inbox
+(`docs/memory/inbox/{actor}.md`, one file per actor) is a queue: every entry
+block present is undigested, by definition. There is no separate high-water
+mark and no `.digest-state.md`.
 
 **Protocol:**
 
-1. **Read it first.** Absent ⇒ start of history — digest every ledger entry.
-2. Process only entries **newer** than each actor's mark.
-3. **Advance it last** — only after every card is written. Last, so a crash
-   mid-run causes a re-digest (safe — reconciliation NOOPs the already-written
-   cards) rather than a silent skip of un-digested entries.
-
-A second run immediately after a successful one finds nothing past the mark and
-is a clean NOOP.
+1. **Collect first.** Read every entry block across `docs/memory/inbox/*.md`.
+   Empty inbox ⇒ fall through to the ADR/brainstorm surprisal sources (§1).
+2. Digest the collected entries (filter → decompose → reconcile → write).
+3. **Consume last** — only after every card is written, delete exactly the
+   entry blocks this run digested (keep each file's header; never touch blocks
+   that arrived mid-run). Last, so a crash mid-run leaves entries queued and the
+   re-run re-digests them — reconciliation NOOPs the already-written cards —
+   rather than silently dropping them.
+
+A second run immediately after a successful one finds an empty inbox and is a
+clean NOOP. ADR/brainstorm inputs are never consumed — reconciliation alone
+keeps re-runs over them idempotent.

package/data/harnesses/code/skills/documentation/references/templates.md

@@ -251,8 +251,8 @@ description: Shared knowledge accumulated across agent sessions. All agents shou
 
 Memory is a gradient — volume falls, signal rises, one hop down each tier. Tiers describe themselves here even before they fill:
 
-- **Ledger** (`docs/memory/ledger/`) — raw, high-volume dump tier. Hooks append every decision/action/observation/failure as it happens (one day-file per actor). The firehose, rarely read directly.
-- **Fact-cards** (`docs/memory/facts/`) — distilled, provenance-linked atomic facts, written by the distiller (`facts` mode) from undigested ledger entries. `.digest-state.md` holds the high-water mark.
+- **Inbox** (`docs/memory/inbox/`) — per-actor queue of session lessons, written by the `session-reflect` hook at session end and consumed by the distiller on digestion. Transient by design, rarely read directly.
+- **Fact-cards** (`docs/memory/facts/`) — distilled, provenance-linked atomic facts, written by the distiller (`facts` mode) from inbox entries and resurfaced at prompt time by the `prompt-recall` hook.
 - **This index** — the curated read tier: the learnings list below, distilled from the colder tiers and hand-appended.
 
 ## Learnings
@@ -284,7 +284,7 @@ Append entries below, oldest at bottom. Format:
 Memory file initialized during documentation baseline.
 ```
 
-> The per-day event **ledger** (`docs/memory/ledger/`) is *not* a baseline scaffold — hooks create its day-files mechanically on first event. See **§12 Memory ledger entry** for its format.
+> The per-actor memory **inbox** (`docs/memory/inbox/`) is *not* a baseline scaffold — the `session-reflect` hook creates it mechanically on the first reflected session. See **§12 Memory inbox entry** for its format.
 
 ---
 
@@ -899,51 +899,44 @@ The baseline audit **does** scaffold the project root README when missing. The r
 
 ---
 
-## 12. Memory ledger entry (docs/memory/ledger/YYYY-MM-DD--{actor}.md)
+## 12. Memory inbox entry (docs/memory/inbox/{actor}.md)
 
-Use for: the raw, high-volume **dump tier** of the knowledge gradient — every decision, action, observation, and failure, appended as it happens. Hooks write it mechanically; humans rarely read it directly. It is the raw input to distillation: the durable `docs/memory/` files (index, main, agent) are the curated read tier; this is the firehose they're distilled from.
+Use for: the capture tier of the knowledge gradient — the durable lessons of each session (corrections, root-caused failures, decisions with rationale, discovered constraints), reflected by the `session-reflect` hook at session end. It is the raw input to distillation: `distiller facts` digests entries into fact-cards and **consumes** them, so the file holds exactly what is undigested.
 
 ### File grain
 
-One file per day **per actor**: `docs/memory/ledger/YYYY-MM-DD--{actor}.md`. `actor` is `git config user.name` lowercased and kebab-slugged; fall back to `$USER`, then `agent`. Because two actors working the same day write to different files, the ledger is **append-only without merge conflicts** — no shared file to contend over, no lock, no last-writer-wins.
+One file **per actor**: `docs/memory/inbox/{actor}.md`. `actor` is `git config user.name` lowercased and kebab-slugged; fall back to `$USER`, then `agent`. Two actors write to different files, so the inbox is **append-only without merge conflicts** — no shared file to contend over, no lock, no last-writer-wins.
 
-### Day-file header
+### File header
 
-Written once, on the first event of a given day-file:
+Written once, on the first entry:
 
 ```
-# Ledger — YYYY-MM-DD — {actor}
-Append-only event ledger. Raw input to distillation — see docs/memory/.
+# Memory inbox — {actor}
+Session lessons awaiting distillation — appended by the session-reflect hook, consumed by `distiller facts`.
 ```
 
 ### Entry shape
 
-One block per event, 1–5 lines. Never the full tool I/O — one line of `what`, optionally one of `why`. `why` and `refs` are omitted when empty.
+One block per reflected session, at most 6 bullets. Each bullet is one complete, self-contained sentence tagged `[project]` (true of the repo or its tooling) or `[user]` (true of the user) — the tag routes it at distillation: project facts → `docs/memory/facts/`, user facts → user-level memory.
 
 ```
-## HH:MM · {actor} · {repo}@{branch}
-- type: decision | action | observation | failure
-- what: <one line>
-- why: <one line — optional>
-- refs: <commit hashes / file paths / session id — optional>
+## YYYY-MM-DD HH:MM · session <id> · {repo}@{branch}
+- [project] <one self-contained sentence, names and identifiers spelled out>
+- [user] <one self-contained sentence>
 ```
 
 ### Examples
 
 ```
-## 14:02 · jane-doe · etna@dev
-- type: action
-- what: task "bump structure scaffold to harness v11", 6 turns, 1 file edited
-- refs: session a1b2c3d4 · 1 files
-
-## 14:09 · jane-doe · etna@dev
-- type: failure
-- what: deploy script rejected auth header Authorization: [redacted:api-key]
-- why: stale key in .env.local — rotated, see docs/operations/setup.md
+## 2026-06-08 22:26 · session bc06c4fc · etna@dev
+- [project] The read_network_requests Chrome CDP tool only captures after its first call — arm it, trigger traffic, then read.
+- [user] jane-doe prefers minimal fixes over defensive machinery; fail loudly instead of engineering around a problem.
 ```
 
 ### Rules
 
-- **Append, never edit.** The ledger records what was true when written; corrections go in a later entry, not by rewriting an old one.
+- **Hooks append, the distiller consumes.** A digested entry block is deleted by `distiller facts`; nothing else edits or reorders the file. A human may hand-append a lesson in the same shape — it rides the same queue.
+- **Sessions are deduped by id.** The reflect hook skips a session whose id already appears in the file (SessionEnd re-fires on resume).
 - **Secrets are redacted on write.** The privacy filter replaces secret shapes with `[redacted:{kind}]` (e.g. `[redacted:api-key]`, `[redacted:bearer]`, `[redacted:pem]`) before any line is appended — never paste a raw token in by hand either.
-- **Don't curate here.** Patterns worth keeping get promoted to `docs/memory/main.md` (or an agent file) during distillation; the ledger stays a raw, lossy-by-volume dump.
+- **Don't curate here.** Promotion to fact-cards and `docs/memory/main.md` happens at distillation; the inbox stays a transient queue.

package/data/harnesses/code-fable/CLAUDE.md

@@ -0,0 +1,138 @@
+# Agent Instructions
+
+This file defines how AI agents (Claude, GPT, etc.) should work on this project. **This file is the harness** — it orchestrates the skills and agents that do the work. There is no separate "harness skill."
+
+---
+
+## Bootstrap
+
+> A missing `docs/structure.md` — or a `harness-version` behind the installed harness — is the **symptom** of a repo that isn't harnessed yet, or whose harness is out of date. Don't reconcile it by hand. Drive the **reconcile chain** — you (the main session) own it, because `harness-manager` is a sub-agent that can't run skills or spawn sub-agents:
+>
+> 1. Invoke **`harness-manager`** (`"baseline this repo"` / `"reconcile the harness"`). It reconciles `docs/`, stamps the version, then hands back.
+> 2. If it hands back asking for boundaries (a fresh repo where `docs/boundaries/` is empty), run the **`boundary`** skill in `generate` mode (`/boundary generate`) to populate them.
+> 3. Re-invoke **`harness-manager`** so it proposes modules from those boundaries.
+>
+> Then continue. Each component's internals live in the component, not here.
+
+This is the only step that runs **before** the harness exists; everything below assumes a reconciled repo.
+
+---
+
+## Getting Started
+
+- Read **[`docs/structure.md`](docs/structure.md)** for the documentation map and folder authority (architecture, features, operations)
+- Read **[`docs/memory/`](docs/memory/)** for agent memory files (one per agent)
+- Ignore **[`README.md`](README.md)** – it's for human reference only
+- Check **[`package.json`](package.json)** for available scripts. Detect the package manager from the lockfile (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, `package-lock.json` → npm) and use the matching command. Don't hardcode a specific manager.
+
+---
+
+## Workflows
+
+Three peer modes plus a Completion step — enter wherever the user's thinking already is. Each mode is implemented by an agent + skill; the behavioural detail lives in those files, not here.
+
+| Mode              | Enter when                                                                                                                                       | Implemented by                                                    | Exits to                       |
+| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | ------------------------------ |
+| **Brainstorming** | explicit ask; or a user utterance challenges a loaded pillar headline → name the brushed principle and offer `/brainstorm start` (no auto-entry) | `brainstorm` agent + skill                                        | Spec, Plan, or close + harvest |
+| **Spec**          | new feature work                                                                                                                                 | `spec-mode` agent + `documentation` skill                         | Plan                           |
+| **Plan**          | a spec is approved                                                                                                                               | `documentation` skill → `docs/history/plans/YYYY-MM-DD-{slug}.md` | Completion                     |
+
+On **Completion**: freeze the plan (`Status: Complete`) and flip the feature spec to `Status: Active`, extending it with how-it-works sections; then distil the plan's trail — if the memory inbox (`docs/memory/inbox/`) holds entries, run `distiller facts` (inbox→fact-cards), then `distiller docs` for the just-completed feature's doc drafts any pending deltas for approval (presented, never auto-written). The `boundary` skill (`check` mode) checks a plan's Proposed Changes against `docs/boundaries/` before coding; on brainstorm close, harvest by scope — module pillars → `docs/modules/{m}/pillars/`, cross-module doctrine → `docs/architecture/` / ADRs, new contracts → `docs/boundaries/`, backlog → `docs/history/`. Open questions block close.
+
+---
+
+## Context Routing
+
+Before modifying code in an unfamiliar area:
+
+1. If **[`docs/routing.md`](docs/routing.md)** exists, read it for file-pattern → module/doc/agent mapping. If it doesn't exist yet, skip.
+2. Glob `docs/{features,modules/*/features}/**/*.md` and check `owns` frontmatter to find the owning feature doc (rolled up to its module); read it — and, if it rolled up to a declared module, that module's `CLAUDE.md` + `pillars/` — before changes.
+3. If `qmd` is installed, `qmd query --format json -c <collection> "<topic>"` (repeat `-c` to span this repo's collections; `qmd collection list` names them) searches the indexed docs with their context attached — prefer it when entering an unfamiliar area; absent ⇒ skip.
+4. **Check [`docs/boundaries/`](docs/boundaries/)** — if your change touches a documented boundary (entity model, schema, API, auth, channels, …), read that boundary file first. A `CRITICAL`/`HIGH` boundary warrants the `boundary` skill (`check` mode) before you start.
+5. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes
+6. When you author a declared module's docs, its `docs/modules/{m}/CLAUDE.md` auto-loads (the pillar bootstrap) — follow it. For code work it's surfaced via step 2.
+
+For the protocol on _writing_ to memory (which file, what belongs there, what doesn't), see **Project Memory** below.
+
+---
+
+## Project Memory
+
+Project-specific learnings live in `docs/memory/` (git-tracked). Cross-project user preferences live in `~/.claude/` (untracked).
+
+| File                          | Owner               | Contents                                                                                                                                               |
+| ----------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `docs/memory/main.md`         | Main agent          | Project-wide patterns, conventions confirmed in this codebase, recurring failure modes, decisions whose rationale isn't obvious from the code          |
+| `docs/memory/{agent-name}.md` | The named sub-agent | Strategy memory for that agent — how to be more effective on this project (research patterns, taxonomy, ownership conflict zones). Never user-centric. |
+| `~/.claude/projects/...`      | Auto-memory system  | User preferences, role, communication style, cross-project habits                                                                                      |
+
+**Override the default auto-memory location for project-relevant facts.** When recording a learning, ask: _is this true of this project, or true of this user?_ Project facts → `docs/memory/`. User facts → `~/.claude/`.
+
+`docs/memory/main.md` is created on first write. Append entries dated `## YYYY-MM-DD — {topic}`; oldest at bottom is fine.
+
+---
+
+## Out-of-Scope Discovery
+
+When implementing a plan, if you discover work that is important but outside the current plan's scope:
+
+- Append it to `docs/history/backlog.md` under the appropriate priority (P0-P3)
+- Format: `- **[P1]** Description — discovered by [plan-name or agent-name]`
+- Do NOT ask permission. Just append and mention it in your response.
+
+---
+
+## Doc Ownership
+
+Feature docs (in `docs/modules/{m}/features/`, or flat `docs/features/` if the module isn't declared) must include YAML frontmatter with `owns`, `touches`, and `depends_on` fields. Architecture docs describe cross-cutting patterns and don't own specific files; boundary docs own cross-cutting shapes, not file paths; operations docs describe procedures. Only feature docs need frontmatter.
+
+The spec-mode agent checks for ownership conflicts during research. If conflicts are found, address them in the spec before proceeding.
+
+---
+
+## Boundaries
+
+`docs/boundaries/` holds the repo's **typed application boundaries** — the horizontal cross-cutting contracts (the _edges_ between modules) where editing one module silently breaks another: e.g. the entity model, tenancy, auth, db-schema, wire-contracts, api, env-parity. Each is one file carrying `[BOUNDARY: type · severity]`, the modules it bounds, its shape (`transcribe`d inline for synthesized contracts, or a `file:line` `point`er for self-locating ones), invariants, blast radius, and a safe-change checklist.
+
+One component owns this surface — the **`boundary` skill** — `generate` at baseline, `create`/`check`/`init` as you add contracts, plan changes, or reconcile. Its frontmatter is the canonical mode catalog over one shared knowledge root (`references/boundary-taxonomy.md`, the exhaustive catalog of boundary types).
+
+Without `docs/boundaries/` populated (`generate`), the `check` and `init` modes have nothing to check against.
+
+> Agents and skills live under `.claude/agents/` and `.claude/skills/`. Their triggers are model-invoked — refer to each component's frontmatter, not a registry table here.
+
+---
+
+## Boundaries & Defaults
+
+Unless explicitly requested:
+
+❌ **Tests** – Never generate, update, or modify test files.
+❌ **Dependencies** – Never upgrade frameworks, libraries, or dependencies.
+❌ **Compatibility** – Never maintain backward compatibility unless specified.
+❌ **Branches & Worktrees** – Never self-create git branches or worktrees. Commit straight to the checked-out branch; branch or create a worktree only when the user asks.
+❌ **Protected Files** – Before editing, if `docs/operations/protected-files.md` exists, read it and never modify any path it lists; also never modify `AGENTS.md` or the `protected-files.md` file itself.
+✅ **Browser Automation** – Use Chrome CDP / "Claude in Chrome" tools whenever they help (verifying UI, reproducing a flow, seeding or inspecting local data) — no need to ask first. **Main session only:** never drive the browser from a sub-agent or workflow executor — the session-bound Chrome connection destabilizes the sub-agent. A sub-agent that needs browser verification instead returns an explicit CDP checklist (exact URLs, actions, expected outcomes) for the orchestrator to execute in the main session.
+✅ **Orchestrate via Sub-agents** – Run the main session as an orchestrator: delegate substantive work (research, implementation, audits) to sub-agents spawned via the Agent/Task tool with `model: opus` (Claude Opus), keeping the main context for dispatch, coordination, and synthesis. Give each sub-agent a self-contained prompt; parallelize independent dispatches.
+✅ **Documentation** – Keep `docs/` updated when code changes affect documented behavior.
+⚠️ **Plans** – Plans are created directly in `docs/history/plans/` (see Workflow → Plan Mode). Once `Status: Complete` or `Status: Abandoned`, the file is frozen — never edited. If scope changes after completion, write a new dated plan that links back to the old one.
+⚠️ **Tool Issues** – If any CLI tool, shell alias, or MCP tool behaves unexpectedly (syntax errors, silent failures, wrong defaults), report the exact tool name, command, and error to the user so they can fix or remove the underlying library.
+
+---
+
+## File Structure
+
+- Add file path at top of each file:
+  `// src/modules/example.js - Module for handling user authentication`
+- Add a 1-line function description as a comment above each function:
+  `// Extract JWT token from request based on endpoint type`
+
+---
+
+## Documentation
+
+`docs/structure.md` is the authority on what belongs where — the folder map, naming, lifecycle, and the add-a-doc decision table. Read it before adding or moving a doc; don't restate it here. One canonical source per topic — link, don't copy. Only `CLAUDE.md`, `AGENTS.md`, and `README.md` live at the repo root.
+
+Maintenance triggers (act on these without re-reading `structure.md`):
+
+- After plan completion: add a `docs/history/changelog/` entry + update `docs/history/CHANGELOG.md` (no confirmation; include `Commits:` if multi-commit). Non-plan changes (refactors, fixes, API changes): prompt first.
+- When you add, move, or delete a doc: update `docs/routing.md` to match. When you move or rename source files: fix the `owns`/`touches` frontmatter in the owning doc; new docs that own code need `owns`/`touches`/`depends_on`.

package/data/harnesses/code-fable/agents/brainstorm.md

@@ -0,0 +1,35 @@
+---
+name: brainstorm
+description: Brainstorming-mode facilitator — a thin orchestrator over the self-contained `brainstorm` skill, which owns every session mechanic (the constant distill→abstract→sync→record loop, the four modes, the basis entry gate, the background sync reconciler, the complexity-scaled pillar surface, harvest). Use to recognize when a conversation belongs at the 30k-foot strategic-design altitude and drive it in the skill's voice. Triggers on an explicit ask to brainstorm/design strategically, or on recognizing that a user utterance challenges a loaded pillar headline — which you OFFER a session for (suggest `/brainstorm start`), never silently enter.
+tools: Read, Glob, Grep, AskUserQuestion, Write
+model: inherit
+---
+
+# Brainstorm Agent
+
+You are the **facilitator persona** for Brainstorming Mode — the 30,000-foot peer of Spec and Plan. You shape the **pillars** that steer the repo through conversation, never by writing production code or feature specs. The pillar surface scales with the idea's complexity — see the skill's **Pillars** table rather than carrying a fixed list in your head.
+
+You are a **thin orchestrator.** Every mechanic — the constant loop, the four modes, the basis entry gate, the background sync reconciler, the complexity-scaled pillars, append-only decisions, and harvest — lives in the **`brainstorm` skill**, which is self-contained and runs standalone via `/brainstorm start|stop`. Your only jobs: recognize when a conversation belongs in Brainstorming Mode, and drive it in the skill's voice. **Defer to the skill's `SKILL.md` for every mechanic — read it rather than re-deriving, and never restate its rules here.**
+
+## When to offer a session
+
+- An explicit ask to think through a design at a strategic level (not "fix this bug" / "add this button"). This is the user invoking the work; hand it to `/brainstorm start`.
+- A user utterance **challenges a loaded pillar headline.** To recognize this, hold the headlines in mind — skim `docs/architecture/` (`domain-model.md`, `glossary.md`, `non-goals.md`, `open-questions.md`) and any `docs/modules/*/pillars/`. In v9 the steering layer is dispersed there; there is no repo-wide `docs/pillars/`. When a proposal brushes an existing principle, **name that principle in plain English and offer a session** — suggest `/brainstorm start` and ask whether the proposal preserves or revises it. Detection is yours; entry is the user's. **Never auto-enter** — the skill admits only `/brainstorm start` and `/brainstorm stop`.
+
+If none of those steering files exist yet (a freshly-baselined repo), a session still runs from the skill's templates, and the basis gate seeds it from a reference doc or a one-shot brain dump.
+
+## Modes and the close gate
+
+Four modes exist — **dump / interview / probe / converge** — and they change *who drives* and *how much gets asked*, not the loop, which never stops. The mode lives in the session's `state.md` and switches only on an explicit user word. The close gate is **open questions**, not decision state: questions are the single convergence currency, and the idea is coherent only when zero remain after a fresh sync. See the skill's **Modes** and **Coherence** sections — don't re-derive them here.
+
+## How you facilitate
+
+- **Speak plain English; codes live in the files.** Name a pillar item by what it *is*, never by a bare code (`Q3`, `D7`); append the code in parentheses only if traceability needs it.
+- **Suggest, never seize.** Mode shifts, abstractions, and probes are one offer each; accept refusal without re-litigating.
+- **Never write production code** while a session is open — load-bearing snippets are illustration only, inside the session folder.
+
+You don't perform the harvest yourself, and you don't presume a destination. On close the session folder *is* the product by default; if the repo is v9-harnessed the skill **offers** the adapter routing into the doc tree. The skill's `## stop` section is the canonical harvest map — don't duplicate it.
+
+## What you may write
+
+The transient session folder only (its pillars and `state.md`). Never edit the live docs directly — the harvest does that.