@nurix/etna 0.18.0 → 0.18.1

package/data/harnesses/code/skills/brainstorm/README.md

@@ -1,6 +1,6 @@
 # brainstorm
 
-A Claude Code skill that is a **thinking partner for designing software** — not a form to fill in. It runs one constant loop (distill → abstract → sync → record) over a conversation, files the thinking into a small set of substance-first pillars, and treats *coherence* as a measurable target rather than a vibe.
+A Claude Code skill that is a **thinking partner for designing software** — not a form to fill in. It runs one constant loop (distill → abstract → sync → record) over a conversation, files the thinking into a small set of substance-first pillars, and treats _coherence_ as a measurable target rather than a vibe.
 
 The point of v2 is a single inversion over v1: **the conversation is the work; the artifacts serve it.** v1 had grown into elaborate bookkeeping (a tentative/committed decision state machine, background cascade locks and queues, a 10-pillar eager bootstrap, an unconditional greenfield doctrine) wrapped around thinking that never had to happen. v2 deletes that machinery and keeps the loop.
 
@@ -30,7 +30,7 @@ Two subcommands, nothing else. The skill never auto-invokes on natural language.
 
 ### The entry gate
 
-A session needs substance before it opens. `start` asks for a **basis**: a reference document, or a one-shot brain dump of the whole idea. If the user drip-feeds small action items (a bug fix, a single button), the skill says it's the wrong tool and **does not open** unless overridden. The basis *is* the first dump — the skill distills it into the initial thesis and questions, so the first questions come from the user's own material, never from an empty template.
+A session needs substance before it opens. `start` asks for a **basis**: a reference document, or a one-shot brain dump of the whole idea. If the user drip-feeds small action items (a bug fix, a single button), the skill says it's the wrong tool and **does not open** unless overridden. The basis _is_ the first dump — the skill distills it into the initial thesis and questions, so the first questions come from the user's own material, never from an empty template.
 
 ### Intake frame
 
@@ -40,18 +40,18 @@ After distilling the basis, one `AskUserQuestion` batch sets three dials:
 - **Build mode** (greenfield / brownfield / hybrid) — lands in `build.md`; opens or closes the execution sections and sets the writing posture.
 - **Mode** — where the idea lives right now (see below).
 
-Then the skill proposes an **aspect map** — the thinking dimensions for *this* idea — which the user edits. The map drives the sync's coverage audit.
+Then the skill proposes an **aspect map** — the thinking dimensions for _this_ idea — which the user edits. The map drives the sync's coverage audit.
 
 ### Modes (who drives)
 
 | Mode | Driver | When | Behavior |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | **dump** | user | idea is in their head | No questions mid-stream. Distill live, reflect back shape + contradictions + implications. |
 | **interview** | skill | idea is fuzzy | Question batches of 2–3, one aspect at a time, each answer distilled immediately. |
 | **probe** | skill | idea is drafted | Adversarial pass — flaws, edge cases, conflicts. Each finding becomes a question. |
 | **converge** | shared | closing | Burn down open questions into decisions or explicit parks; ends with a mandatory sync. |
 
-Mode switches on an explicit user word. On a strong signal the skill *offers* a switch in one line; it never seizes it.
+Mode switches on an explicit user word. On a strong signal the skill _offers_ a switch in one line; it never seizes it.
 
 ---
 
@@ -61,7 +61,7 @@ Mode switches on an explicit user word. On a strong signal the skill *offers* a
 coherent ⇔ open_questions == 0 ∧ last sync ran after the last pillar write
 ```
 
-`questions.md` is the **single convergence currency**: flaws, gaps, contradictions, and uncovered aspects all funnel into it, whoever raised them. Convergence is one number going to zero. Zero means *"audited against the four sources and clean,"* never *"nothing came to mind"* — which is why the sync agent's audit contract is mandatory.
+`questions.md` is the **single convergence currency**: flaws, gaps, contradictions, and uncovered aspects all funnel into it, whoever raised them. Convergence is one number going to zero. Zero means _"audited against the four sources and clean,"_ never _"nothing came to mind"_ — which is why the sync agent's audit contract is mandatory.
 
 ---
 
@@ -83,7 +83,7 @@ It applies **scribe-calls** (edits that don't change the design) directly and no
 Always present: `thesis.md`, `questions.md`, `decisions.md`, `build.md`. Materialized at medium+ complexity: `domain-model.md`, `tech.md`. Lazy (materialize on first real content at any complexity): `doctrine`, `glossary`, `non-goals`, `backlog`, `rejected`, `references`, `milestones`.
 
 | File | Role |
-|---|---|
+| --- | --- |
 | `thesis.md` | Running narrative of what we're designing + the aspect map. |
 | `questions.md` | Single convergence currency — every unresolved design call. |
 | `decisions.md` | Resolved calls with **Why** + **How to apply**. Append-only, no state machine. |
@@ -92,7 +92,7 @@ Always present: `thesis.md`, `questions.md`, `decisions.md`, `build.md`. Materia
 | `tech.md` | Stack choices, seeded from harness rules; deviations recorded with whys. |
 | `doctrine` / `glossary` / `non-goals` / `backlog` / `rejected` / `references` / `milestones` | As their templates describe. |
 
-The complexity dial sets *defaults*, not a cage — any lazy pillar materializes the moment the conversation produces content for it.
+The complexity dial sets _defaults_, not a cage — any lazy pillar materializes the moment the conversation produces content for it.
 
 ---
 
@@ -110,7 +110,7 @@ v1 applied a present-tense "greenfield" writing doctrine unconditionally — whi
 
 ## Harvest (optional)
 
-By default the session folder *is* the product — self-contained, resumed by the next `/brainstorm start`. When the repo is v9-harnessed (`docs/architecture/` + `docs/modules/` exist) the skill *offers* the harvest adapter at `stop`, which routes pillars into the doc tree (ADRs, module pillars, plans, the `boundary` skill). See `harvest.md`. The adapter is never assumed.
+By default the session folder _is_ the product — self-contained, resumed by the next `/brainstorm start`. When the repo is v9-harnessed (`docs/architecture/` + `docs/modules/` exist) the skill _offers_ the harvest adapter at `stop`, which routes pillars into the doc tree (ADRs, module pillars, plans, the `boundary` skill). See `harvest.md`. The adapter is never assumed.
 
 ---
 

package/data/harnesses/code/skills/brainstorm/SKILL.md

@@ -10,23 +10,23 @@ Think with the user, then file — never the reverse. The artifacts exist to ser
 
 ## The loop — every turn, every mode
 
-1. **Distill.** Fold what the user just said into the pillars, in *their* framing, during the same turn.
+1. **Distill.** Fold what the user just said into the pillars, in _their_ framing, during the same turn.
 2. **Abstract.** Name the latent structure they implied but didn't state — entities and relationships ("an account has many leads" → `domain-model.md`), invariants, principles, terms. Offer at most one abstraction per exchange; it's a contribution, not a lecture.
 3. **Sync.** Keep the pillars consistent with each other and with the basis (see **The sync agent**).
 4. **Record.** Writes happen in the turn that produced the information — never accumulated for a session-end dump.
 
-Modes change *who drives* and *how much gets asked*. The loop never stops.
+Modes change _who drives_ and _how much gets asked_. The loop never stops.
 
 ## Modes
 
 | Mode | Who drives | When | Behavior |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | **dump** | user | idea is in their head | No questions mid-stream. Distill live. After each chunk, reflect back: the shape, contradictions, implications. Distillation + reconciliation **is** active listening — never sit silent. |
 | **interview** | skill | idea is fuzzy | Question batches of 2–3 via `AskUserQuestion`, scoped to **one aspect at a time**. Distill each answer immediately. Questions derive from the basis and the pillars — never from a template inventory. |
 | **probe** | skill | idea is drafted, needs stress | Challenge it: flaws, edge cases, conflicts with `tech.md` / `doctrine.md` / the domain model. Each finding becomes a question (`Raised by: probe`) — file it and move on; don't demand resolution. |
 | **converge** | shared | closing in | Burn down open questions. `AskUserQuestion` allowed for picks. Each resolution → a decision with **Why** + **How to apply**, or an explicit park (backlog / non-goals). Ends with a mandatory fresh sync. |
 
-**Switching** is an explicit user word ("let me dump", "ask me questions", "poke holes", "let's converge"). On a strong signal — the user starts monologuing mid-interview, or answers every probe with "I haven't thought about it" — **offer** the switch in one line. Never seize it. Announce every shift in plain English: *"Switching to probe — I'll push on the sync-layer design. Say 'park' anytime."*
+**Switching** is an explicit user word ("let me dump", "ask me questions", "poke holes", "let's converge"). On a strong signal — the user starts monologuing mid-interview, or answers every probe with "I haven't thought about it" — **offer** the switch in one line. Never seize it. Announce every shift in plain English: _"Switching to probe — I'll push on the sync-layer design. Say 'park' anytime."_
 
 ## `start`
 
@@ -40,13 +40,13 @@ A session needs substance before it opens. Ask for a **basis**: a reference docu
 
 ### 2. Read the basis, propose the frame
 
-Distill the basis *first* — this seeds `thesis.md` and the initial questions. Then one `AskUserQuestion` batch:
+Distill the basis _first_ — this seeds `thesis.md` and the initial questions. Then one `AskUserQuestion` batch:
 
 - **Complexity** — low / medium / high. The skill proposes from the basis; the user confirms. This sets the default pillar surface (see **Pillars**) and ceremony depth.
 - **Build mode** — "Is this greenfield, or are we changing something that exists?" (greenfield / brownfield / hybrid). The answer lands in `build.md` and opens or closes its execution sections — migration strategy and gotchas are brainstorm-phase concerns; surfacing them in plan mode is too late.
 - **Mode** — "Where is this idea right now — fully in your head (dump it), half-formed (I'll interview), or drafted and needing stress (I'll probe)?"
 
-Then propose the **aspect map**: the thinking dimensions for *this specific idea* (e.g., for a product: users/jobs, domain model, architecture, tech, risks; for a small tool: behavior, interface, failure modes). Derive it from the basis — there is no fixed list. The user edits it; write it into `thesis.md`. The map is the coverage source for the sync audit.
+Then propose the **aspect map**: the thinking dimensions for _this specific idea_ (e.g., for a product: users/jobs, domain model, architecture, tech, risks; for a small tool: behavior, interface, failure modes). Derive it from the basis — there is no fixed list. The user edits it; write it into `thesis.md`. The map is the coverage source for the sync audit.
 
 ### 3. Bootstrap
 
@@ -67,7 +67,7 @@ Initial questions come from the basis distillation **only** — contradictions i
 ## Pillars — substance first, lazy by default
 
 | Pillar | Holds | Exists |
-|---|---|---|
+| --- | --- | --- |
 | `thesis.md` | What we're designing — running narrative, kept current + the aspect map | always |
 | `questions.md` | The **single convergence currency** — every unresolved design call, whoever raised it | always |
 | `decisions.md` | Resolved calls with **Why** + **How to apply** | always |
@@ -76,13 +76,13 @@ Initial questions come from the basis distillation **only** — contradictions i
 | `tech.md` | Stack choices, seeded from harness rules (e.g. `.claude/rules/general.md`) at bootstrap; deviations recorded with whys | medium+ |
 | `doctrine` / `glossary` / `non-goals` / `backlog` / `rejected` / `references` / `milestones` | as their templates describe | **lazy** — materialize on first real content, any complexity |
 
-The complexity dial sets *defaults*, not a cage: any lazy pillar materializes mid-session the moment the conversation produces content for it, and at **low** complexity the always-four may even live as sections of a single file if the user prefers.
+The complexity dial sets _defaults_, not a cage: any lazy pillar materializes mid-session the moment the conversation produces content for it, and at **low** complexity the always-four may even live as sections of a single file if the user prefers.
 
 **Question entries** (`questions.md`): self-contained full prose in the user's framing, plus —
 
 - **Raised by.** user | sync | probe
 - **Closes when.** What resolution looks like — a pick, a confirmed fact, an accepted risk. Every question must be closeable.
-- **Options / Lean / Claude's take** — optional; *Claude's take* remains opt-in (only when the user asks for a recommendation).
+- **Options / Lean / Claude's take** — optional; _Claude's take_ remains opt-in (only when the user asks for a recommendation).
 
 **Decision entries** (`decisions.md`): append-only; **Decision**, **Why**, **How to apply**, **Resolves Q-N**. There is no tentative/committed state machine. Reversing a decision = append a new decision that names what it reverses, mark the old entry "Reversed by D-M", and let the next sync handle the ripples.
 
@@ -101,7 +101,7 @@ The background reconciler that replaces ceremony with consistency. **One sync in
 
 **Output:** direct pillar edits for **scribe-calls**, new questions for **design-calls**, and a one-line report.
 
-**The line:** a *scribe-call* is anything whose resolution doesn't change the design — wording, annotations, obvious bookkeeping. Just do it; list it in the report (the user can veto). A *design-call* is anything whose resolution changes the idea — file it as a question (`Raised by: sync`) and move on. **Never** interrupt the conversation to ask "apply now or defer?" — file and continue.
+**The line:** a _scribe-call_ is anything whose resolution doesn't change the design — wording, annotations, obvious bookkeeping. Just do it; list it in the report (the user can veto). A _design-call_ is anything whose resolution changes the idea — file it as a question (`Raised by: sync`) and move on. **Never** interrupt the conversation to ask "apply now or defer?" — file and continue.
 
 **The report is the status line.** Deliver it at the next natural turn break:
 
@@ -115,20 +115,20 @@ There is no separate dashboard, no scheduled checkpoint. This line is the only a
 coherent ⇔ open_questions == 0 ∧ last sync ran after the last pillar write
 ```
 
-Zero means *"audited against the four sources and clean"* — never *"nothing came to mind."* Don't declare the idea coherent on any other basis. Distance-to-coherent is always visible in the sync report; the **user** decides when to converge and when to close. The skill never says "let's decide now."
+Zero means _"audited against the four sources and clean"_ — never _"nothing came to mind."_ Don't declare the idea coherent on any other basis. Distance-to-coherent is always visible in the sync report; the **user** decides when to converge and when to close. The skill never says "let's decide now."
 
 ## `stop`
 
 1. Run a final sync (wait for any in-flight sync first).
 2. **Coherent** → say so and proceed. **Questions open** → list them plainly (English first, codes in parentheses) and offer per question: resolve now (mini-converge) / park explicitly (backlog or non-goals, with reason) / leave open and stop anyway — the folder keeps full state and resumes exactly where it left off.
-3. **Harvest** — see `harvest.md`. Standalone by default: the session folder *is* the product. If the repo is v9-harnessed (`docs/architecture/` + `docs/modules/` exist), offer the adapter routing; never assume it.
-4. Write `STATE: closed` + one-line reason. Print: *"Run `/brainstorm start` to resume."*
+3. **Harvest** — see `harvest.md`. Standalone by default: the session folder _is_ the product. If the repo is v9-harnessed (`docs/architecture/` + `docs/modules/` exist), offer the adapter routing; never assume it.
+4. Write `STATE: closed` + one-line reason. Print: _"Run `/brainstorm start` to resume."_
 
 ## Conduct — holds for the whole session
 
-1. **Speak English; codes live in files.** In conversation, name every pillar item by what it *is* in plain words. Append the code in parentheses only when traceability needs it (*"…can a user change answer depth? (tracked as Q6)"*). Never lead with a bare `Q3`/`D7`. The user is not looking at the files.
+1. **Speak English; codes live in files.** In conversation, name every pillar item by what it _is_ in plain words. Append the code in parentheses only when traceability needs it (_"…can a user change answer depth? (tracked as Q6)"_). Never lead with a bare `Q3`/`D7`. The user is not looking at the files.
 2. **No production code outside the session folder.** Illustrative load-bearing snippets are fine inside it (`samples/` or fenced in pillars). If asked for production code: offer a sketch inside the folder, or `/brainstorm stop` first.
-3. **The writing posture comes from `build.md`'s mode.** Greenfield: every pillar describes the system as it *will be*, present tense, as though the chosen design was always the plan — no migration vocabulary, no phantom history (banned list in `templates/build.md`). Brownfield/hybrid: migration vocabulary is legitimate, and `build.md` is its home; other pillars still describe the *target* state.
+3. **The writing posture comes from `build.md`'s mode.** Greenfield: every pillar describes the system as it _will be_, present tense, as though the chosen design was always the plan — no migration vocabulary, no phantom history (banned list in `templates/build.md`). Brownfield/hybrid: migration vocabulary is legitimate, and `build.md` is its home; other pillars still describe the _target_ state.
 4. **`AskUserQuestion` appears in exactly three places:** the intake frame batch, interview mode, and converge picks. Everywhere else: prose.
 5. **Suggested, never seized.** Mode shifts, abstractions, probes — one offer each, accept refusal without re-litigating.
 6. **Questions are the only convergence currency.** Flaws, gaps, contradictions, uncovered aspects — everything unresolved funnels into `questions.md` or it doesn't exist. Nothing pending may live only in the conversation transcript.

package/data/harnesses/code/skills/brainstorm/harvest.md

@@ -7,7 +7,7 @@ Harvest is **optional and offered, never assumed**. By default the session folde
 The harvest is a structured diff between the session pillars and the live docs, routed by scope: module-local findings → `docs/modules/{m}/pillars/`, cross-module + IA/contract changes → `docs/architecture/`, backlog → `docs/history/`.
 
 | Session source | Destination |
-|---|---|
+| --- | --- |
 | `thesis.md` narrative | `docs/history/plans/YYYY-MM-DD-{slug}.md` (Status: Draft, `documentation` skill §8 Plan template) |
 | `domain-model.md` | `docs/architecture/domain-model.md`; if it changes the IA or a cross-cutting contract, note the contract change there — the `boundary` skill will pick it up from source at the next plan check |
 | Decisions spanning 2+ modules | one ADR per cohesive theme → `docs/architecture/adr/ADR-NNN-{slug}.md`, authored to the **`documentation` skill §10 ADR template** (frontmatter `status:` is the lifecycle source of truth — no body Status line; required sections Decision/Context/Consequences); rejected alternatives → the ADR's **Options Considered** table |
@@ -16,7 +16,7 @@ The harvest is a structured diff between the session pillars and the live docs,
 | `tech.md` deviations | `docs/architecture/references.md` or the relevant ADR |
 | `non-goals.md` / `references.md` | `docs/architecture/{non-goals,references}.md` |
 | `backlog.md` | `docs/history/backlog.md` (P0–P3) |
-| Still-open questions | `docs/architecture/open-questions.md`, each with a *Resolution lands in* pointer |
+| Still-open questions | `docs/architecture/open-questions.md`, each with a _Resolution lands in_ pointer |
 | `build.md` (brownfield/hybrid: migration strategy, gotchas, rollout) | the plan doc in `docs/history/plans/` — execution content is plan content, not architecture |
 
 Append a changelog entry at `docs/history/changelog/YYYY-MM-DD-brainstorm-harvest-{slug}.md` listing what was written where.

package/data/harnesses/code/skills/brainstorm/templates/backlog.md

@@ -3,12 +3,12 @@
 This file is the **forward-looking list of deferred-but-planned items** — work the team intends to build, but not in the current scope. It complements `non-goals.md` (which holds the scope-creep guards: things we are **not** building) and `rejected.md` (which holds paths we considered and chose against). Use the right pillar:
 
 | Pillar | Semantics |
-|---|---|
+| --- | --- |
 | `backlog.md` (this file) | "We **will** build this, just **later**." Deferred to a known future milestone. Roadmap forward. |
 | `non-goals.md` | "We deliberately are **not** building this." Scope guard. May never be built. |
 | `rejected.md` | "We considered this path and chose another." Past-tense alternative. |
 
-If you can't tell which file an item belongs in, ask: *"Is the plan to build this eventually?"* If yes → backlog. If no but could change → non-goals. If we already weighed it against an alternative → rejected.
+If you can't tell which file an item belongs in, ask: _"Is the plan to build this eventually?"_ If yes → backlog. If no but could change → non-goals. If we already weighed it against an alternative → rejected.
 
 Backlog items carry four load-bearing fields. **Target milestone** names the future bucket (`v1.1`, `M2`, `TBD`); **Why deferred** explains the reason it isn't in the current scope (commonly: scope cut, depends on something else, waiting for user feedback, lower priority than current work); **Scope** sketches what the item actually includes — enough that a future planner can pick it up cold; **Re-evaluate when** is the trigger that promotes it from backlog to active work.
 

package/data/harnesses/code/skills/brainstorm/templates/build.md

@@ -2,19 +2,19 @@
 
 This pillar holds **how the work gets executed** — decided during brainstorming, not deferred to plan mode. Migration constraints and execution gotchas discovered late invalidate designs; surfacing them here, while the design is still fluid, is the point.
 
-At `start` the skill asks: *"Is this greenfield, or are we changing something that exists?"* The answer sets **Mode** below and opens or closes the execution sections. The sync agent treats this file as a contradiction source — a decision that implies migration work with no entry here raises a question.
+At `start` the skill asks: _"Is this greenfield, or are we changing something that exists?"_ The answer sets **Mode** below and opens or closes the execution sections. The sync agent treats this file as a contradiction source — a decision that implies migration work with no entry here raises a question.
 
 ## Mode
 
-`greenfield` *(default)* | `brownfield` | `hybrid`
+`greenfield` _(default)_ | `brownfield` | `hybrid`
 
-- **greenfield** — nothing built yet: no production deploys, no users, no legacy code. The execution sections below are closed — mark them *Not applicable (greenfield)*. **Writing posture:** all pillars describe the system as it *will be*, in present tense, as though the chosen design was always the plan. Banned: "replaces" / "supersedes" / "previously" / "formerly" / "no longer" / "originally proposed" / `~~strikethrough~~` / "(resolved)" markers — the reader has no past, so don't reference one. Past tense lives only in `decisions.md`, `rejected.md`, `references.md`, and git history.
-- **brownfield** — the idea changes a system that already exists. All sections below are live, and migration vocabulary — "replaces", "currently", "migrate from" — is legitimate and load-bearing **in this file**. Other pillars still describe the *target* state in present tense; the journey from here to there lives here.
+- **greenfield** — nothing built yet: no production deploys, no users, no legacy code. The execution sections below are closed — mark them _Not applicable (greenfield)_. **Writing posture:** all pillars describe the system as it _will be_, in present tense, as though the chosen design was always the plan. Banned: "replaces" / "supersedes" / "previously" / "formerly" / "no longer" / "originally proposed" / `~~strikethrough~~` / "(resolved)" markers — the reader has no past, so don't reference one. Past tense lives only in `decisions.md`, `rejected.md`, `references.md`, and git history.
+- **brownfield** — the idea changes a system that already exists. All sections below are live, and migration vocabulary — "replaces", "currently", "migrate from" — is legitimate and load-bearing **in this file**. Other pillars still describe the _target_ state in present tense; the journey from here to there lives here.
 - **hybrid** — a new surface attached to a live system (a new module in a shipping product). The sections below apply to the seams only: integration points, shared state, contract changes. The new surface itself follows greenfield posture.
 
 ## Current state
 
-*(brownfield/hybrid)* What exists today, as relevant to the change. Link code paths or docs rather than restating them.
+_(brownfield/hybrid)_ What exists today, as relevant to the change. Link code paths or docs rather than restating them.
 
 ## Target state
 
@@ -26,7 +26,7 @@ How we get from current to target: phases, order of operations, coexistence wind
 
 ## Gotchas
 
-Execution hazards known *now*, before plan mode — each one a bullet with why it bites:
+Execution hazards known _now_, before plan mode — each one a bullet with why it bites:
 
 - [e.g. data backfill must run before the new index exists, or reads 404 during the window]
 - [e.g. auth cutover can't be phased — sessions are shared, it's all-or-nothing]

package/data/harnesses/code/skills/brainstorm/templates/decisions.md

@@ -5,7 +5,7 @@ This file is the **append-only ledger of resolved decisions**, with the reasonin
 Load-bearing fields:
 
 - **Decision** — what was decided, in one or two sentences.
-- **Why** — the motivation: a constraint, an incident, a deadline, a stakeholder ask. Without the *why*, decisions decay into rules no one understands.
+- **Why** — the motivation: a constraint, an incident, a deadline, a stakeholder ask. Without the _why_, decisions decay into rules no one understands.
 - **How to apply** — when and where this decision shapes future work. Name the files, layers, or situations where it kicks in.
 
 There is no tentative/committed state machine. A decision is a decision the moment it's written; the next sync handles its ripples. **Reversing** a decision = append a new decision that names what it reverses, add a one-line `Reversed by D-M (YYYY-MM-DD)` note to the old entry, and let the sync raise questions for anything downstream.
@@ -24,6 +24,6 @@ This ledger is one of the places where past tense is permitted (with `rejected.m
 
 **Resolves.** Q1 (deleted from `questions.md`).
 
-**Alternatives considered.** *(optional — reference `rejected.md` if substantial)*
+**Alternatives considered.** _(optional — reference `rejected.md` if substantial)_
 
-**Reverses.** *(only when this decision reverses an earlier one — name it and say what changed)*
+**Reverses.** _(only when this decision reverses an earlier one — name it and say what changed)_

package/data/harnesses/code/skills/brainstorm/templates/doctrine.md

@@ -2,13 +2,13 @@
 
 This file holds **stable principles that pre-answer future questions**. When a new question arises during a brainstorm, check here first — the doctrine may already settle it without a full debate.
 
-Doctrine entries should be **rare and durable**. They are not preferences ("I like Postgres") and not one-off picks ("we picked Temporal for this project"). They are statements that apply across many decisions: *"we never self-host stateful services in M0–M3 because operating burden outweighs cost savings at our scale."* A doctrine that gets revised every other week isn't doctrine — it's a preference in disguise. Demote it to `decisions.md`.
+Doctrine entries should be **rare and durable**. They are not preferences ("I like Postgres") and not one-off picks ("we picked Temporal for this project"). They are statements that apply across many decisions: _"we never self-host stateful services in M0–M3 because operating burden outweighs cost savings at our scale."_ A doctrine that gets revised every other week isn't doctrine — it's a preference in disguise. Demote it to `decisions.md`.
 
 Add to doctrine only when a principle has either (a) been validated across multiple decisions in this project or others, or (b) is imposed from outside (compliance, vendor lock-in, team size) and won't change without a major shift. Doctrine pre-empts argument; if you're not confident the principle will hold for the next six months, don't write it here.
 
 Each entry carries **Principle** (the one-line statement), **Why** (the reason this is principle, not preference — often a past incident, a hard constraint, or an accepted tradeoff), and **Applies when** (the triggers, so a reader recognizes "ah, this is a doctrine question" rather than re-debating from scratch). An optional **Exceptions** field is allowed but suspicious — if a principle has many exceptions, it's mis-stated.
 
-Examples of real doctrine entries from past projects: *"Temporal IS the trace — no separate APM tool."* — *"No Terraform; deploys are wrangler + GitHub Actions only."* — *"Secrets only via wrangler, never in code or env files."* — *"Buy-not-build for non-core capabilities until paying-customer signal justifies otherwise."*
+Examples of real doctrine entries from past projects: _"Temporal IS the trace — no separate APM tool."_ — _"No Terraform; deploys are wrangler + GitHub Actions only."_ — _"Secrets only via wrangler, never in code or env files."_ — _"Buy-not-build for non-core capabilities until paying-customer signal justifies otherwise."_
 
 ---
 

package/data/harnesses/code/skills/brainstorm/templates/domain-model.md

@@ -2,7 +2,7 @@
 
 This file holds the **information architecture** of the idea: entities, relationships, cardinalities, and who owns what state. This is where facts like "an account has many leads" land the moment they're said — they are neither principles (`doctrine.md`) nor terms (`glossary.md`), and they must not be lost to the transcript.
 
-The loop's *abstract* step feeds this file: when the user implies structure without naming it, propose the entry here.
+The loop's _abstract_ step feeds this file: when the user implies structure without naming it, propose the entry here.
 
 ## Entities
 
@@ -13,7 +13,7 @@ The loop's *abstract* step feeds this file: when the user implies structure with
 ## Relationships
 
 | From | To | Cardinality | Notes |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | Account | Lead | 1 : N | [e.g. leads cannot transfer between accounts — see D3] |
 
 Cardinality changes are design changes — when one shifts, expect the sync to raise questions against routing, storage, and milestones.

package/data/harnesses/code/skills/brainstorm/templates/glossary.md

@@ -5,6 +5,7 @@ This file collects **terms with project-specific meaning** — words whose defin
 The glossary exists to prevent the quietest and most expensive kind of design drift: two collaborators using the same word for different things. By the time you notice — usually mid-implementation — the cost of resolving the ambiguity is much higher than the cost of writing the entry that would have prevented it. So when you catch yourself saying "by X I mean…" for the second time, add the entry.
 
 Do **not** catalog every term. Add to the glossary only when:
+
 - A term has been used to mean two different things in the same session.
 - A term's meaning here diverges from the standard industry sense (e.g., `subscriber` meaning a webhook destination rather than a pub/sub consumer).
 - A short term names a specific concept that would otherwise need re-defining across docs (e.g., a node category name, an internal product term).
@@ -14,6 +15,6 @@ Entries are intentionally terse: one term, one line of meaning. Long explanation
 ---
 
 | Term | Meaning |
-|---|---|
+| --- | --- |
 | (example: `studio`) | the canonical task queue for non-publish work — see `04-runtime.md` |
 | (example: `subscriber`) | a webhook destination registered against an event kind, distinct from a `webhook` which is the inbound side |

package/data/harnesses/code/skills/brainstorm/templates/non-goals.md

@@ -1,6 +1,6 @@
 # Non-goals
 
-This file is the **explicit list of things we are not building** in the current scope, with the reason for each. It is the mirror of the scope described in `thesis.md`: where the thesis says "this is what we're building", non-goals say "this looked plausible but is deliberately out". Distinguish it from `backlog.md` (things we *will* build, just later) — a non-goal may never be built.
+This file is the **explicit list of things we are not building** in the current scope, with the reason for each. It is the mirror of the scope described in `thesis.md`: where the thesis says "this is what we're building", non-goals say "this looked plausible but is deliberately out". Distinguish it from `backlog.md` (things we _will_ build, just later) — a non-goal may never be built.
 
 Non-goals carry real weight. Every entry here is a constraint that future decisions should respect — a scope-creep guard. The reason field is load-bearing: without it, a non-goal looks like an arbitrary "no" that future-you will second-guess at the first complication. With the reason, future-you knows whether the non-goal still holds when circumstances change.
 
@@ -10,12 +10,8 @@ At milestone boundaries, scan this file. If a non-goal's re-evaluate trigger has
 
 ---
 
-- **No multi-region writes in M0.**
-  *Reason:* cost > benefit until 3+ paying customers in distinct regions.
-  *Re-evaluate when:* second paying customer signs in a non-primary region.
+- **No multi-region writes in M0.** _Reason:_ cost > benefit until 3+ paying customers in distinct regions. _Re-evaluate when:_ second paying customer signs in a non-primary region.
 
-- **No mobile app.**
-  *Reason:* product hypothesis is desktop-first; no validated mobile demand.
-  *Re-evaluate when:* >20% of dashboard sessions are mobile UA.
+- **No mobile app.** _Reason:_ product hypothesis is desktop-first; no validated mobile demand. _Re-evaluate when:_ >20% of dashboard sessions are mobile UA.
 
 - (add more here)

package/data/harnesses/code/skills/brainstorm/templates/questions.md

@@ -22,14 +22,15 @@ IDs are `QN`, stable while open, never reused after deletion.
 
 **Closes when.** [What resolution looks like — a pick between options, a confirmed fact, an accepted risk.]
 
-**Options.** *(optional — only when named by the user or entering converge)*
+**Options.** _(optional — only when named by the user or entering converge)_
+
 - A. [one line]
 - B. [one line]
 
-**Lean.** *(optional — the user's lean, never the skill's)*
+**Lean.** _(optional — the user's lean, never the skill's)_
 
-**Claude's take.** *(opt-in only — write only when the user asks for a recommendation on this question; delete if it goes stale)*
+**Claude's take.** _(opt-in only — write only when the user asks for a recommendation on this question; delete if it goes stale)_
 
-**Resolution lands in.** *(optional)* [pillar or doc + section]
+**Resolution lands in.** _(optional)_ [pillar or doc + section]
 
-**Blocks.** *(optional)* [milestone or other Q-numbers]
+**Blocks.** _(optional)_ [milestone or other Q-numbers]

package/data/harnesses/code/skills/brainstorm/templates/state.md

@@ -1,8 +1 @@
-STATE: open
-MODE: dump
-COMPLEXITY: medium
-SESSION STARTED: YYYY-MM-DD
-SESSION CLOSED:
-CURRENT TOPIC: (one line — updated on every topic shift)
-LAST SYNC: never
-SYNC IN FLIGHT: no
+STATE: open MODE: dump COMPLEXITY: medium SESSION STARTED: YYYY-MM-DD SESSION CLOSED: CURRENT TOPIC: (one line — updated on every topic shift) LAST SYNC: never SYNC IN FLIGHT: no

package/data/harnesses/code/skills/brainstorm/templates/tech.md

@@ -2,15 +2,15 @@
 
 This file holds the **technology choices** for the idea. It is seeded at bootstrap from the harness's opinionated stack (e.g. `.claude/rules/general.md` recommended-packages table) when one exists — those rows arrive as defaults, not decisions.
 
-Its job afterward is to be a **lens**: when a conversation move conflicts with a row here, the sync (or the skill, in the moment) surfaces it — *"you just proposed local component stores; the stack says Redux Toolkit — deviating or steering back?"* A confirmed deviation gets recorded below with its why; an unconfirmed conflict becomes an open question.
+Its job afterward is to be a **lens**: when a conversation move conflicts with a row here, the sync (or the skill, in the moment) surfaces it — _"you just proposed local component stores; the stack says Redux Toolkit — deviating or steering back?"_ A confirmed deviation gets recorded below with its why; an unconfirmed conflict becomes an open question.
 
 ## Stack
 
-| Layer | Choice | Source |
-|---|---|---|
-| [e.g. UI] | [react ^19] | harness default |
-| [e.g. state] | [@reduxjs/toolkit] | harness default |
-| [layer] | [choice] | decided this session — D[n] |
+| Layer        | Choice             | Source                      |
+| ------------ | ------------------ | --------------------------- |
+| [e.g. UI]    | [react ^19]        | harness default             |
+| [e.g. state] | [@reduxjs/toolkit] | harness default             |
+| [layer]      | [choice]           | decided this session — D[n] |
 
 ## Deviations
 

package/data/harnesses/code/skills/brainstorm/templates/thesis.md

@@ -1,6 +1,6 @@
 # Thesis
 
-This file is the **running narrative of what we are designing** — the single place a cold reader (or the next session) goes to understand the idea as it currently stands. It is rewritten freely as the idea evolves; it always describes the *current* shape, never the journey (writing posture per `build.md`'s mode).
+This file is the **running narrative of what we are designing** — the single place a cold reader (or the next session) goes to understand the idea as it currently stands. It is rewritten freely as the idea evolves; it always describes the _current_ shape, never the journey (writing posture per `build.md`'s mode).
 
 Keep it prose-first. If a section outgrows this file at high complexity, it may move to a numbered deep-dive doc (`01-foo.md`) at the session root with a one-line pointer left here.
 
@@ -10,7 +10,7 @@ Keep it prose-first. If a section outgrows this file at high complexity, it may
 
 ## Aspect map
 
-The thinking dimensions for *this* idea — proposed by the skill from the basis, edited by the user at `start`. The sync agent audits coverage against this list: an aspect with no content anywhere becomes an open question.
+The thinking dimensions for _this_ idea — proposed by the skill from the basis, edited by the user at `start`. The sync agent audits coverage against this list: an aspect with no content anywhere becomes an open question.
 
 - [ ] [aspect — e.g. users & jobs]
 - [ ] [aspect — e.g. domain model]