@zalom/plastic 1.14.1 → 2.0.0-alpha.10

package/skills/intent-ending/SKILL.md

@@ -24,7 +24,7 @@ installed directory.
 | # | Step | Who does it |
 |---|---|---|
 | 0 | Precondition check | You, before touching outcome.md |
-| 1 | outcome.md + intent-file `## Outcome` summary | `scripts/end-intent` |
+| 1 | backfill spec/plan/action/outcome from the record, self-check, intent-file `## Outcome` summary | `scripts/end-intent` |
 | 2 | INDEX.md terminal move (Active -> Completed/Abandoned) | `scripts/end-intent` |
 | 3 | savepoint `Done` bookend | `scripts/end-intent` |
 | 4 | store auto-commit | `scripts/end-intent` |
@@ -39,45 +39,42 @@ deliveries; separately, one session delivered four intents back to back and
 never ran the old step-5 one-liner at all, intent 188). Never restate
 outcome/INDEX/savepoint/disarm prose inline again; call `scripts/end-intent`.
 
-### Step 0. Precondition (the gate is section-blind, not selective)
+### Step 0. Precondition (the record is what gets backfilled)
 
-`Bridge.check_gate` (scripts/lib/bridge.rb) is LIVE code already wired into
-the write-time hook. Its outcome.md rule is a blind scan of the WHOLE
-checklist.md: `content.scan(/^- \[ \]/)` counts every unchecked box, in
-every section, with no awareness of which section a box lives in. ANY
-unchecked box anywhere blocks the outcome.md write; there is no exemption
-for orchestrator-owned or completion-tracking items.
+Nothing refuses the close any more (the 1.x write-time gate and `end-intent`'s
+exit-6 structure gate were retired in 2.0, intents 302 and 308). What you leave
+on disk is what the record becomes, so before the call:
 
 1. Read checklist.md. Tick every item as it is actually performed, including
    an item that describes the close itself: running this very procedure IS
-   what that item describes, so tick it at the moment you begin the close,
-   before authoring outcome.md. By the time outcome.md is written,
-   checklist.md must read 100 percent checked; there is no other way past
-   the gate.
+   what that item describes. An unchecked box is not a refusal, it is a
+   reported gap that lands verbatim in the backfilled `## Follow-ups`.
 2. Confirm every acceptance criterion in spec.md is verifiable (tests pass,
    or the manual check described in its HOW line was actually run).
-3. The structure gate (intent 222) now enforces this: `scripts/end-intent`
-   refuses with exit 6 and names the exact unchecked box (or any other
-   structural gap: intent-file validity, lifecycle-artifact presence,
-   `## Links` projection). On a refusal, fix via the OWNING tool, never a
-   hand edit of the check's own output:
-   - checklist/outcome content - finish it yourself, the same as before.
-   - links projection - run
-     `ruby ~/.plastic/scripts/maintenance-run --tool project-links --intent <id> --apply`.
-   - a savepoint issue - advisory only (WARN, never blocks): run
-     `plastic-intent-savepoint` to rebuild via `Bridge.rebuild_savepoint` if
-     you want it clean, but it never refuses the close on its own.
-   Then re-run `scripts/end-intent`.
+3. Decide what you have to say. A spec.md, plan.md, action file, or outcome.md
+   left as the scaffold placeholder is written from the record by
+   `scripts/end-intent` (the intent file's `## Intent`, `### Decisions`, and
+   `## Insights`, the checklist, the diff on the intent's own worktree). A
+   file you wrote, even under a still-present sentinel, is never touched.
+   Write outcome.md yourself when the summary deserves more than the
+   `--outcome-summary` line; otherwise let the backfill carry it.
 
 ### Step 1-5. Run `scripts/end-intent`
 
-First author outcome.md for real (never leave the scaffold placeholder in
-place): copy `templates/outcome.md`, set the frontmatter to
-`disposition: delivered` or `disposition: abandoned`, and fill `## Summary`,
-`## Delivered`, `## Verification`, `## Follow-ups`. On abandon, `## Summary`
-states the abandonment reason and the trail (see Pivot below). Also author
+Author outcome.md yourself when it deserves prose: copy `templates/outcome.md`,
+set the frontmatter to `disposition: delivered` or `disposition: abandoned`, and
+fill `## Summary`, `## Delivered`, `## Verification`, `## Follow-ups`. `## Delivered` is a
+`| Row | What |` table: one row per thing delivered, in plain wording a reader
+recognizes, not a method name or an implementation summary (that detail
+belongs in `## Summary`). Each row's label must appear as a standalone token
+in an action-file heading (`### S1 - ...` proves row S1); that heading's
+matrix rows become the row's Proven-by cell on `report-screen delivered`'s
+post-delivery screen. `## Needs you` is the literal None or a
+`| N | What | Why |` table. On abandon, `## Summary` states the abandonment reason and the trail (see Pivot
+below). A placeholder outcome.md is backfilled from the record instead, with the
+close's disposition and the `--outcome-summary` line as its summary. Also author
 the rich INDEX entry note now (a short line in the store's existing
-Completed/Abandoned convention: mode/tier, what shipped or why it was
+Completed/Abandoned convention: mode, what shipped or why it was
 abandoned, suite result, merge/spawn notes); content authoring stays with
 you, `--index-note` only appends what you write.
 
@@ -91,9 +88,11 @@ ruby ~/.plastic/scripts/end-intent \
   --index-note "<rich Completed/Abandoned entry description>"
 ```
 
-This does all of steps 1-5 in order: guards outcome.md (a missing or
-still-placeholder file is caught by the structure gate first and exits 6; a
-wrong-disposition file exits 2; either way it authors nothing), stamps the
+This does all of steps 1-5 in order: backfills every missing or placeholder
+spec.md, plan.md, action file, and outcome.md from the record (never a file
+you wrote), runs doctor's per-intent structure check and the outcome guard as
+a self-check that reports on stderr and proceeds (an unchecked box, a
+malformed intent file, a wrong-disposition outcome.md you wrote), stamps the
 intent file's `## Outcome` section, moves the INDEX.md
 line from `## Active` to `## Completed` or `## Abandoned` (dated today,
 idempotent, accepting either a real em dash or a plain hyphen as the id/
@@ -127,8 +126,7 @@ correctly, for the first time on that path (D7).
 
 Exit codes: 0 success (the intent is closed AND its delivery lock is gone);
 1 a usage or resolution failure, OR an INDEX id that resolves to neither
-`## Active` nor the terminal section; 2 the outcome.md guard refusing (fix
-outcome.md and re-run, nothing was written); 3 steps 1-4 already committed
+`## Active` nor the terminal section; 3 steps 1-4 already committed
 but disarm could not verify the lock is gone afterward (run `/plastic-doctor
 check the lock status`); 4 a live foreign session holds the lock (back off);
 5 the code worktree is dirty (commit/stash first, or pass
@@ -171,8 +169,7 @@ historical record of what was planned.
 
 ## Routing
 
-`plastic-releasing`, `plastic-auto`, `plastic-intent-executing`, the curator
-agent, `store-curating`, and `store-indexing` all delegate their mechanical
+`plastic-releasing`, `plastic-auto`, and `plastic-intent-executing` all delegate their mechanical
 close to this skill (or call `scripts/end-intent` directly for steps 1-5).
 None of them restate the outcome/INDEX/savepoint/disarm prose inline any
 more; if you find one that does, that surface has drifted and should route

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

@@ -7,11 +7,11 @@
       "scope": "behavior",
       "set": "train",
       "prompt": "checklist.md has one unchecked non-completion item. Try to complete the intent.",
-      "expected_output": "Defers to the existing Bridge.check_gate hard gate rather than writing outcome.md; tells the user to finish the checklist item first instead of fighting the deny.",
+      "expected_output": "Ticks or finishes the item before calling scripts/end-intent, because an unchecked box is reported by the structure self-check and lands verbatim in the backfilled Follow-ups; never a refusal (the write-time gate was removed in 2.0, intents 302 and 308).",
       "files": [],
       "assertions": [
-        { "type": "human", "check": "SKILL.md Step 0 states the gate blocks outcome.md while unchecked non-completion items remain, and instructs finishing the checklist rather than attempting the write", "result": "expect-pass" },
-        { "type": "code", "check": "Bridge.check_gate(intent_dir, 'outcome.md') returns a non-nil block reason when checklist.md has an unchecked '- [ ]' item (scripts/lib/bridge.rb)", "result": "pass" }
+        { "type": "human", "check": "SKILL.md Step 0 states that nothing refuses the close, that an unchecked box is a reported gap landing in Follow-ups, and instructs finishing the checklist before the call", "result": "expect-pass" },
+        { "type": "code", "check": "scripts/end-intent exits 0 on an unchecked '- [ ]' item and prints 'structure check: intent_checklist_complete' (test/end_intent_test.rb)", "result": "pass" }
       ]
     },
     {
@@ -53,7 +53,7 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "Start work on intent 87.",
-      "expected_output": "Does NOT activate plastic-intent-ending; this is a boarding request (plastic-intent-starting), the opposite end of the lifecycle from a close.",
+      "expected_output": "Does NOT activate plastic-intent-ending; this is a resume request (plastic-intent-continuing), the opposite end of the lifecycle from a close.",
       "files": [],
       "assertions": [
         { "type": "code", "check": "router CHOICE != plastic-intent-ending", "result": "expect-pass" }

package/skills/intent-executing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: plastic-intent-executing
-description: Use when you have a written implementation plan to execute. Default mode is subagent-driven (at L a fresh subagent per task with two-stage review, at S and M one executor dispatch for the whole consolidated action). Fallback mode is inline execution for environments without subagent support. If superpowers:subagent-driven-development or superpowers:executing-plans are available, delegates to them.
+description: Use when you have a written implementation plan to execute. Default mode is subagent-driven (one executor dispatch for the whole consolidated action, tests first, reviewed by risk). Fallback mode is inline execution for environments without subagent support. If superpowers:subagent-driven-development or superpowers:executing-plans are available, delegates to them.
 user-invocable: true
 ---
 
@@ -8,7 +8,7 @@ user-invocable: true
 
 ## Overview
 
-Load plan from the active intent's `plan.md`, execute all tasks, review per the tier gate below, report when complete.
+Load plan from the active intent's `plan.md`, execute all tasks, review as below, report when complete.
 
 ## Step 0: Sync Worktree First
 
@@ -40,12 +40,9 @@ If `superpowers:subagent-driven-development` is available as a skill, delegate t
 - Superpowers skills respect "user preferences for plan/spec location"; Plastic IS that preference
 
 ### Subagent-Driven (Default)
-Dispatches subagents to do the work. The controller never implements. It dispatches, reviews, and tracks progress. How many dispatches it makes depends on the tier stamped at the top of `spec.md` (the `Tier:` line, the single authoritative record). `plan.md` carries a bold `**Tier:**` field copied from it, a convenience only:
+Dispatches subagents to do the work. The controller never implements. It dispatches, reviews, and tracks progress. One executor dispatch implements the whole consolidated action from `plan.md`, the action file's failure-mode matrix, and `checklist.md` in one pass, tests first: the matrix's tests are committed red before the code. Several independent action files are handed to the same executor in order; they are not a reason for a per-task review loop (removed in 2.0, intent 307).
 
-- **S or M:** one executor dispatch implements the whole consolidated action from `plan.md` plus `checklist.md` in one pass. There is no per-task implementer-then-two-reviewers loop.
-- **L:** a fresh subagent per task, and a two-stage review after each task: spec compliance first, then code quality.
-
-The final independent review in Step 3 runs at every tier. It is a separate agent with fresh context, and it is never the maker.
+The post-execution review in Step 3 runs by risk (the rule lives in the auto skill). When it runs, the reviewer is a separate agent with fresh context, never the maker. The plan itself is reviewed before code by the adversarial plan reviewer (`plan-reviewer-prompt.md`), dispatched by the lead at How.
 
 ### Inline (Fallback)
 Executes tasks sequentially in the current session. Use when subagents aren't available or user explicitly requests inline mode.
@@ -62,46 +59,21 @@ Run Step 0 (Sync Worktree First) before this step.
 
 ### Step 2: Execute Each Task
 
-Read the `Tier:` line stamped at the top of `spec.md` first (the authority), then follow the matching branch. `plan.md`'s bold `**Tier:**` field is a convenience copy of the same value, useful when `spec.md` is not already open.
-
-#### At S or M: one executor dispatch
+Dispatch ONE executor subagent and give it the whole delivery: every task's full text from `plan.md` (pasted in, never a file reference), every action file with its failure-mode matrix, the checklist items it must tick, the project context from CLAUDE.md, the active intent context from `{ID}--{slug}.md`, and the worktree path. In auto mode this is the `plastic-executor` agent; elsewhere use the `implementer-prompt.md` template. The executor writes the matrix's tests and commits them red, implements the consolidated action in order, ticks each item as it lands (see `## Tick-as-you-land`), and drives the test suite green.
 
-Dispatch ONE executor subagent and give it the whole delivery: every task's full text from `plan.md` (pasted in, never a file reference), the checklist items it must tick, the project context from CLAUDE.md, and the active intent context from `{ID}--{slug}.md`. In auto mode this is the `plastic-executor` agent; elsewhere use the `implementer-prompt.md` template. The executor implements the consolidated action in order, ticks each item as it lands (see `## Tick-as-you-land`), and drives the test suite green.
+After each commit lands (the red commit and every commit after it), append a `Commit` line to the savepoint ledger: `ruby ~/.plastic/scripts/savepoint-note <intent_dir> --kind Commit --text "<sha> <what it proves>"` (intent 317, D17). This is what feeds `report-screen delay`; a commit with no line is a gap the delay report cannot explain.
 
 Read its response by code:
-- DONE or DONE_WITH_CONCERNS → proceed to Step 3. Run no per-task spec review and no per-task quality review at these tiers; Step 3's final review covers the work.
+- DONE or DONE_WITH_CONCERNS → proceed to Step 3.
 - NEEDS_CONTEXT → provide the missing context, re-dispatch the executor.
 - BLOCKED → stop, report to the user, wait for resolution.
 
-#### At L: one subagent per task
-
-For each task sequentially (never parallel: conflict risk):
-
-**a. Dispatch implementer subagent**
-Use the Agent tool with the implementer prompt template. Include:
-- Full task text (pasted in, not file reference)
-- Project context from CLAUDE.md
-- Active intent context from `{ID}--{slug}.md`
+### Step 3: Review by Risk
+Apply the auto skill's risk rule to the executor's return and the diff: a matrix row no test could prove, a diff touching a hook, the lock, the worktree code, the installer, or a release file, a DONE_WITH_CONCERNS or a deviation from the matrix, or an owner-facing surface no test pins. When a rule fires, dispatch the post-execution reviewer with `code-quality-reviewer-prompt.md` (a separate agent with fresh context, never the maker); if it returns changes, re-dispatch the executor to fix them, then run the suite once more. When no rule fires, the green suite is the review.
 
-**b. Handle implementer response**
-- DONE → proceed to spec review
-- DONE_WITH_CONCERNS → note concerns, proceed to spec review
-- NEEDS_CONTEXT → provide missing context, re-dispatch
-- BLOCKED → stop, report to user, wait for resolution
+Whenever a review verdict returns - the plan review before code, or the post-execution review above - the lead appends a `Review` line: `ruby ~/.plastic/scripts/savepoint-note <intent_dir> --kind Review --text "<verdict, what changed>"` (intent 317, D17). This is the other half of what `report-screen delay` reads.
 
-**c. Dispatch spec compliance reviewer**
-Use the Agent tool with spec-reviewer prompt. The reviewer reads actual code and compares against the task requirements. Pass/fail.
-- If fail: implementer fixes, spec reviewer re-reviews (loop until pass)
-
-**d. Dispatch code quality reviewer**
-Only after spec compliance passes. Reviews clean code, testing, architecture. Pass/fail.
-- If fail: implementer fixes, quality reviewer re-reviews (loop until pass)
-
-**e. Tick as it lands, then move to next**
-Follow `## Tick-as-you-land` below: move the task's checklist item to `## Completed` and add a `## Session Log` row in the same edit.
-
-### Step 3: Final Review
-After all tasks complete, dispatch a final reviewer for the entire implementation. This runs at every tier, S, M, and L. The reviewer is a separate agent with fresh context and is never the maker. At S and M this is the only review the work gets, so if it returns changes, re-dispatch the executor to fix them, then re-review.
+**The D19 heading convention.** An action file's `## Delivered` row (in `outcome.md`) is proven by whichever `actions/ACTION_N.md` heading carries that row's label as a standalone token - `### Row A -` proves row A, `### S1 -` proves row S1. Write action-file section headings so the label they prove is unambiguous (never a substring another label could also match, like `A` inside `AB`); `report-screen delivered`'s Proven-by column renders `not recorded` when no heading matches.
 
 ### Step 4: Update Intent and Complete
 Capture observations in `## Insights`. When ALL checklist items are checked:
@@ -142,22 +114,19 @@ row (Date, Items Completed, Notes). Do not batch several tasks' worth of
 checklist updates into one later edit; tick the moment the task is verified,
 before moving to the next task.
 
-## Verify before every owner gate
+## Verify before every owner review
 
 Hard rule: before presenting any completed work to the owner, independently
 verify it. Grep or run the artifact the work just produced (the test suite,
 the changed file, the installed output) rather than restating the intended
 change. Never present an unverified claim to the owner. If verification
-fails, fix it before the gate, not after.
-
-Read `../plastic-conventions/references/gates-and-enforcement.md` for the transition-gate
-mechanics, the audited escape, and gate logging behind every owner gate named here.
+fails, fix it before the review, not after.
 
 ## Methods report (audits and sweeps)
 
 When the work is an audit or a sweep (checking many files or many instances of
 something rather than building one artifact), deposit a methods report to
-`{intent_dir}/resources/` before the gate: what was checked, how it was
+`{intent_dir}/resources/` before the review: what was checked, how it was
 checked, and what was found. This lets the owner review the method, not just
 the conclusion.
 
@@ -175,7 +144,7 @@ When presenting a batch of Exec decisions for the owner to rule, read
 `~/.plastic/_decision-tables.md` and follow the numbered-table procedure,
 persisting each ruling with `--stage Exec`.
 
-## Gate position
+## Position in the cycle
 
 - **Before:** `plan.md` and `checklist.md` exist; the worktree is armed.
 - **Produces:** code changes, a ticked checklist, and (for audits or sweeps) a methods report in `resources/`.

package/skills/intent-executing/plan-reviewer-prompt.md

@@ -0,0 +1,39 @@
+# Adversarial Plan Reviewer Prompt
+
+You review a plan before any code exists. The lead of this intent wrote `spec.md`, `plan.md`,
+and at least one `actions/ACTION_N.md` that carries a failure-mode matrix: one row per
+operation, naming a failure mode and the test that would catch it. Your job is to find what
+that matrix misses and what it claims but cannot deliver, so the executor builds against a
+plan that has already been attacked.
+
+## Intent
+
+{{INTENT_DIR}} (read `spec.md`, `plan.md`, every `actions/ACTION_N.md`, and anything under
+`resources/` the spec cites). Target tree: {{WORKTREE}}.
+
+## Instructions
+
+1. Read the spec's decisions and the matrix first, then the tree. Check every claim by
+   opening the named file at the named line; never accept a line number from the spec on
+   trust.
+2. For every operation in the spec, name a failure mode the matrix does not cover, or a
+   covered failure mode whose named test cannot actually detect it (the test reads a
+   different file, the regex cannot match, the assertion is a tautology, the fixture never
+   produces the case).
+3. Grep the tree for every name the plan deletes, renames, or re-points, and list each
+   caller, test, doc, or template the plan does not name.
+4. Where the plan touches a test the suite pins by exact string, quote the pinned string and
+   say what the change must keep verbatim.
+5. Run any probe that settles a claim cheaply (a single test file, a measurement); report the
+   numbers.
+6. Write no code and edit no repository file. Your output is the review.
+
+## Report Format
+
+One line first, the verdict: **REVISE** or **PROCEED**, with the biggest risk in the same
+sentence.
+
+Then numbered findings under `## A. Matrix gaps`, `## B. Missed files and pins`, and
+`## C. Probes`. Each finding names the file and line you read and states what the spec or
+the matrix must add, change, or drop. Be concrete and adversarial; do not pad; do not restate
+the plan.

package/skills/intent-speccing/SKILL.md

@@ -1,73 +1,130 @@
 ---
 name: plastic-intent-speccing
-description: >
-  Consolidate the enriched Why (`## Context`, `### Decisions`, `## Insights`) into `spec.md`
-  through a deterministic, judgment-free numbered sequence. Use when the user types the command
-  to turn the brainstorm into a spec, asks to "write the spec", "spec this intent", "consolidate
-  into spec.md", or the active intent is at Why with enough Decisions on record to close it out.
-  Also fires on an indirect request that never names spec.md, such as "turn what we just
-  discussed into the contract the planner builds from." Distinct from `plastic-intent-brainstorming`
-  (the exploration that produces the enriched Why, upstream of this skill) and
-  `plastic-intent-planning` (turns an existing spec.md into plan.md for How, downstream of this
-  skill).
+description: >-
+  Thinking mode for an intent: the conversation that turns an idea into rulings, the
+  research that backs them, and the action files that say how the work runs. Use when the
+  user wants to think a request through before building it, says "let's design this",
+  "brainstorm", "grill me", "research this first", "spec this intent", "write the spec",
+  or when a prompt is too vague to run directly and the direct skill routes here. Also
+  fires on an indirect ask that never names a spec, such as "turn what we just discussed
+  into the contract the work runs from." Absorbs what the former intent-brainstorming,
+  intent-grilling, and intent-researching skills used to do (intent 304).
 user-invocable: true
 ---
 
-# Intent Speccing
+# Intent Speccing: thinking mode
 
-Consolidate the enriched Why into `spec.md` through eight fixed steps, one action per step. The
-next action is never a judgment call: when a section cannot be filled from what is on record,
-step 5 is to stop and ask, never invent.
+One skill for the whole thinking conversation on an intent. It asks one question at a time,
+records every owner ruling the moment it lands, grills when asked, deposits research in
+`resources/`, and ends by writing the action files the work runs from and consolidating the
+rulings into `spec.md`. There is no separate brainstorm, grill, or research skill; those are
+the modes below.
 
-## Precondition
+## Active intent
 
-Run only when the active intent is at Why (its `## Intent` and enriched `## Context` plus
-`### Decisions` exist, `spec.md` does not yet exist or is being redone) and the user has asked to
-consolidate that Why into the spec. If no intent is active, or the active intent is not at Why,
-report that and stop; do not guess which intent is meant.
+Resolve the active intent before anything else: read `~/.plastic/projects.yml`, match the
+working directory against registered project paths (a match means the project store at
+`~/.plastic/projects/{slug}/store/`, no match means `~/.plastic/store/`), then read that
+store's `INDEX.md` under `## Active`. Exactly one active intent is the one to work; several
+means ask which; none means stop and say so ("No active intent. Create one first with
+/plastic-intent-creating"). Every artifact goes into `{store}/{id}--{slug}/`; never write
+outside it.
 
-## The 8-step sequence
+## The conversation
 
-| Step | Action |
-|---|---|
-| 1 | Confirm the precondition above. |
-| 2 | Read inputs in fixed order and build a ruling ledger: (a) `## Context` and `### Decisions`; (b) `## Insights` newest-last, so a later ruling supersedes an earlier conflicting one; (c) `resources/discovery--<slug>.md`; (d) any other `resources/*.md`. |
-| 3 | Decide the tier: adopt the brainstorming `Tier:` recommendation from Decisions or Insights; otherwise apply the PLASTIC.md tiers rubric (S = single mechanism or file cluster, M = one subsystem, L = cross-cutting or novel design). |
-| 4 | Fill the template section by section, all 8 sections in template order. Read `references/per-section-fill-rules.md` now, filling the template is the trigger. Write the tier as the literal top line above `# Spec:`. Encode every ruling into its matching section, later supersedes earlier on conflict. A collapsed single-line S/M section is complete and valid; do not pad it. |
-| 5 | Gap rule: if any section cannot be filled from the ledger built in step 2, STOP and ask the user for the missing ruling. Never invent scope to fill a gap. |
-| 6 | State the gate position (below) so the user knows what happens next. |
-| 7 | Self-verify against the checklist. Read `references/self-verify-checklist.md` now, verifying before presenting is the trigger. Fix any failing check, then re-verify from the top. |
-| 8 | Present `spec.md` for the user-review gate, then hand off to `plastic-intent-planning` for How. |
+QMD-first: before scanning the store by hand for prior decisions, specs, or research, run
+`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` and open the authoritative intent file for
+any hit you act on. The command is a no-op when QMD is absent.
+
+1. **Context first.** Check the project state (files, docs, recent commits) and the intent's
+   `## Context` and `## Insights`. Assess scope: a request that describes several independent
+   subsystems is decomposed first, one thinking conversation per piece, before any detail
+   question is spent.
+2. **One question per message, in prose.** No multiple-choice chips; a short menu of named
+   options is fine when the choice is genuinely enumerable, phrased as a sentence. Focus on
+   purpose, constraints, and success criteria. Before asking how something works, look:
+   in a codebase the answer is usually on disk.
+3. **Propose two or three approaches** with trade-offs, leading with the recommendation and
+   the reason for it. YAGNI: strip what the design does not need.
+4. **Present the design in sections** scaled to their complexity (a few sentences when
+   straightforward, up to 300 words when nuanced): architecture, components, data flow,
+   error handling, testing. Get a ruling after each section. Read
+   `references/design-principles.md` before proposing a design for the unit-boundary and
+   existing-codebase guidance (follow established patterns, no unrelated refactoring).
+5. **Record every ruling as it lands.** The moment the owner rules, before the next question:
+   ```
+   ruby ~/.plastic/scripts/insight-append {intent_dir} "<ruling text>" --stage Why --author human
+   ```
+   Never batch. A later ruling that conflicts with an earlier one gets a new insight naming
+   the superseded one; both stay on record and the later wins. When presenting a batch of
+   options for the owner to pick from, read `~/.plastic/_decision-tables.md` and follow the
+   numbered-table procedure.
+
+No implementation starts until a design has been presented and ruled on. That holds for a
+config change and a one-function utility as much as for a subsystem; the design can be three
+sentences, but it is presented.
+
+### Grill mode
 
-## Gate position (step 6)
+When the owner says "grill me" or asks to stress-test a plan or design, the same conversation
+turns relentless. Identify the root in one sentence and restate it. Walk the decision tree
+branch by branch: state the branch, ask a specific question, lead with your own recommended
+answer, resolve before moving on, name dependencies between decisions and resolve the
+upstream one first. Do not accept "it depends" without "on what?"; do not skip edge cases; do
+not assume when you can verify; challenge assumptions ("why not the alternative?"). Every
+three or four questions, summarize what is decided. At natural checkpoints, about every ten
+questions, offer to continue or to pause and capture what is decided; a pause records every
+ruling so far and stops. When all branches are resolved, list the decisions and the deferred
+items, then offer the hand-off below.
 
-The Why stage's deliverable is `spec.md`; the gate is satisfied the moment a complete, real
-`spec.md` exists (this is the gates-by-name framing: gate-check enforces spec.md before plan.md,
-not the Transition Gates table row). Writing `plan.md` is what opens the code gate for Exec, and
-writing `plan.md` is not this skill's job, that is `plastic-intent-planning`. State this to the user
-at step 6 so the handoff at step 8 is expected, not a surprise.
+### Research mode
 
-Read `../plastic-conventions/references/lifecycle-and-savepoints.md` for the subagent
-report-home contract behind this handoff. This path resolves relative to this skill's own
-installed directory.
+When a question needs evidence rather than a ruling, research it and deposit the report in
+`{intent_dir}/resources/{type}--{topic}.md`, with `{type}` one of `deep-research`,
+`competitive-analysis`, `technical-spike`, `reference`, `landscape-survey` and `{topic}` in
+kebab-case. Choose the depth and say why: shallow (one or two searches plus a look at the
+code, minutes) for a narrow factual question; deep (several sources, cross-checked, a
+landscape or an architectural decision, or when a wrong answer would cause an architectural
+mistake) through the harness's deep-research capability when it has one, else a manual
+fan-out of searches. The report carries a summary, findings with citations, sources, and a
+"Relevance to intent" section; tables for findings and comparisons. Log one line in the
+intent's `## Insights` naming the file and the key finding. Research does not chain to
+another step; the conversation decides what to do with it.
 
-## Tier stamp (step 3, convention only)
+## Closing the conversation
 
-Write `Tier: S|M|L` as the literal first line of the file, above the `# Spec:` heading. This line
-is convention-only: the orchestrator and the planner read it, no gate and no doctor check
-validates it.
+When the rulings are enough to build from:
 
-## Completion report
+1. **Write the action files.** Every ruling that says how the work runs lands in
+   `actions/ACTION_N.md` (at least one real file, no placeholder): the files to touch, the
+   order, the tests that prove each step, the rules. The action files are what direct mode or
+   an auto team executes; they exist before the work runs.
+2. **Consolidate `spec.md`** from the rulings, section by section in template order. Read
+   `references/per-section-fill-rules.md` when filling the template. Build the ruling ledger
+   in fixed order first: `## Context` and `### Decisions`, then `## Insights` newest-last so a
+   later ruling supersedes an earlier one, then `resources/discovery--<slug>.md`, then any
+   other `resources/*.md`. Encode every ruling into its section; a collapsed single-line
+   section is complete when it names everything. If a section cannot be filled from the
+   ledger, stop and ask for the missing ruling; never invent scope. A spec.md left as the
+   placeholder is backfilled from the record at close (`## Problem`, `## Decisions`,
+   `## Acceptance Criteria`; the rest stays stub text), so consolidate only when the
+   rulings say more than the record already does.
+3. **Self-verify.** Read `references/self-verify-checklist.md` before presenting; fix any
+   failing check and re-verify from the top.
+4. **Present and hand off.** Present `spec.md` and the action files. Then offer the routes:
+   run it now inline when the work is small enough for direct mode; hand to `plastic-auto`
+   when the owner says auto and the checklist above passes (all decisions resolved, scope
+   bounded, dependencies named, success criteria defined); or keep thinking.
 
-State, in this order: which file was written (`spec.md`, new or rewritten), the stamped `Tier:`
-value, the count of Acceptance Criteria produced (the surface the planner will cover), which
-`## Insights` rulings superseded an earlier Decision (if any) and where each landed, and the
-handoff target (`plastic-intent-planning`). If step 5 stopped for a missing ruling, report that
-instead: which section, what is missing, and the question put to the user.
+Report, in this order: which files were written (`spec.md` new or rewritten, the action
+files), the count of acceptance criteria, which `## Insights` rulings superseded an earlier
+decision and where each landed, and the route chosen. If step 2 stopped for a missing
+ruling, report that instead: which section, what is missing, the question put to the owner.
 
 ## References
 
 | Trigger | Read |
 |---|---|
-| Filling the template (step 4) | `references/per-section-fill-rules.md` |
-| Self-verifying before presenting (step 7) | `references/self-verify-checklist.md` |
+| Before proposing a design (unit boundaries, existing codebases) | `references/design-principles.md` |
+| Filling the spec template (closing step 2) | `references/per-section-fill-rules.md` |
+| Self-verifying before presenting (closing step 3) | `references/self-verify-checklist.md` |

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

@@ -1,6 +1,6 @@
 {
   "skill_name": "plastic-intent-speccing",
-  "notes": "Intent 163. Scopes: description triggering (1-4) and behavior (5-8: all-8-sections output, mandatory superseding-ruling case, STOP-and-ask gap rule, tabular alternatives with no em-dash). No dedicated Ruby test file backs this skill yet (natural-language guided command), so all assertions are result: expect-pass pending a real observed run, per the intent-starting evals.json convention.",
+  "notes": "Intent 163. Scopes: description triggering (1-4) and behavior (5-8: all-8-sections output, mandatory superseding-ruling case, STOP-and-ask gap rule, tabular alternatives with no em-dash). No dedicated Ruby test file backs this skill yet (natural-language guided command), so all assertions are result: expect-pass pending a real observed run, per the evals.json convention.",
   "evals": [
     {
       "id": 1,
@@ -37,7 +37,7 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "Brainstorm this intent.",
-      "expected_output": "Does NOT activate plastic-intent-speccing; activates plastic-intent-brainstorming (exploration that produces the enriched Why, upstream of speccing).",
+      "expected_output": "Activates plastic-intent-speccing (brainstorming is a mode of the thinking conversation since intent 304).",
       "files": [],
       "assertions": [
         {
@@ -52,7 +52,7 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "Write the plan.",
-      "expected_output": "Does NOT activate plastic-intent-speccing; activates plastic-intent-planning (turns an existing spec.md into plan.md for How, downstream of speccing).",
+      "expected_output": "Does NOT activate plastic-intent-speccing; a plan is written from the action files by the executing skill.",
       "files": [],
       "assertions": [
         {
@@ -67,12 +67,12 @@
       "scope": "behavior",
       "set": "train",
       "prompt": "Intent Y is at Why: Context describes the problem and goal, and 5 Decisions are recorded resolving scope, approach, and one rejected alternative. Consolidate into spec.md.",
-      "expected_output": "Produces spec.md with Tier: S|M|L as the literal top line above the Spec heading; all 8 template sections present once, in template order (Problem, Goals, Non-Goals, Approach, Alternatives Considered, Decisions, Acceptance Criteria, Open Questions); no template placeholder text remains; every recorded Decision is encoded into its matching section.",
+      "expected_output": "Produces spec.md starting at the Spec heading; all 8 template sections present once, in template order (Problem, Goals, Non-Goals, Approach, Alternatives Considered, Decisions, Acceptance Criteria, Open Questions); no template placeholder text remains; every recorded Decision is encoded into its matching section.",
       "files": [],
       "assertions": [
         {
           "type": "human",
-          "check": "Tier line is literally the first line of the file; all 8 sections appear once each, in template order; no placeholder text; every Decision traces to a section",
+          "check": "The file starts at the Spec heading; all 8 sections appear once each, in template order; no placeholder text; every Decision traces to a section",
           "result": "expect-pass"
         }
       ]

package/skills/intent-speccing/references/per-section-fill-rules.md

@@ -1,8 +1,8 @@
 # Per-Section Fill Rules
 
-The single shared method for turning the enriched Why into `spec.md`. Both
-`plastic-intent-speccing` (guided) and the `plastic-spec-specialist` agent (auto) point here;
-neither restates these rules. One fill rule per template section, in template order.
+The single shared method for turning the rulings into `spec.md`. `plastic-intent-speccing`
+(the thinking conversation) and the auto orchestrator both point here; neither restates these
+rules. One fill rule per template section, in template order.
 
 Read the ruling ledger first (built in step 2 of the SKILL.md sequence): `## Context` plus
 `### Decisions`, then `## Insights` newest-last (a later ruling supersedes an earlier
@@ -24,7 +24,7 @@ delivering a specific outcome.
 
 One bullet per goal, each a concrete, observable outcome the delivery must reach. Encode every
 Decision that commits to an outcome as its own bullet, do not compress two Decisions into one
-vague goal. A single-line collapsed Goals section (S/M tier) is complete if it names every
+vague goal. A single-line collapsed Goals section is complete if it names every
 outcome; do not pad it with restated Problem text.
 
 ## 3. Non-Goals

package/skills/intent-speccing/references/self-verify-checklist.md

@@ -22,8 +22,7 @@ these.
 5. **No template placeholder text remains.** No literal `<intent name>`, `<alternative>`, `...`,
    sample bracket text, or other template filler from `templates/spec.md` survives anywhere in
    the artifact.
-6. **Tier stamp is the top line.** `Tier: S|M|L` is the literal first line of the file, above the
-   `# Spec:` heading, not folded into a section body.
+6. **No header line.** The file starts at the `# Spec:` heading; there is no `Tier:` line (removed in 2.0, intent 304).
 7. **All 8 sections present, in template order.** Problem, Goals, Non-Goals, Approach,
    Alternatives Considered, Decisions, Acceptance Criteria, Open Questions, each present once, in
    that order, none merged into another.

package/skills/project-creating/SKILL.md

@@ -77,7 +77,7 @@ writes `INDEX.md` and `project.yml` only if missing. It is idempotent, so it is
 safe even when the tactical mirror in step 5 already created the store directory.
 Do not create the store with an inline `mkdir`; the provisioner is the only place
 a store is made. For a project that is already registered but store-less, use the
-`plastic-store-provisioning` skill instead.
+`plastic-doctor` skill's provisioning section instead.
 
 ### 8. Mark Global Intent(s) Completed