@zalom/plastic 2.0.0-alpha.9 → 2.0.1

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

@@ -1,74 +0,0 @@
-{
-  "skill_name": "plastic-intent-ending",
-  "notes": "Intent 161. Scopes: description triggering (3-6) and behavior (1-2: the two mandatory D6 cases). Case B graduates into test/end_intent_test.rb (test_done_bookend_lands_once_and_is_idempotent) per evaluating-skills conventions.",
-  "evals": [
-    {
-      "id": 1,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "checklist.md has one unchecked non-completion item. Try to complete the intent.",
-      "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 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" }
-      ]
-    },
-    {
-      "id": 2,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "Run the mechanical close (scripts/end-intent) for a delivered intent with a real outcome.md.",
-      "expected_output": "The savepoint Done bookend lands exactly once in savepoint.md, and a second run of the same command does not duplicate it (this is the regression the intent fixes: releasing used to skip this line entirely).",
-      "files": [],
-      "assertions": [
-        { "type": "human", "check": "SKILL.md Step 1-4 calls scripts/end-intent as one script instead of restating the outcome/INDEX/savepoint one-liners in prose", "result": "expect-pass" },
-        { "type": "code", "check": "test/end_intent_test.rb#test_done_bookend_lands_once_and_is_idempotent is green", "result": "pass" }
-      ]
-    },
-    {
-      "id": 3,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "Mark intent 87 done, it shipped.",
-      "expected_output": "Activates plastic-intent-ending to run the mechanical close (outcome.md, INDEX move, savepoint bookend, commit, disarm, reindex, report).",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE == plastic-intent-ending", "result": "expect-pass" }
-      ]
-    },
-    {
-      "id": 4,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "This one's not worth finishing, abandon it and wrap this up.",
-      "expected_output": "Activates plastic-intent-ending (indirect trigger: 'wrap this up' names no lifecycle vocabulary directly). Abandoned runs the identical procedure, only outcome.md content and the INDEX section differ.",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE == plastic-intent-ending", "result": "expect-pass" }
-      ]
-    },
-    {
-      "id": 5,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "Start work on intent 87.",
-      "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" }
-      ]
-    },
-    {
-      "id": 6,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "Cut a release and tag it v1.2.0.",
-      "expected_output": "Does NOT activate plastic-intent-ending directly; activates plastic-releasing, which internally calls scripts/end-intent for the mechanical close as one of its own steps.",
-      "files": [],
-      "assertions": [
-        { "type": "code", "check": "router CHOICE == plastic-releasing", "result": "expect-pass" }
-      ]
-    }
-  ]
-}

package/skills/intent-executing/SKILL.md

@@ -1,170 +0,0 @@
----
-name: plastic-intent-executing
-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
----
-
-# Executing a Plan
-
-## Overview
-
-Load plan from the active intent's `plan.md`, execute all tasks, review as below, report when complete.
-
-## Step 0: Sync Worktree First
-
-Before Step 1 (Load Plan) in either workflow below, sync the code worktree with
-main first, so no edit lands on a path a merged rename or delete already removed:
-
-```
-git -C <worktree> fetch origin && git -C <worktree> merge --ff-only origin/main
-```
-
-After syncing, verify the plan's target files exist at the paths plan.md names.
-If a named file or directory is missing (renamed or removed upstream), stop and
-report it rather than editing a stale path.
-
-Read `../plastic-conventions/references/locks-and-worktrees.md` for delivery isolation: the
-single-owner lock, claims, worktrees, solo mode, and the station ledger, before touching the
-worktree above. This path resolves relative to this skill's own installed directory.
-
-## Mode Selection
-
-### Check for superpowers first
-If `superpowers:subagent-driven-development` is available as a skill, delegate to it. If only `superpowers:executing-plans` is available, delegate to that. If neither is available, use Plastic's own execution engine below.
-
-**CRITICAL: when delegating to superpowers:**
-- Tell the skill that the plan is at `~/.plastic/store/ID--slug/plan.md` (not `docs/superpowers/plans/`)
-- Tell the skill that specs live at `~/.plastic/store/ID--slug/spec.md` (not `docs/superpowers/specs/`)
-- All meta-artifacts must stay inside `~/.plastic/store/ID--slug/`
-- Code files go in the project tree as normal
-- 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. 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).
-
-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.
-
-To select: user says "inline", "execute inline", or "no subagents".
-
-## Subagent-Driven Workflow
-
-### Step 1: Load Plan
-Run Step 0 (Sync Worktree First) before this step.
-1. Read the active intent's `plan.md`
-2. Extract ALL tasks with their full text, store in memory. Never make subagents read the plan file.
-3. Create a task list to track progress
-
-### Step 2: Execute Each Task
-
-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.
-
-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.
-- NEEDS_CONTEXT → provide the missing context, re-dispatch the executor.
-- BLOCKED → stop, report to the user, wait for resolution.
-
-### 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.
-
-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.
-
-**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:
-
-1. Update the intent's cluster entries in `INDEX.md` to show `_(completed)_`. Do this first, so the store auto-commit in the next step picks it up. `plastic-intent-ending` does not cover cluster maintenance (`store-indexing` and `store-curating` own it), so doing it here keeps the step from being lost.
-2. Hand the mechanical close to `plastic-intent-ending`. It owns `outcome.md`, the intent file's `## Outcome` stamp, the INDEX terminal move, the savepoint `Done` line, the store auto-commit, disarm, the QMD reindex, and the EM-to-CTO owner report, as ONE delegation. Author the outcome.md content when that skill asks for it; do not restate the mechanical steps here.
-
-**This is NOT optional.** An intent with all checklist items done but no Outcome is a broken state. Complete the intent immediately, do not leave it for later.
-
-## Inline Workflow
-
-### Step 1: Load and Review Plan
-Run Step 0 (Sync Worktree First) before this step.
-1. Read plan file from active intent
-2. Review critically, raise concerns before starting
-3. Create task list to track progress
-
-### Step 2: Execute Tasks
-For each task:
-1. Mark as in_progress
-2. Follow each step exactly
-3. Run verifications as specified
-4. Tick as it lands: follow `## Tick-as-you-land` below
-
-### Step 3: Update Intent and Complete
-Capture observations in `## Insights`. When ALL checklist items are checked:
-
-1. Update the intent's cluster entries in `INDEX.md` to show `_(completed)_`. Do this first, so the store auto-commit in the next step picks it up. `plastic-intent-ending` does not cover cluster maintenance (`store-indexing` and `store-curating` own it), so doing it here keeps the step from being lost.
-2. Hand the mechanical close to `plastic-intent-ending`. It owns `outcome.md`, the intent file's `## Outcome` stamp, the INDEX terminal move, the savepoint `Done` line, the store auto-commit, disarm, the QMD reindex, and the EM-to-CTO owner report, as ONE delegation. Author the outcome.md content when that skill asks for it; do not restate the mechanical steps here.
-
-**This is NOT optional.** Complete the intent immediately when work is done.
-
-## Tick-as-you-land
-
-As each task lands, in the same edit: move its checklist item from `## In
-Progress` to `## Completed` in `checklist.md`, and add one `## Session Log`
-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 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 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 review: what was checked, how it was
-checked, and what was found. This lets the owner review the method, not just
-the conclusion.
-
-## Reroute vs dispatch
-
-A human-facing instruction like "run /plastic-intent-speccing" means the user
-types that slash command themselves; it is never handed to a
-subagent. Agent-facing dispatch text is a prompt passed to the Agent tool for
-a subagent to execute. Keep the two separate: do not address a slash command
-to a subagent, and do not paste a dispatch prompt at the user.
-
-## Owner decisions during Exec
-
-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`.
-
-## 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/`.
-- **Next:** `plastic-intent-ending` owns `outcome.md` and the rest of the mechanical close (see intent 161). The Update-Intent-and-Complete step above hands off to it.
-
-Read `../plastic-conventions/references/lifecycle-and-savepoints.md` for the subagent
-report-home contract this handoff relies on.
-
-## Model Selection for Subagents
-
-Match model to task complexity:
-- **Mechanical tasks** (config files, boilerplate): cheapest available
-- **Standard implementation**: default model
-- **Architecture, integration, review**: most capable model
-
-## Prompt Templates
-
-Subagent prompts are in this skill's directory:
-- `implementer-prompt.md`: template for implementer subagents
-- `spec-reviewer-prompt.md`: template for spec compliance reviewers
-- `code-quality-reviewer-prompt.md`: template for code quality reviewers
-
-Read the appropriate template when dispatching each subagent type.

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

@@ -1,66 +0,0 @@
-{
-  "skill_name": "plastic-intent-executing",
-  "notes": "Intent 164. New evals.json for the executing-plan skill: refuse-to-present-unverified, sync-worktree-first, and the reroute-vs-dispatch distinction. All assertions are pending a real observed run per the plastic-evaluating-skills convention.",
-  "evals": [
-    {
-      "id": 1,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "A task just landed: a new method was added and its test file was written. The agent is about to tell the owner the task is done and move to the next one.",
-      "expected_output": "Before presenting the completed task to the owner, the agent independently verifies it: greps the changed file or runs the specific test, rather than restating what it intended to do. It does not present the claim until the grep or test run has actually been observed.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "a grep or test run against the actual artifact is shown before the owner-facing claim; no claim is presented as done without that observed check",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 2,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "The agent finished implementing a task and, without running anything, tells the owner \"Task 3 is complete and the tests pass.\"",
-      "expected_output": "This is a refusal case: the skill does not allow presenting a pass claim without first grepping or running the artifact. The correct behavior is to run the verification first and only then report the observed result.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "the skill's stated hard rule blocks an unverified claim like this; expected behavior is verify-then-report, not report-then-hope",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 3,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "Execution is starting for an intent whose plan.md was written two days ago; the code worktree has not been touched since.",
-      "expected_output": "Before Step 1 (Load Plan), the agent syncs the code worktree with main: `git -C <worktree> fetch origin && git -C <worktree> merge --ff-only origin/main`, then verifies the plan's target files exist at the paths plan.md names before editing any of them.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "the fetch-and-merge --ff-only sync command runs before Load Plan; target file existence is checked before the first edit",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 4,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "The plan's next step reads \"run /plastic-intent-speccing\" as a human-facing instruction to consolidate the spec once Exec finishes an audit task.",
-      "expected_output": "The agent tells the user to type the /plastic-intent-speccing command themselves; it does not dispatch a subagent with that slash-command text as a prompt, and it does not paste an agent-facing dispatch prompt at the user instead.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "the slash-command instruction is directed at the user, not handed to the Agent tool as a subagent prompt; no dispatch-prompt text leaks into the user-facing message",
-          "result": "expect-pass"
-        }
-      ]
-    }
-  ]
-}

package/skills/intent-executing/implementer-prompt.md

@@ -1,42 +0,0 @@
-# Implementer Subagent Prompt
-
-You are implementing a specific task from a plan. You have been given the full task text below.
-
-## Your Task
-
-{{TASK_TEXT}}
-
-## Project Context
-
-{{PROJECT_CONTEXT}}
-
-## Active Intent
-
-{{INTENT_CONTEXT}}
-
-## Instructions
-
-1. Read the task carefully. If anything is unclear, report NEEDS_CONTEXT with what you need.
-2. Implement exactly what the task specifies — nothing more, nothing less.
-3. Write tests first when the task includes test steps (TDD).
-4. Follow the file paths specified in the task exactly.
-5. Commit after each logical unit of work.
-6. When done, self-review against this checklist:
-   - [ ] All steps in the task are completed
-   - [ ] Tests pass
-   - [ ] Code is clean and follows project conventions
-   - [ ] No unrelated changes
-
-## Report Format
-
-End your work with one of these status lines:
-
-**DONE** — All steps completed, tests pass, code committed.
-
-**DONE_WITH_CONCERNS** — Completed but I noticed: [describe concerns].
-
-**NEEDS_CONTEXT** — I need clarification on: [specific questions].
-
-**BLOCKED** — Cannot proceed because: [describe blocker].
-
-It is always OK to report BLOCKED or NEEDS_CONTEXT. Do not guess or improvise when uncertain.

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

@@ -1,27 +0,0 @@
-# Spec Compliance Reviewer Prompt
-
-The implementer says they finished this task. Verify independently — their report may be incomplete or optimistic.
-
-## Task Requirements
-
-{{TASK_TEXT}}
-
-## Instructions
-
-1. Read the actual code that was written (not the implementer's report)
-2. Compare line by line against the task requirements
-3. Check for:
-   - Missing requirements — anything in the task that wasn't implemented
-   - Extra work — anything added that the task didn't ask for
-   - Misunderstandings — code that doesn't match what the task intended
-   - Test coverage — are all specified behaviors tested?
-
-## Report Format
-
-**PASS** — All task requirements are correctly implemented. No gaps, no extras.
-
-**FAIL** — Issues found:
-- [file:line] Description of what's wrong and what was expected
-- [file:line] Description of what's missing
-
-Be specific. Reference exact file paths and line numbers.

package/skills/intent-speccing/SKILL.md

@@ -1,130 +0,0 @@
----
-name: plastic-intent-speccing
-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: thinking mode
-
-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.
-
-## Active intent
-
-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 conversation
-
-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
-
-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.
-
-### Research mode
-
-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.
-
-## Closing the conversation
-
-When the rulings are enough to build from:
-
-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.
-
-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 |
-|---|---|
-| 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,126 +0,0 @@
-{
-  "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 evals.json convention.",
-  "evals": [
-    {
-      "id": 1,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "The active intent is at Why with Context and Decisions recorded. Consolidate the enriched Why into spec.md.",
-      "expected_output": "Activates plastic-intent-speccing (the user-typed Why-to-How consolidation command).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-intent-speccing",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 2,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "Turn what we just discussed into the contract the planner builds from.",
-      "expected_output": "Activates plastic-intent-speccing; an indirect trigger that names neither the skill nor spec.md.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-intent-speccing",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 3,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "Brainstorm this intent.",
-      "expected_output": "Activates plastic-intent-speccing (brainstorming is a mode of the thinking conversation since intent 304).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE != plastic-intent-speccing",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 4,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "Write the plan.",
-      "expected_output": "Does NOT activate plastic-intent-speccing; a plan is written from the action files by the executing skill.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE != plastic-intent-speccing",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 5,
-      "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 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": "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"
-        }
-      ]
-    },
-    {
-      "id": 6,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "Intent Z has Decisions recording D4: ship the setting as a CLI flag. A later Insights entry, timestamped after D4, reads: superseding ruling, ship as a config-file setting instead of a CLI flag, per user correction. Consolidate into spec.md.",
-      "expected_output": "The produced spec Approach and Decisions sections encode the LATER ruling (config-file setting); the superseded earlier Decision (CLI flag) does not stand as the shipped design in any section. The Decisions section notes that the later Insight supersedes D4.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "Approach and Decisions state the config-file setting, not the CLI flag; no section still asserts the CLI-flag path as the shipped design",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 7,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "Intent W is at Why. Context says the team wants error handling that is more resilient, but no Decision or Insight states which specific mechanism (retry, circuit breaker, or fallback) was chosen. Consolidate into spec.md.",
-      "expected_output": "Stops at step 5 (the gap rule) instead of inventing an Approach; asks the user which error-handling mechanism was decided, naming the missing ruling and the section it blocks.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "no invented Approach or Decisions content fills the gap; the agent asks for the missing ruling instead of guessing a default mechanism",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 8,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "Intent V has Decisions recording 3 rejected alternatives, each with a one-line reason it lost. Consolidate into spec.md.",
-      "expected_output": "Alternatives Considered renders as a table (Alternative, Not chosen because), not the bullet-dash form shown in the template; the produced spec file contains no em-dashes or en-dashes anywhere in the file.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "Alternatives Considered is a two-column table with one row per rejected alternative; a full-file dash-glyph scan of the produced spec file finds none",
-          "result": "expect-pass"
-        }
-      ]
-    }
-  ]
-}