@zalom/plastic 1.0.3 → 1.1.1

package/skills/continuing/evals/evals.json

@@ -1,15 +1,15 @@
 {
   "skill_name": "plastic-continuing",
-  "notes": "Intent 36, updated for 36a (boot moved into hook-session-start; the skill is now work-continuation only). Scopes: description triggering (1-8) and behavior/convention compliance of the work-continuation skill (9-14). Triggering assertions follow the plastic-auto eval style (one subagent router per case). Behavior assertions are convention checks against the SKILL.md.",
+  "notes": "Intent 158a1. New bare front-door router restored per intent 96 (D8). Scopes: description triggering (1-5) and routing behavior (6-9), the latter checked as convention against SKILL.md's routing table.",
   "results": {
-    "triggering": { "cases": 8, "passed": 8, "run": "2026-06-16, one subagent per case" },
-    "behavior": { "cases": 6, "passed": 6, "evidence": "convention checks against skills/continuing/SKILL.md after the intent-36 rewrite; doctor --core verified at 0.07s with 9 liveness checks and full doctor unchanged at 30 checks" }
+    "triggering": { "cases": 5, "passed": 5, "run": "2026-07-10, one subagent per case" },
+    "behavior": { "cases": 4, "passed": 4, "evidence": "convention checks against skills/continuing/SKILL.md's routing table" }
   },
   "evals": [
     {
       "id": 1, "scope": "triggering", "set": "train",
       "prompt": "continue",
-      "expected_output": "Activates plastic-continuing (the bare 'continue' keyword is the documented trigger).",
+      "expected_output": "Activates plastic-continuing (the bare 'continue' keyword is the router's documented trigger).",
       "files": [],
       "assertions": [
         { "type": "code", "check": "router CHOICE == plastic-continuing", "observed": "plastic-continuing", "result": "pass" }
@@ -26,7 +26,7 @@
     },
     {
       "id": 3, "scope": "triggering", "set": "validation",
-      "prompt": "pick up where we left off in this project",
+      "prompt": "pick up where we left off",
       "expected_output": "Activates plastic-continuing.",
       "files": [],
       "assertions": [
@@ -34,26 +34,17 @@
       ]
     },
     {
-      "id": 4, "scope": "triggering", "set": "train",
-      "prompt": "boot plastic and show me where things stand",
-      "expected_output": "Activates plastic-continuing (continuing work + presenting state is the skill's purpose; boot itself is hook-owned).",
+      "id": 4, "scope": "triggering", "set": "validation",
+      "prompt": "where was I",
+      "expected_output": "Activates plastic-continuing (indirect trigger: a continue request that never says 'continue').",
       "files": [],
       "assertions": [
         { "type": "code", "check": "router CHOICE == plastic-continuing", "observed": "plastic-continuing", "result": "pass" }
       ]
     },
     {
-      "id": 5, "scope": "triggering", "set": "train",
-      "prompt": "continue delivering this intent autonomously, don't ask me",
-      "expected_output": "Does NOT settle on plastic-continuing for execution. Shares 'continue' but the autonomous-delivery intent routes to plastic-auto.",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE == plastic-auto", "observed": "plastic-auto", "result": "pass" }
-      ]
-    },
-    {
-      "id": 6, "scope": "triggering", "set": "validation",
-      "prompt": "continue the for-loop to the next iteration in this function",
+      "id": 5, "scope": "triggering", "set": "validation",
+      "prompt": "continue the for-loop in this function",
       "expected_output": "Does NOT activate plastic-continuing. Near-miss: shares 'continue' but is a code-editing task.",
       "files": [],
       "assertions": [
@@ -61,84 +52,39 @@
       ]
     },
     {
-      "id": 7, "scope": "triggering", "set": "train",
-      "prompt": "resume the paused background download",
-      "expected_output": "Does NOT activate plastic-continuing. Near-miss: shares 'resume' but is unrelated to Plastic sessions.",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE != plastic-continuing", "observed": "none", "result": "pass" }
-      ]
-    },
-    {
-      "id": 8, "scope": "triggering", "set": "validation",
-      "prompt": "what's the dashboard look like right now",
-      "expected_output": "May activate plastic-dashboard rather than plastic-continuing; an overview request without 'continue/resume' is a dashboard task.",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE != plastic-continuing", "observed": "plastic-dashboard", "result": "pass" }
-      ]
-    },
-    {
-      "id": 9, "scope": "behavior", "set": "train",
-      "prompt": "Does the skill defer boot to the SessionStart hook rather than running it itself?",
-      "expected_output": "SKILL.md states boot (health check, core context, version banner, statusline) is owned by hook-session-start / plastic-statusline, not this skill.",
-      "files": ["skills/continuing/SKILL.md"],
-      "assertions": [
-        { "type": "convention", "check": "SKILL.md says boot is owned by the SessionStart hook and the skill does not run it", "observed": "'Boot is not this skill's job.' paragraph naming hook-session-start and plastic-statusline", "result": "pass" }
-      ]
-    },
-    {
-      "id": 10, "scope": "behavior", "set": "train",
-      "prompt": "Does the skill avoid running doctor / setting the statusline itself?",
-      "expected_output": "SKILL.md does NOT instruct running doctor.rb --core or setting the statusline; it attributes those to the hooks.",
-      "files": ["skills/continuing/SKILL.md"],
-      "assertions": [
-        { "type": "convention", "check": "no in-skill boot step invokes doctor.rb --core or sets the statusline; both are attributed to hooks", "observed": "doctor --core and statusline mentioned only as hook-owned in the 'Boot is not this skill's job' note", "result": "pass" }
-      ]
-    },
-    {
-      "id": 11, "scope": "behavior", "set": "train",
-      "prompt": "Is dashboard selection project-aware?",
-      "expected_output": "Project loaded -> `dashboard.rb project <slug>`; otherwise -> `dashboard.rb continue`. Skill only invokes, does not render.",
-      "files": ["skills/continuing/SKILL.md"],
-      "assertions": [
-        { "type": "convention", "check": "both dashboard invocations present and gated on project detection", "observed": "'dashboard.rb project <slug>' and 'dashboard.rb continue' in the 'Continue (present the dashboard)' section", "result": "pass" }
-      ]
-    },
-    {
-      "id": 12, "scope": "behavior", "set": "validation",
-      "prompt": "Is ledger-resume conditional and ledger-driven?",
-      "expected_output": "Resume fires only when a specific intent is named; reads savepoint.md last line as stage, verifies the stage file, rebuilds on drift, derives next step from first unchecked checklist item.",
+      "id": 6, "scope": "behavior", "set": "train",
+      "prompt": "continue",
+      "expected_output": "Bare 'continue' with no further target dispatches to the project route (plastic-project-continuing), the routing table's default.",
       "files": ["skills/continuing/SKILL.md"],
       "assertions": [
-        { "type": "convention", "check": "Conditional Ledger-Resume section reads last ledger line, verifies stage file, calls rebuild_savepoint on drift, uses first unchecked checklist item", "observed": "all four present in 'Conditional Ledger-Resume'", "result": "pass" }
+        { "type": "convention", "check": "routing table's default row maps bare continue/resume/no target to plastic-project-continuing", "observed": "present", "result": "pass" }
       ]
     },
     {
-      "id": 13, "scope": "behavior", "set": "validation",
-      "prompt": "Are the stale prose-savepoint fields gone?",
-      "expected_output": "No 'In progress' / 'Blockers' fields read from a prose savepoint remain; the ledger model is used instead.",
+      "id": 7, "scope": "behavior", "set": "train",
+      "prompt": "continue --intent 4a",
+      "expected_output": "Dispatches to the intent route (plastic-intent-continuing).",
       "files": ["skills/continuing/SKILL.md"],
       "assertions": [
-        { "type": "convention", "check": "no prose-savepoint announce template (In progress / Blockers from prose)", "observed": "absent; announce uses Stage/Next step/Context/Drift derived from ledger + checklist", "result": "pass" }
+        { "type": "convention", "check": "routing table maps --intent {id} to plastic-intent-continuing", "observed": "present", "result": "pass" }
       ]
     },
     {
-      "id": 14, "scope": "behavior", "set": "validation",
-      "prompt": "Is the 'Determine Store' local-store gap filled?",
-      "expected_output": "Step 2 of Determine Store describes local/project-store detection (no empty step).",
+      "id": 8, "scope": "behavior", "set": "validation",
+      "prompt": "resume the statusline-coloring intent",
+      "expected_output": "Dispatches to the intent route (plastic-intent-continuing): a specific intent named by description.",
       "files": ["skills/continuing/SKILL.md"],
       "assertions": [
-        { "type": "convention", "check": "Determine Store step 2 documents local/project store detection via projects.yml + CWD match", "observed": "filled", "result": "pass" }
+        { "type": "convention", "check": "routing table maps a named specific intent (by id or description) to plastic-intent-continuing", "observed": "present", "result": "pass" }
       ]
     },
     {
-      "id": 15, "scope": "behavior", "set": "validation",
-      "prompt": "QMD is present. The user says: continue the work on the statusline coloring (names the intent by description, not id).",
-      "expected_output": "Before scanning the store with grep/Read to locate the named intent, runs `ruby ~/.plastic/scripts/qmd-sync search \"statusline coloring\"` to surface the candidate intent, then opens the authoritative intent file for the hit it resumes. No-op fallback to INDEX.md / file scan when QMD is absent.",
+      "id": 9, "scope": "behavior", "set": "validation",
+      "prompt": "continue the consistency-dividend roadmap",
+      "expected_output": "Dispatches to the roadmap route (plastic-roadmap-continuing).",
       "files": ["skills/continuing/SKILL.md"],
       "assertions": [
-        { "type": "human", "check": "qmd-sync search is run before grep/Read when the intent is named by description; authoritative file opened for the hit", "observed": "Conditional Ledger-Resume carries the QMD-first step: run qmd-sync search before grep/Read, then open the authoritative file; no-op fallback when QMD is absent", "result": "pass" }
+        { "type": "convention", "check": "routing table maps a named roadmap/delivery batch to plastic-roadmap-continuing", "observed": "present", "result": "pass" }
       ]
     }
   ]

package/skills/dashboard/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: plastic-dashboard
-description: Use when the user wants an overview of intents, asks "where are we", "what's next", "what should I work on", "show the dashboard", or invokes /plastic-dashboard. Renders a deterministic Value×Effort work cockpit as Markdown across the global store and all projects, and emits a machine-readable queue that auto mode consumes.
+description: Use when the user wants an overview of intents, asks "where are we", "what's next", "what should I work on", "show the dashboard", or invokes /plastic-dashboard. Renders the intent store(s) as Markdown prose, the global board as a narrative of work done, each project board as a short summary plus its most-valuable next work, and emits a machine-readable queue that auto mode consumes.
 user-invocable: false
 ---
 
 # Dashboard — Plastic Work Cockpit
 
 A deterministic overview of the intent store(s). It answers three questions at a glance:
-**where we are** (recently worked), **where we go next** (a Value×Effort matrix), and
+**where we are** (recently worked), **where we go next** (the most-valuable next work), and
 **how to conduct it** (a disposition per intent). The human-facing surface is **Markdown**,
 because the user's UI renders Markdown natively but collapses raw tool-call stdout.
 
@@ -19,7 +19,7 @@ state → byte-identical payload, regardless of model. Do NOT hand-summarize int
 
 - User invokes `/plastic-dashboard`
 - User asks "where are we", "what's next", "what should I work on", "show me the intents"
-- `plastic-continuing` lands on the board on resume
+- `plastic-project-continuing` lands on the board on resume
 - `plastic-auto` reads `--json` to choose the next dispatchable intent
 
 ## Procedure (the Markdown board — default human surface)
@@ -34,9 +34,9 @@ ruby ~/.plastic/scripts/dashboard.rb [continue|project <slug>] --data
 - `project <slug>` → that **project** board payload (`mode: "project"`).
 
 The payload is read-only JSON. Global-board fields: `date`, `store_health`, `recently_worked`,
-`matrix` (`quick_win`/`next_big`/`defer`/`triage`/`research`, each a list of `{line, bullet, ...}`),
-`counts`, `projects`, `project_totals`. Project-board fields: `slug`, `store_health`,
-`description`, `recently_worked`, `matrix`, `counts`, `active`, `future`.
+`next_work` (a flat, rank-ordered list of `{id, intent, scope, lifecycle, value, disposition,
+flags, line}`), `counts`, `projects`, `project_totals`. Project-board fields: `slug`,
+`store_health`, `description`, `recently_worked`, `next_work`, `counts`, `active`, `future`.
 
 Each board load runs the scoped store check (`doctor --store <scope>`): the global board runs
 `--store global` and a project board runs `--store <slug>`. The result rides in the payload as
@@ -51,13 +51,16 @@ Templates live in this skill's `templates/` directory:
 `~/.claude/skills/plastic-dashboard/templates/dashboard-global.md` and
 `dashboard-project.md`.
 
-Fill mechanically — no rewriting, no re-sorting:
-- `{{a.b.count}}` → the integer (e.g. `matrix.quick_win.count` = that list's length).
+Fill mechanically, no rewriting, no re-sorting:
+- `{{a.b.count}}` → the integer (e.g. `counts.active` = that count).
 - `{{...lines}}` → join the list's `.line` strings with **real newlines** (one per line).
-  These lines are already glyph-led (the glyph is the bullet — never add `-`, never emit
-  `<br>`). If a matrix quadrant list is empty, render `_(none)_`.
+  These are ordinary prose lines, not glyph-led bullets: never add a Markdown `-` bullet,
+  never emit `<br>`. If a list is empty, render `_(none)_`.
+- `next_work.lines` → the most-valuable next work, already ranked; each line reads
+  `"<id> <intent, truncated>"`. Use each entry's `disposition`/`flags` fields when the prose
+  needs to say why an item is next.
 - `projects.lines` → one line per project:
-  `- **{slug}** — {description} · active {active} · done {done} · future {future} · last accessed {last_accessed_at[0,10]}`.
+  `- **{slug}**: {description}, active {active}, done {done}, future {future}, last accessed {last_accessed_at[0,10]}`.
 - Scalars (`{{date}}`, `{{slug}}`, `{{description}}`) → substitute verbatim.
 
 ### Step 3 — Present it (mandatory, every invocation)
@@ -84,7 +87,7 @@ a no-op when QMD is absent, so fall back to the existing INDEX.md / file scan.
 The board lists everything; the user navigates by free prose (no capped picker):
 - On the **global** board, the user replies with an **intent id** (work it), a **project
   name** (re-run `project <slug> --data` and present that board), or **"new"** (start a new
-  intent in global via `plastic-creating-intent`).
+  intent in global via `plastic-intent-creating`).
 - On a **project** board, the user replies with an **intent id**, or **"global"** to return.
 
 ## Auto-mode contract (`--json`)
@@ -112,7 +115,7 @@ a raw terminal. The Markdown board (`--data` + template) is the surface for the
 ## How classification works (deterministic)
 
 The script computes Effort/Value/Flags/Override/Caps; the agent never re-derives them.
-To explain or debug a quadrant assignment, read `references/classification.md`.
+To explain or debug a ranking or disposition, read `references/classification.md`.
 
 ## Eval
 
@@ -123,7 +126,7 @@ intentional change means the skill is broken.
 
 ## Notes
 
-- Quadrant lists are **not** Markdown `-` bullets — the glyph is the bullet (the boards are
-  UI-only and may evolve, so they need not be valid Markdown lists). Never emit `<br>`.
+- Board lines are ordinary prose, not a rigid grid: the boards are UI-only and may evolve,
+  so they need not be valid Markdown lists. Never emit `<br>`.
 - Clusters (Zettelkasten grouping in INDEX.md) are intentionally not rendered.
 - Additive: changes no core lifecycle, gate, or cycle logic.

package/skills/dashboard/references/classification.md

@@ -1,7 +1,7 @@
 # How Classification Works (Deterministic)
 
 The script (`dashboard.rb`) computes Effort/Value/Flags/Override/Caps deterministically;
-the agent never re-derives them. Read this to explain or debug a quadrant assignment.
+the agent never re-derives them. Read this to explain or debug a ranking or disposition.
 
 - **Effort** — small for `research`/`exploration`/`bugfix`, for already-scoped intents
   (plan/checklist exists), or a **branch id** (folgezettel depth ≥ 2, e.g. `4a`, `12b3`); big
@@ -16,7 +16,7 @@ the agent never re-derives them. Read this to explain or debug a quadrant assign
   the staleness threshold. All three kept low-noise by design.
 - **Override** — a `value: high|low` frontmatter field always wins (pre-stamped data, never
   model judgment at render time).
-- **Caps** — quadrant lists and the project board's `active`/`future` lists are capped at 8
-  entries plus a trailing "+N more" line; each entry's text is truncated to 120 characters
+- **Caps**: the next-work list and the project board's `active`/`future` lists are capped at
+  8 entries plus a trailing "+N more" line; each entry's text is truncated to 120 characters
   with a trailing ellipsis. Applies to the Markdown board only (the ASCII renderer has its own
   separate `CELL_CAP`).

package/skills/dashboard/templates/dashboard-global.md

@@ -1,31 +1,16 @@
-# 🧩 Plastic · Global Board — {{date}}
+# 🧩 Plastic · Global Board, {{date}}
 
-**Recently worked** · last 24h
+**Recently worked** (last 24h)
 {{recently_worked.lines}}
 
-## Where we go next · Value × Effort  *(global intents only)*
+## Where we are
 
-|  | Small effort | Big effort |
-|---|---|---|
-| **High value** | ⚡ **Quick win** · {{matrix.quick_win.count}} | ★ **Next big thing** · {{matrix.next_big.count}} |
-| **Low value** | → **Defer (agent)** · {{matrix.defer.count}} | ⚑ **Triage** · {{matrix.triage.count}} |
+{{counts.active}} intents active, {{counts.done}} done, {{counts.future}} queued for later.
 
-**⚡ Quick win** — small effort, high value
-{{matrix.quick_win.lines}}
-
-**★ Next big thing** — big effort, high value
-{{matrix.next_big.lines}}
-
-**→ Defer (agent)** — small effort, low value
-{{matrix.defer.lines}}
-
-**⚑ Triage** — big effort, low value
-{{matrix.triage.lines}}
-
-🔬 **Research → agent**
-{{matrix.research.lines}}
-
-## Projects · active {{project_totals.active}} · done {{project_totals.done}} · future {{project_totals.future}}
+## Projects, active {{project_totals.active}}, done {{project_totals.done}}, future {{project_totals.future}}
 {{projects.lines}}
 
+## Most-valuable next work
+{{next_work.lines}}
+
 **What would you like to work on next?** (type an **intent id**, a **project name**, or anything **new** you'd like to start)

package/skills/dashboard/templates/dashboard-project.md

@@ -1,33 +1,11 @@
-# 📦 {{slug}} · Project Board — {{date}}
+# 📦 {{slug}} · Project Board, {{date}}
 
 {{description}}
 
-**Recently worked** · last 24h
+**Recently worked** (last active work, last 24h)
 {{recently_worked.lines}}
 
-## Where we go next · Value × Effort
-
-|  | Small effort | Big effort |
-|---|---|---|
-| **High value** | ⚡ **Quick win** · {{matrix.quick_win.count}} | ★ **Next big thing** · {{matrix.next_big.count}} |
-| **Low value** | → **Defer (agent)** · {{matrix.defer.count}} | ⚑ **Triage** · {{matrix.triage.count}} |
-
-**⚡ Quick win** — small effort, high value
-{{matrix.quick_win.lines}}
-
-**★ Next big thing** — big effort, high value
-{{matrix.next_big.lines}}
-
-**→ Defer (agent)** — small effort, low value
-{{matrix.defer.lines}}
-
-**⚑ Triage** — big effort, low value
-{{matrix.triage.lines}}
-
-🔬 **Research → agent**
-{{matrix.research.lines}}
-
-## Intents · active {{counts.active}} · done {{counts.done}} · future {{counts.future}}
+## Intents, active {{counts.active}}, done {{counts.done}}, future {{counts.future}}
 
 **Active**
 {{active.lines}}
@@ -35,6 +13,9 @@
 **Future**
 {{future.lines}}
 
-**Legend** · ○ What ◔ Why ◑ How ◕ Exec ● Done · ⚡ quick win ★ big → defer ⚑ triage 🔬 research
+## Most-valuable next work
+{{next_work.lines}}
+
+**Legend** · ○ What ◔ Why ◑ How ◕ Exec ● Done
 
 **What would you like to work on next?** (type an **intent id**, or **global** to go back)

package/skills/doctor/SKILL.md

@@ -13,7 +13,7 @@ Doctor has three scopes. Pick the right one for the situation:
 | Scope | Flag | When it runs | States |
 |-------|------|--------------|--------|
 | Core check | `--core` | SessionStart hook (automatic), also available on demand | Binary: pass or error |
-| Store check | `--store [global\|<slug>]` | Dashboard load, `plastic-continuing` | Three-state: pass / warn / fail |
+| Store check | `--store [global\|<slug>]` | Dashboard load, `plastic-project-continuing` | Three-state: pass / warn / fail |
 | Full check | (no flag) | After every update (automatic), or `/plastic-doctor` | Three-state: pass / warn / fail |
 
 ### `--core` (binary, manifest-backed)
@@ -118,9 +118,9 @@ Use the `fix_hint` value to determine the correct action:
 | "Add missing entries to INDEX.md" | Add orphaned intents to the appropriate INDEX.md section |
 | "Remove stale references from INDEX.md" | Edit INDEX.md to remove ghost references |
 | "Inject the missing required frontmatter field(s)" | Edit the intent's `{ID}--{slug}.md` frontmatter to add the missing key (e.g. `chain: []`) without touching other keys |
-| "Run: provision-project-store {slug}" | Run `provision-project-store <slug>` (or invoke the `plastic-add-project-store` skill) to create the missing store |
+| "Run: provision-project-store {slug}" | Run `provision-project-store <slug>` (or invoke the `plastic-store-provisioning` skill) to create the missing store |
 | "Re-run installer" | Run `npx -y @zalom/plastic@<channel> install --agent <agent>` (channel: -alpha->@alpha, -beta->@beta, else @latest) |
-| "Dispatch plastic-intent-curator ... revisions.md ..." | Invoke the `plastic-intent-curator` (or the agent) to relocate the flagged section or ref into the intent's `revisions.md` via move-and-record (one dated, `[rule: <tag>]`-tagged entry per item), per PLASTIC.md > Structural maintenance and revisions.md. For a missing required section, restore or reproject it instead. |
+| "Dispatch plastic-store-curating ... revisions.md ..." | Invoke the `plastic-store-curating` (or the agent) to relocate the flagged section or ref into the intent's `revisions.md` via move-and-record (one dated, `[rule: <tag>]`-tagged entry per item), per PLASTIC.md > Structural maintenance and revisions.md. For a missing required section, restore or reproject it instead. |
 
 For fixes the agent cannot handle automatically, explain what the user needs
 to do manually. The `revisions.md` remedy is curator-applied (a move-and-record

package/skills/install/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: plastic-install
-description: Use when initializing Plastic globally (~/.plastic/) or locally in a project, or to re-install/repair a broken installation. Accepts channel flags (--alpha, --beta, --latest) to select release channel. First install defaults to --beta; reinstalls match the already-installed channel. Global install is recommended: it creates the global intent store as a git-backed repository. Local install creates .plastic/ in the current project for testing.
+description: 'Use when initializing Plastic globally (~/.plastic/) or locally in a project, or to re-install/repair a broken installation. Accepts channel flags (--alpha, --beta, --latest) to select release channel. First install defaults to --latest (stable); reinstalls match the already-installed channel. Global install is recommended: it creates the global intent store as a git-backed repository. Local install creates .plastic/ in the current project for testing.'
 user-invocable: true
 ---
 
 # Install Plastic
 
-> **Recommended path:** for a first install, run `npx -y @zalom/plastic@beta install --claude`
-> in your shell (or `bunx -y @zalom/plastic@beta install --claude` if you use Bun). This skill
+> **Recommended path:** for a first install, run `npx -y @zalom/plastic@latest install --claude`
+> in your shell (or `bunx -y @zalom/plastic@latest install --claude` if you use Bun). This skill
 > exists to **re-install or repair** an existing setup from inside the agent, and to
 > drive interactive global configuration. Whenever this skill performs an install or
 > re-install, it **runs `/plastic-doctor` afterward** and reports the result.
@@ -16,7 +16,7 @@ user-invocable: true
 
 If Plastic is installed, derive `<channel>` from `~/.plastic/VERSION`: a version containing
 `-alpha` means `@alpha`, `-beta` means `@beta`, otherwise `@latest`. If not installed
-(first install), default to `@beta`. The user can always override with
+(first install), default to `@latest`. The user can always override with
 `--alpha` / `--beta` / `--latest`.
 
 ## Re-install / repair
@@ -35,18 +35,18 @@ Then **run `/plastic-doctor`** and report what it found.
 
 | Flag | Behavior |
 |------|----------|
-| `--latest` | Install from the stable channel |
-| `--beta` | Install from the beta channel (default on a first install) |
+| `--latest` | Install from the stable channel (default on a first install) |
+| `--beta` | Install from the beta channel |
 | `--alpha` | Install from the alpha channel |
 
 When invoked from within Claude Code (re-install or channel switch), the skill
 runs the appropriate npx command:
 
 ```bash
-# Stable
+# Stable (default on a first install)
 npx -y @zalom/plastic@latest install --claude
 
-# Beta (default on a first install)
+# Beta
 npx -y @zalom/plastic@beta install --claude
 
 # Alpha
@@ -68,10 +68,10 @@ Run `/plastic-install` with no arguments.
 Check if `~/.plastic/VERSION` exists.
 - If yes: announce "Plastic is already installed at ~/.plastic/. Run `/plastic-update` to
   sync core files, or use the re-install command above to repair in place."
-- If no: run the fresh install command (default `@beta`, or the channel the user named):
+- If no: run the fresh install command (default `@latest`, or the channel the user named):
 
 ```bash
-npx -y @zalom/plastic@beta install --claude
+npx -y @zalom/plastic@latest install --claude
 ```
 
 This single command, via `install.rb` (`bootstrap` + `distribute`), creates `store/`,

package/skills/{brainstorming → intent-brainstorming}/SKILL.md

@@ -1,19 +1,19 @@
 ---
-name: plastic-brainstorming
-description: "Explore intent requirements and design before implementation. Produces spec.md in the active intent directory."
+name: plastic-intent-brainstorming
+description: "Explore intent requirements and design before implementation, through conversational prose questions asked one at a time (no multiple-choice chips), persisting each owner ruling immediately as an insight. Produces the enriched Why (Context and Decisions) in the active intent directory; hands off to /plastic-intent-speccing for spec.md."
 user-invocable: true
 ---
 
 # Brainstorming Ideas Into Designs
 
-Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+Help turn ideas into fully formed designs through natural collaborative dialogue.
 
-Announce: "I'm using the brainstorming skill to explore the design for intent {id} — {name}."
+Announce: "I'm using the brainstorming skill to explore the design for intent {id}: {name}."
 
-Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
+Start by understanding the current project context, then ask questions one at a time, in prose, to refine the idea. Once you understand what you're building, present the design and collect the owner's rulings on it. This skill's product is the enriched Why, not spec.md.
 
 <HARD-GATE>
-Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
+Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has ruled on it. This applies to EVERY project regardless of perceived simplicity.
 </HARD-GATE>
 
 ## Active Intent Gate
@@ -21,34 +21,32 @@ Do NOT invoke any implementation skill, write any code, scaffold any project, or
 Before proceeding, resolve the active intent:
 
 1. **Detect store:** Read `~/.plastic/projects.yml`, match CWD against registered project paths. If match → project store at `~/.plastic/projects/{slug}/store/`. If no match → global store at `~/.plastic/store/`.
-2. **Find active intent:** Read `INDEX.md` from the detected store. Look under `## Active`. If exactly one → use it. If multiple → ask which. If none → refuse: "No active intent. Create one first with /plastic-creating-intent"
+2. **Find active intent:** Read `INDEX.md` from the detected store. Look under `## Active`. If exactly one → use it. If multiple → ask which. If none → refuse: "No active intent. Create one first with /plastic-intent-creating"
 3. **Resolve intent directory:** `{store}/store/{id}--{slug}/`
 
 All artifacts go to the intent directory. Never write to external paths.
 
 ## Anti-Pattern: "This Is Too Simple To Need A Design"
 
-Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
+Every project goes through this process. A todo list, a single-function utility, a config change: all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get a ruling.
 
 ## Checklist
 
 You MUST create a task for each of these items and complete them in order:
 
-1. **Explore project context** — check files, docs, recent commits, read active intent
-2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
-3. **Propose 2-3 approaches** — with trade-offs and your recommendation
-4. **Present design** — in sections scaled to their complexity, get user approval after each section
-5. **Write spec** — save to `{intent_dir}/spec.md` and commit to store repo
-6. **Spec self-review** — placeholder scan, consistency, scope, ambiguity
-7. **User reviews written spec** — ask user to review before proceeding
-8. **Transition to planning** — invoke `plastic-writing-plans`
+1. **Explore project context**: check files, docs, recent commits, read active intent
+2. **Grill in prose**: ask conversational prose questions, one at a time, no multiple-choice chips; understand purpose/constraints/success criteria
+3. **Propose 2-3 approaches**: with trade-offs and your recommendation
+4. **Present design**: in sections scaled to their complexity, get a ruling after each section
+5. **Collect rulings**: for each owner ruling, immediately persist it (see Collect rulings below); never batch
+6. **Hand off to /plastic-intent-speccing**: the enriched Why is done; do not author spec.md here
 
 ## Process Flow
 
-The Checklist above states the ordered flow (steps 1-8). For the same flow as a
+The Checklist above states the ordered flow (steps 1-6). For the same flow as a
 diagram, read `references/design-principles.md`.
 
-**The terminal state is invoking `plastic-writing-plans`.** Do NOT invoke any other implementation skill. The ONLY skill you invoke after brainstorming is `plastic-writing-plans`.
+**The terminal state is the handoff below.** Do NOT invoke any implementation skill and do NOT write spec.md. Brainstorming's product is the enriched Why.
 
 ## The Process
 
@@ -56,9 +54,9 @@ diagram, read `references/design-principles.md`.
 - QMD-first (when available): before scanning the store with grep/Read for prior decisions, specs, or outcomes, run `ruby ~/.plastic/scripts/qmd-sync search "<terms>"` to surface candidate, prior, or related intents, then open the authoritative intent file for any hit you act on. The command is a no-op when QMD is absent, so fall back to the existing INDEX.md / file scan.
 - Check out the current project state first (files, docs, recent commits)
 - Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
-- If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
-- For appropriately-scoped projects, ask questions one at a time to refine the idea
-- Prefer multiple choice questions when possible, but open-ended is fine too
+- If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own Why → spec → plan → implementation cycle.
+- For appropriately-scoped projects, ask questions one at a time, in prose, to refine the idea
+- Ask conversational prose questions, not multiple-choice chips. A short menu of named options is fine when the choice is genuinely enumerable, but phrase it as a sentence, not a bulleted picker.
 - Only one question per message - if a topic needs more exploration, break it into multiple questions
 - Focus on understanding: purpose, constraints, success criteria
 
@@ -80,39 +78,39 @@ guidance (what makes a good interface, when a file has grown too large) and
 existing-codebase guidance (follow established patterns, fold in targeted
 improvements without unrelated refactoring).
 
-## After the Design
-**Documentation:**
-- Write the validated design (spec) to `{intent_dir}/spec.md` using the `${CLAUDE_PLUGIN_ROOT}/templates/spec.md` form
-- Use elements-of-style:writing-clearly-and-concisely skill if available
-- Commit to the store repo:
-  ```
-  cd {store_root} && git add . && git commit -m "docs: spec for intent {id} — {name}"
-  ```
+## Collect rulings
 
-**Spec Self-Review:**
-After writing the spec document, look at it with fresh eyes:
-1. **Placeholder scan:** Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
-2. **Internal consistency:** Do any sections contradict each other? Does the architecture match the feature descriptions?
-3. **Scope check:** Is this focused enough for a single implementation plan, or does it need decomposition?
-4. **Ambiguity check:** Could any requirement be interpreted two different ways? If so, pick one and make it explicit.
+Each owner ruling triggers one immediate persist call, never a batch. The moment the
+owner rules on a question or a design section, before moving to the next one, run:
 
-Fix any issues inline. No need to re-review — just fix and move on.
+```
+ruby ~/.plastic/scripts/insight-append {intent_dir} "<ruling text>" --stage Why --author human
+```
 
-**User Review Gate:**
-After the spec review loop passes, ask the user to review the written spec before proceeding:
-> "Spec written and committed to `{intent_dir}/spec.md`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
+When a later ruling conflicts with an earlier one already on record, append a new
+insight that names the superseded ruling and states plainly that this one supersedes
+it. Both insights stay on record; the later one wins.
 
-Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.
+When presenting a batch of design options or rulings for the owner to choose, read
+`~/.plastic/_decision-tables.md` and follow the numbered-table procedure.
 
-**Implementation:**
-- Invoke `plastic-writing-plans` to create the implementation plan
-- Do NOT invoke any other skill. `plastic-writing-plans` is the next step.
+## Handoff
+
+Why exploration complete. The enriched Why is captured (Context, Decisions, one
+insight per ruling). Invoke /plastic-intent-speccing to consolidate it into spec.md.
+Do not author spec.md here.
+
+## Gate position
+
+- **Before:** an active intent exists with the lock armed.
+- **Produces:** the enriched Why (`## Context`, `### Decisions`, one `## Insights` entry per ruling).
+- **Next:** /plastic-intent-speccing consolidates the enriched Why into spec.md.
 
 ## Key Principles
 
 - **One question at a time** - Don't overwhelm with multiple questions
-- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **Prose, not chips** - Ask conversational prose questions; skip multiple-choice menus
 - **YAGNI ruthlessly** - Remove unnecessary features from all designs
 - **Explore alternatives** - Always propose 2-3 approaches before settling
-- **Incremental validation** - Present design, get approval before moving on
+- **Incremental validation** - Present design, collect a ruling before moving on
 - **Be flexible** - Go back and clarify when something doesn't make sense