@zalom/plastic 1.0.3 → 1.1.0

package/skills/_decision-tables.md

@@ -0,0 +1,50 @@
+## Numbered Decision Tables
+
+The shared procedure for collecting owner rulings during any stage (Why, How, Exec).
+Any stage skill that needs the owner to choose between options or rule on a batch of
+open questions follows this procedure instead of improvising its own format.
+
+Read this when a stage skill's own text says to.
+
+### The procedure
+
+1. **Collect the candidate decisions.** Gather every open question or option set that
+   needs an owner ruling right now. Do not present them one at a time across separate
+   messages; batch them into a single collection first.
+
+2. **Present exactly ONE table.** Its first column is the row number. One decision per
+   row. Add a recommendation column stating the agent's recommended choice and a short
+   reason. Example shape:
+
+   | # | Decision | Recommendation |
+   |---|---|---|
+   | 1 | Ship the setting as a CLI flag or a config file? | Config file: survives across invocations |
+   | 2 | Retry, circuit breaker, or fallback for the flaky call? | Retry: matches existing error handling elsewhere in this module |
+
+3. **Let the owner rule by row number.** The owner responds with a ruling per row
+   number (e.g. "1: config file, 2: retry"). Do not require prose paragraphs back; a
+   row-number ruling is enough.
+
+4. **Persist each ruling immediately, one at a time.** For every ruling, before moving
+   to the next row, run:
+
+   ```
+   ruby ~/.plastic/scripts/insight-append {intent_dir} "<ruling text>" --stage <stage> --author human
+   ```
+
+   Never batch rulings into a single call and never wait until all rows are ruled to
+   start persisting. `<stage>` is the current stage (Why, How, or Exec). If a ruling
+   supersedes an earlier one already on record, append a second insight that names the
+   superseded decision and states plainly that this ruling supersedes it. Both insights
+   stay on record; the later one wins.
+
+5. **Write the full ruling set to a rulings file.** After the last row is ruled and
+   persisted, write the complete table plus every ruling to
+   `{intent_dir}/resources/rulings--<slug>.md` so the full set is readable in one place
+   alongside the per-row insights.
+
+### Why one table, not a chip per row
+
+A single table lets the owner rule on everything in one pass and reference row numbers
+in their reply. Multiple small prompts force the owner to context-switch per decision
+and make later replies ambiguous about which decision they answer.

package/skills/auto/SKILL.md

@@ -1,15 +1,15 @@
 ---
 name: plastic-auto
 description: >-
-  Autonomous intent delivery — agent takes over How and Exec. Use when user says
+  Autonomous intent delivery - agent takes over How and Exec. Use when user says
   "auto", "take it from here", "deliver this", or when brainstorming-grill-me concludes
   and user confirms autonomous execution. Requires an active intent in INDEX.md.
 user-invocable: true
 ---
 
-# Auto — Autonomous Intent Delivery
+# Auto - Autonomous Intent Delivery
 
-Announce: "Taking over intent [ID] — [name] for autonomous delivery."
+Announce: "Taking over intent [ID] - [name] for autonomous delivery."
 
 **Advisory (not a gate).** At auto-mode start, recommend once that the user run this
 orchestrating main session on the best available thinking model (Fable, Opus, or whatever
@@ -19,7 +19,7 @@ subagents keep their pinned tier and never resolve to Fable.
 
 ## Precondition
 
-An active intent MUST exist in INDEX.md. If none exists, refuse: "No active intent found. Create one first with /plastic-creating-intent."
+An active intent MUST exist in INDEX.md. If none exists, refuse: "No active intent found. Create one first with /plastic-intent-creating."
 
 If multiple active intents exist, ask the user which one to deliver (this is the only question auto asks).
 
@@ -31,8 +31,8 @@ next dispatchable intent:
 ruby ~/.plastic/scripts/dashboard.rb all --json
 ```
 
-Work `dispatchable_queue` in `rank` order (these are `defer`/`research` dispositions —
-safe to deliver autonomously). Leave `human_only` and `next_big_thing` for the user — those
+Work `dispatchable_queue` in `rank` order (these are `defer`/`research` dispositions -
+safe to deliver autonomously). Leave `human_only` and `next_big_thing` for the user - those
 are `drive`/`triage` items the human should lead. See the `plastic-dashboard` skill.
 
 QMD-first (when available): when the user describes the work to deliver rather than naming an
@@ -65,7 +65,7 @@ and artifact depth to that size. Extended walkthrough: `references/tiers.md`.
 
 ## Arm the Lifecycle Gate (do this FIRST)
 
-Immediately after selecting the intent — before any other work — arm auto mode. This
+Immediately after selecting the intent - before any other work - arm auto mode. This
 writes the session bridge that makes the code-edit gate live, so project code cannot be
 edited before the plan exists (the gate applies to YOU, the orchestrator):
 
@@ -88,7 +88,7 @@ Honor the cycle: What → Why (spec.md) → How (plan.md + actions/ + checklist.
 
 ## Flags
 
-- `--skip-permissions` — bypass hard stops on destructive actions on existing projects. Full trust mode. Default: off.
+- `--skip-permissions` - bypass hard stops on destructive actions on existing projects. Full trust mode. Default: off.
 
 ## Team Spin-Up
 
@@ -104,7 +104,7 @@ Roster (one role per cycle stage):
 - **plastic-executor** (code + checklist + `## Insights`)
 - **plastic-enforcer** (orchestrates + gates; that is YOU)
 
-Dispatch rule: sequential, one specialist per stage on one branch (the deliverables share files). Gate each deliverable against the stage's exit criteria before handing off. The How and Exec phases below default to Plastic's native dispatch (`plastic-executing-plan`) and delegate to the superpowers skills only when they are available or the user asks; do not restate the phase mechanics here.
+Dispatch rule: sequential, one specialist per stage on one branch (the deliverables share files). Gate each deliverable against the stage's exit criteria before handing off. The How and Exec phases below default to Plastic's native dispatch (`plastic-intent-executing`) and delegate to the superpowers skills only when they are available or the user asks; do not restate the phase mechanics here.
 
 Spawn preamble (live-state injection): before dispatching any specialist, run `scripts/spawn-preamble <intent_dir> --role <role>` and PREPEND its output to that specialist's prompt. The preamble is a deterministic, filesystem-only snapshot of the active intent (id, intent line, current stage, and the provisioned code worktree path when one exists on disk) plus the honoring instruction, so every spawned agent boots with accurate live state instead of guessing. This is the authoritative L2 mechanism for harnesses whose sub-agents do not inherit a top-level session event (see `docs/reference/harness-adapters.md`).
 
@@ -168,15 +168,15 @@ this is worth doing, or proceed).
 When entering at Why stage:
 
 1. Read existing `## Context` and `### Decisions` from the intent file
-2. Assess gaps — what decisions are missing? What context is incomplete?
-3. Self-directed research — read code, search docs, explore related intents (via wikilinks in `## Links`), web search if needed. NO questions to human.
-4. Adaptive budget — assess complexity and set your own research budget:
+2. Assess gaps - what decisions are missing? What context is incomplete?
+3. Self-directed research - read code, search docs, explore related intents (via wikilinks in `## Links`), web search if needed. NO questions to human.
+4. Adaptive budget - assess complexity and set your own research budget:
    - Simple (config change, small feature): 2-3 research steps
    - Medium (new feature, integration): 5-8 research steps
    - Complex (new project, architecture): 10-15 research steps
-5. Make decisions — pick best option, document in `## Context > ### Decisions` with rationale
+5. Make decisions - pick best option, document in `## Context > ### Decisions` with rationale
 6. Log all autonomous decisions in `## Insights` with `(autonomous)` marker: "Decision: chose X because Y (autonomous)"
-7. Write `spec.md` — consolidated specification
+7. Write `spec.md` - consolidated specification
 8. Notify user (Why briefing): brief per `references/human-report-contract.md`
    (State: the approach chosen, one line; Risk: the main trade-off; Call: the one decision
    needed, approve or pick an option).
@@ -191,9 +191,9 @@ intent birth and persists at every tier; only writing `ACTION_N.md` files into i
 only (S/M leave the directory empty).
 
 1. If `superpowers:writing-plans` is available as a skill, delegate plan creation to it. Tell it the plan saves to the active intent's directory (not `docs/superpowers/plans/`).
-2. Otherwise, write `plan.md` directly — implementation plan with numbered tasks
-3. Write `ACTION_N.md` files into the existing `actions/` directory (one per task, self-contained) — L only
-4. Write `checklist.md` — execution registry with checkboxes covering all actions
+2. Otherwise, write `plan.md` directly - implementation plan with numbered tasks
+3. Write `ACTION_N.md` files into the existing `actions/` directory (one per task, self-contained) - L only
+4. Write `checklist.md` - execution registry with checkboxes covering all actions
 5. Notify user (How briefing): brief per `references/human-report-contract.md`
    (State: the plan shape, task count and what it builds; Risk: the riskiest task or
    dependency; Call: approve the plan to build).
@@ -205,9 +205,9 @@ Then proceed to Exec.
 If the plan calls for creating a new project (the intent is an implementation intent that needs a new codebase):
 
 1. Determine project path from `~/.plastic/config.yml` `project_roots` or from intent context
-2. **Confirm path with user** — this is the ONE human interaction during auto delivery:
+2. **Confirm path with user** - this is the ONE human interaction during auto delivery:
    > "Creating project `<slug>` at `<path>`. Confirm path, or provide alternative."
-3. Invoke `plastic-creating-project` skill
+3. Invoke `plastic-project-creating` skill
 4. The global intent is now Completed (creating-project handles this)
 5. The tactical mirror in the project store becomes the active intent
 6. Continue execution from the project directory using the tactical intent
@@ -215,7 +215,7 @@ If the plan calls for creating a new project (the intent is an implementation in
 ## Exec Phase
 
 1. If `superpowers:subagent-driven-development` or `superpowers:executing-plans` is available, delegate execution to it
-2. Otherwise invoke `plastic-executing-plan`
+2. Otherwise invoke `plastic-intent-executing`
 3. Execute actions from checklist sequentially
 4. Check off items in `checklist.md` as completed
 5. Append observations to `## Insights` with `(autonomous)` marker
@@ -224,7 +224,7 @@ If the plan calls for creating a new project (the intent is an implementation in
    (State: what got built and the test result; Risk: residual failures or deviations;
    Call: go to review, or done).
 
-## Permission Model — Safe-by-Default
+## Permission Model - Safe-by-Default
 
 The agent MUST prefer non-destructive routes:
 
@@ -232,7 +232,7 @@ The agent MUST prefer non-destructive routes:
 |---|---|
 | Drop table | Rename to `_deprecated_<table>`, flag for cleanup |
 | Delete files | Move to `.archive/` or backup branch |
-| Alter column | Additive migration — new column + backfill |
+| Alter column | Additive migration - new column + backfill |
 | Remove feature | Feature flag off, code stays until human confirms |
 | Database migration | Backup before migration, keep rollback path |
 
@@ -247,7 +247,7 @@ With `--skip-permissions`, the agent logs the action in Insights but proceeds wi
 
 ### Greenfield Exception
 
-During initial project creation, all decisions are non-destructive by definition (there's nothing to destroy). The agent has full autonomy for greenfield choices — DB engine, framework, gems, architecture.
+During initial project creation, all decisions are non-destructive by definition (there's nothing to destroy). The agent has full autonomy for greenfield choices - DB engine, framework, gems, architecture.
 
 ## Completion
 
@@ -258,55 +258,38 @@ During initial project creation, all decisions are non-destructive by definition
    and End tail in PLASTIC.md `## Delivery Isolation and the Single-Owner Lock`).
 3. Write `## Outcome` summary in the intent file (1-2 sentences)
 4. **Release (if configured)**
-   1. Detect project — match CWD against paths in `~/.plastic/projects.yml` to find the project slug. If no match, skip to step 5 (default commit-only behavior).
+   1. Detect project - match CWD against paths in `~/.plastic/projects.yml` to find the project slug. If no match, skip to step 5 (default commit-only behavior).
    2. Read `~/.plastic/projects/{slug}/project.yml`. If the file doesn't exist or has no `release` key, skip to step 5.
    3. Based on `release.on_complete`:
-      - `commit` — git add + commit (same as default, proceed to step 5)
-      - `commit_and_push` — git add + commit + push
-      - `manual` — skip auto-commit, notify user: "Release configured as manual — commit when ready."
+      - `commit` - git add + commit (same as default, proceed to step 5)
+      - `commit_and_push` - git add + commit + push
+      - `manual` - skip auto-commit, notify user: "Release configured as manual - commit when ready."
    4. If `release.verify` is set, run the verify command (e.g. `bundle exec rake test`):
       - **Exit 0 (green):** proceed to sub-step 5
       - **Non-zero (red):** check `release.on_red`:
-        - `fix_and_retry` — attempt to fix the failure, re-run verify (max 2 retries)
-        - `stop` — write `savepoint.md` with current state, notify user: "Verify failed — savepoint written.", **STOP**
-        - `manual` — notify user: "Verify failed: [summary]. Resolve manually."
-   5. If `release.on_green` has items, invoke `plastic-releasing` to handle them (tag, changelog, publish, etc.). Do NOT duplicate release logic — delegate entirely.
+        - `fix_and_retry` - attempt to fix the failure, re-run verify (max 2 retries)
+        - `stop` - write `savepoint.md` with current state, notify user: "Verify failed - savepoint written.", **STOP**
+        - `manual` - notify user: "Verify failed: [summary]. Resolve manually."
+   5. If `release.on_green` has items, invoke `plastic-releasing` to handle them (tag, changelog, publish, etc.). Do NOT duplicate release logic - delegate entirely.
 5. Review `## Insights` for observations that should spawn future intents. If any:
-   - Create them (using `plastic-creating-intent` conventions)
+   - Create them (using `plastic-intent-creating` conventions)
    - Update `chain` in the current intent's frontmatter
-6. Move intent from `## Active` to `## Completed` in INDEX.md (with today's date). As the
-   closing act of the transfer, stamp the terminal ledger bookend (intent 81) so the savepoint's
-   last line records delivery:
+6. Run the mechanical close through `plastic-intent-ending`: it owns steps 1-6 of the Done
+   procedure (outcome/INDEX/savepoint/commit, disarm, and the QMD reindex last) as ONE
+   delegation, not five separate one-liners restated here. Run its backing script for the
+   outcome/INDEX/savepoint/commit core, passing `--index-note` with a rich Completed/
+   Abandoned entry description (mode/tier, what shipped or why abandoned, suite result):
    ```bash
-   ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.append_terminal_savepoint("<intent_dir>", "delivered")'
+   ruby ~/.plastic/scripts/end-intent --store <store_path> --id <ID> --disposition delivered \
+     --index-note "<mode, tier>; <what shipped>; <suite result>"
    ```
-   (Use `"abandoned"` instead when the intent is being moved to `## Abandoned`.) Idempotent.
-7. Auto-commit: `cd <store-root> && git add . && git commit -m "feat: deliver intent <ID> — <name>"`
-8. Disarm the lifecycle gate (auto delivery is finished). Substitute the intent's own id for
-   `<ID>` (a session can be delivering more than one intent at once, intent 131, so disarm must
-   name which of the session's bridges to clear):
-   ```bash
-   ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.disarm_auto(ENV["CLAUDE_CODE_SESSION_ID"], intent_id: "<ID>")'
-   ```
-   Disarm runs the ordered End tail (release worktrees, then clear the `delivery.lock`,
-   then the bridge becomes purge-eligible) and performs the mandatory worktree cleanup
-   (intent 73c3): both per-intent worktrees are removed and both repos pruned. This is
-   the plain remove path (no merge); when the work ships through a release, the release
-   path merges the branch BEFORE the worktree is removed instead of relying on this step.
-   Never leave an orphaned worktree, and run `git worktree prune` if you hit a stale
-   reference. For the full ordering rationale and the release-vs-plain-disarm
-   distinction, read `references/end-tail.md`.
-9. QMD reindex LAST (canonical End tail), run only after disarm has released the
-   worktrees, cleared the `delivery.lock`, and purged the bridge. It runs in the
-   background so it never blocks the turn:
-   ```bash
-   ruby ~/.plastic/scripts/qmd-sync reindex --store <store-root> --async
-   ```
-   `<store-root>` is the store that holds this intent (the global store or the project
-   store); the command is a no-op when QMD is absent. For why the reindex must be last
-   (so the index never references a bridge or lock about to disappear), read
-   `references/end-tail.md`.
-10. Notify user (Done briefing): brief per `references/human-report-contract.md`
+   (Use `--disposition abandoned` when the intent is being moved to `## Abandoned`.) Then
+   follow `plastic-intent-ending`'s Step 5 (disarm: `Bridge.disarm_auto` on this auto/curator
+   path, the plain-remove branch) and Step 6 (QMD reindex, async, last) exactly as that skill
+   states them. Never leave an orphaned worktree; run `git worktree prune` on a stale
+   reference. If any of this ever needs to change, change `plastic-intent-ending`, not this
+   skill.
+7. Notify user (Done briefing): brief per `references/human-report-contract.md`
     (State: the delivered impact; Risk: residual risk; Call: the decision left to you, merge,
     release, or accept). See `outcome.md` for details.
 
@@ -315,7 +298,7 @@ During initial project creation, all decisions are non-destructive by definition
 If the agent gets stuck (can't resolve a gap, dependency is missing, tests fail persistently):
 1. Log the blocker in `## Insights`
 2. Write `savepoint.md` with current state
-3. Notify user: "Blocked on intent [ID] — [name]: [description]. Savepoint written."
+3. Notify user: "Blocked on intent [ID] - [name]: [description]. Savepoint written."
 4. **STOP.** Do not attempt workarounds that could leave the project in a broken state.
 
 ## References

package/skills/auto/evals/evals.json

@@ -116,13 +116,13 @@
       "scope": "triggering",
       "set": "train",
       "prompt": "create a new intent for the dashboard idea",
-      "expected_output": "Does NOT activate plastic-auto; activates plastic-creating-intent.",
+      "expected_output": "Does NOT activate plastic-auto; activates plastic-intent-creating.",
       "files": [],
       "assertions": [
         {
           "type": "code",
           "check": "router CHOICE != plastic-auto",
-          "observed": "plastic-creating-intent",
+          "observed": "plastic-intent-creating",
           "result": "pass"
         }
       ]
@@ -132,13 +132,13 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "what's the status of my active intents?",
-      "expected_output": "Does NOT activate plastic-auto; this is a read/continuing/managing-index query.",
+      "expected_output": "Does NOT activate plastic-auto; this is a read/intent-continuing/store-indexing query.",
       "files": [],
       "assertions": [
         {
           "type": "code",
           "check": "router CHOICE != plastic-auto",
-          "observed": "plastic-managing-index",
+          "observed": "plastic-store-indexing",
           "result": "pass"
         }
       ]

package/skills/auto/references/agent-architecture.md

@@ -101,7 +101,7 @@ verifies state itself.
 ### Delegation
 
 The roles are thin handoff contracts, not a spawning engine. Dispatch and review run
-by default through Plastic's own engine, `plastic-executing-plan` (implementer plus
+by default through Plastic's own engine, `plastic-intent-executing` (implementer plus
 two-stage review, no external plugin). When `superpowers:subagent-driven-development`
 and `superpowers:dispatching-parallel-agents` are available, or the user asks for them,
 they delegate to those as an enhancement. The team model defines who hands what to whom
@@ -112,7 +112,7 @@ spawning.
 
 The default is always Plastic's native engine, so a user without superpowers still gets
 the full behavior. If the harness supports subagents but superpowers is absent, auto
-mode dispatches through `plastic-executing-plan`. If the harness has no subagent dispatch
+mode dispatches through `plastic-intent-executing`. If the harness has no subagent dispatch
 at all, auto mode falls back to a single agent walking the full What, Why, How, Exec
 cycle itself. The enforcer's gate discipline still applies in every case.
 

package/skills/dashboard/SKILL.md

@@ -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-intent-continuing` lands on the board on resume
 - `plastic-auto` reads `--json` to choose the next dispatchable intent
 
 ## Procedure (the Markdown board — default human surface)
@@ -84,7 +84,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`)

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-intent-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,6 +1,6 @@
 ---
 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 --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.'
 user-invocable: true
 ---
 

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

package/skills/intent-brainstorming/evals/evals.json

@@ -0,0 +1,67 @@
+{
+  "skill_name": "plastic-intent-brainstorming",
+  "notes": "Intent 66a. Spec for the QMD-first step in the Why/explore-context phase (surface prior decisions/specs/outcomes before grep/Read). Runner is intent 76; spec only. Intent 164 extended this file with the prose-grilling, conflict-supersession, and handoff-to-speccing scenarios; evals 2-4 are pending a real observed run per the plastic-evaluating-skills convention.",
+  "evals": [
+    {
+      "id": 1,
+      "scope": "behavior",
+      "set": "validation",
+      "prompt": "QMD is present. Brainstorming the active intent during the Why phase, the agent needs prior decisions and specs on caching.",
+      "expected_output": "In the explore-project-context (Why) step, before scanning the store with grep/Read, runs `ruby ~/.plastic/scripts/qmd-sync search \"caching decisions\"` to surface prior decisions, specs, or outcomes, then opens the authoritative intent file for any hit it acts on. No-op fallback to INDEX.md / file scan when QMD is absent.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "qmd-sync search is run during Why before grep/Read; authoritative file opened for any hit",
+          "observed": "SKILL.md (or agent file) 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"
+        }
+      ]
+    },
+    {
+      "id": 2,
+      "scope": "behavior",
+      "set": "validation",
+      "prompt": "During Why exploration for intent X, the owner first rules that a setting ships as a CLI flag. Later in the same session, after more discussion, the owner rules that it should ship as a config-file setting instead, explicitly reversing the earlier call.",
+      "expected_output": "The skill persists BOTH rulings as separate insight-append calls with --stage Why: one for the CLI-flag ruling when it was made, and a second for the config-file ruling that names the CLI-flag ruling as superseded and states that this ruling supersedes it. Neither call is skipped, merged, or batched.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "two separate `ruby ~/.plastic/scripts/insight-append {intent_dir} \"<ruling text>\" --stage Why --author human` calls are made, one per ruling, immediately as each ruling lands; the second insight names the superseded CLI-flag ruling and states supersession",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 3,
+      "scope": "behavior",
+      "set": "train",
+      "prompt": "Brainstorming a new intent about notification delivery, the agent needs to learn the owner's preferred channel (email, push, or SMS).",
+      "expected_output": "The agent asks a single conversational prose question about the preferred channel, one at a time, phrased as a sentence rather than a bulleted or lettered multiple-choice menu.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "the question is prose, not a chip/lettered multiple-choice menu; only one question is asked per message",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 4,
+      "scope": "behavior",
+      "set": "train",
+      "prompt": "Design for intent Y is presented and the owner has ruled on every open section.",
+      "expected_output": "The skill states the enriched Why is captured (Context, Decisions, one insight per ruling) and invokes /plastic-intent-speccing as the handoff. It does not write spec.md itself.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "no spec.md write action is taken by this skill; the terminal message names /plastic-intent-speccing and states spec.md is not authored here",
+          "result": "expect-pass"
+        }
+      ]
+    }
+  ]
+}