@zalom/plastic 1.0.0-alpha.9 → 1.0.0-beta.10

package/skills/auto/evals/evals.json

@@ -0,0 +1,255 @@
+{
+  "skill_name": "plastic-auto",
+  "notes": "Intent 27. Scopes: description triggering (1-8) and behavior/output quality (9). Assertions written after observing Step-3 runs (one clean subagent router per case). Intent 63 added cases 10-11 (auto-mode enforcer-led team spin-up and solo fallback).",
+  "results": {
+    "triggering": {
+      "cases": 8,
+      "passed": 8,
+      "pass_at_1": 1.0,
+      "run": "2026-06-10, one subagent per case"
+    },
+    "behavior": {
+      "cases": 1,
+      "passed": 1,
+      "evidence": "dogfood: intent 27 itself delivered via auto produced spec->plan->checklist before any code edit; code-gate unit test proves pre-How project-code edits are blocked"
+    }
+  },
+  "evals": [
+    {
+      "id": 1,
+      "scope": "triggering",
+      "set": "train",
+      "prompt": "auto",
+      "expected_output": "Activates plastic-auto (the bare 'auto' keyword is the documented trigger).",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE == plastic-auto",
+          "observed": "plastic-auto",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 2,
+      "scope": "triggering",
+      "set": "train",
+      "prompt": "take it from here and deliver intent 27 end to end",
+      "expected_output": "Activates plastic-auto (autonomous delivery of an active intent).",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE == plastic-auto",
+          "observed": "plastic-auto",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 3,
+      "scope": "triggering",
+      "set": "validation",
+      "prompt": "go fully autonomous on the active intent, don't ask me questions",
+      "expected_output": "Activates plastic-auto.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE == plastic-auto",
+          "observed": "plastic-auto",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 4,
+      "scope": "triggering",
+      "set": "train",
+      "prompt": "deliver this intent for me",
+      "expected_output": "Activates plastic-auto.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE == plastic-auto",
+          "observed": "plastic-auto",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 5,
+      "scope": "triggering",
+      "set": "train",
+      "prompt": "set up a hook to automatically format the file on every save",
+      "expected_output": "Does NOT activate plastic-auto. Near-miss: shares 'auto*' but is a settings/hooks task (update-config).",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE != plastic-auto",
+          "observed": "update-config",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 6,
+      "scope": "triggering",
+      "set": "validation",
+      "prompt": "deliver the built package to the dist directory",
+      "expected_output": "Does NOT activate plastic-auto. Near-miss: shares 'deliver' but is a build/file task.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE != plastic-auto",
+          "observed": "none",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 7,
+      "scope": "triggering",
+      "set": "train",
+      "prompt": "create a new intent for the dashboard idea",
+      "expected_output": "Does NOT activate plastic-auto; activates plastic-creating-intent.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE != plastic-auto",
+          "observed": "plastic-creating-intent",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 8,
+      "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.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE != plastic-auto",
+          "observed": "plastic-managing-index",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 9,
+      "scope": "behavior",
+      "set": "train",
+      "prompt": "Active intent X exists with only a '## Intent' section. Deliver it in auto mode.",
+      "expected_output": "Arms the lifecycle gate first, then produces spec.md (Why), then plan.md + actions/ + checklist.md (How), and edits NO project code before plan.md + checklist.md exist. Disarms on completion.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "spec.md written before plan.md before any project-code edit",
+          "observed": "dogfood run of intent 27 followed this order",
+          "result": "pass"
+        },
+        {
+          "type": "code",
+          "check": "code-gate blocks project-code Edit/Write while pre-How (test/code_gate_test.rb)",
+          "observed": "test green",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 10,
+      "scope": "behavior",
+      "set": "train",
+      "prompt": "Active intent X exists. Deliver it in auto mode on a harness that supports subagents.",
+      "expected_output": "Spins up one enforcer-led team per intent (brainstorming, spec-specialist, planner, executor, plastic-enforcer). The enforcer IS the orchestrator. Dispatches one specialist per stage sequentially on one branch, gating each deliverable (Context+Decisions, then spec.md, then plan.md+actions+checklist, then code) against the stage exit criteria before handoff, and dispatches an independent reviewer subagent at the final gate only.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "five-role roster spun up; specialists dispatched stage-sequentially with per-stage gating; independent reviewer only at final gate",
+          "observed": "dogfood: intents 60-62 delivered by exactly this enforcer-led team on a shared branch",
+          "result": "pass"
+        },
+        {
+          "type": "code",
+          "check": "agents/plastic-*.md role files ship and install into the harness agent dir, manifest-tracked (test/install_packaging_test.rb)",
+          "observed": "test green",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 11,
+      "scope": "behavior",
+      "set": "validation",
+      "prompt": "Active intent X exists. Deliver it in auto mode on a harness with no subagent dispatch.",
+      "expected_output": "Falls back to a single agent walking the full What, Why, How, Exec cycle itself, preserving current behavior. The enforcer gate discipline still applies (arm the gate first, no project-code edits before plan.md + checklist.md exist).",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "solo agent walks the full cycle when subagent dispatch is unavailable; gate discipline preserved",
+          "observed": "SKILL.md Team Spin-Up documents the solo fallback explicitly",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 12,
+      "scope": "behavior",
+      "set": "validation",
+      "prompt": "A power-tool is present (qmd on PATH, or a .serena marker / serena on PATH). A substantive prompt arrives in auto mode.",
+      "expected_output": "The UserPromptSubmit power-tools hook appends a MANDATORY obligation per present tool: a MUST-use-QMD line when qmd is present (to check for an existing or related intent before treating work as new), and a MUST-use-Serena line when serena is present (symbolic tools before grep/Read). QMD hits are still injected when above threshold.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "PowerTools.mandate returns MUST/MANDATORY lines for each present tool; QmdHook.run appends the mandate",
+          "observed": "power_tools_test.rb + qmd_hook_test.rb assert MUST wording; serena line gated on the serena detector",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 13,
+      "scope": "behavior",
+      "set": "validation",
+      "prompt": "Neither qmd nor serena is present (no qmd on PATH, no .serena marker, no serena on PATH). A substantive prompt arrives.",
+      "expected_output": "Detect-then-degrade: the hook emits nothing (silent no-op, exit 0). No mandate text appears. Nothing is required to install.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "PowerTools.mandate returns nil and QmdHook.run returns nil when neither tool is present",
+          "observed": "power_tools_test.rb test_mandate_neither_is_nil + qmd_hook_test.rb test_nil_when_neither_tool_present",
+          "result": "pass"
+        }
+      ]
+    },
+    {
+      "id": 14,
+      "scope": "behavior",
+      "set": "validation",
+      "prompt": "QMD is present. In auto mode the user says: deliver the work on the uploader retry policy (no intent id given).",
+      "expected_output": "Before scanning the store with grep/Read to find the matching intent, runs `ruby ~/.plastic/scripts/qmd-sync search \"uploader retry policy\"` to surface the candidate intent, then opens the authoritative intent file for the hit it takes over. This discovery step is distinct from the completion-time reindex step. No-op fallback to INDEX.md / file scan when QMD is absent.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "qmd-sync search is run before grep/Read during discovery; authoritative file opened for the hit; reindex step stays separate",
+          "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"
+        }
+      ]
+    }
+  ]
+}

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

@@ -0,0 +1,155 @@
+# Agent Architecture
+
+## Main Orchestrator
+
+The Main Orchestrator manages the global store (Main Knowledge Base). It:
+- Recognizes, creates, updates, and groups intents
+- Spawns Project Orchestrators for registered projects
+- Receives contributions back from Project Orchestrators
+- Is the only agent that runs in a loop (continuous Build, Observe, Repeat)
+
+## Project Orchestrators
+
+Project Orchestrators manage project stores (Project Knowledge Bases). They:
+- Care about intents and execution within their project
+- Spin up an enforcer-led team to deliver an intent
+- Contribute back to the Main Orchestrator when new intents are born
+  that could enrich the Main Knowledge Base
+
+## The Auto-Mode Team
+
+Auto mode spins up exactly ONE enforcer-led team per intent. The plastic-enforcer
+IS the auto orchestrator itself, not a separately dispatched agent. Making the
+orchestrator the enforcer avoids the who-gates-the-gater regress (the gate-keeper
+can never be ungated).
+
+The team has five roles, one per place in the What, Why, How, Exec cycle:
+
+- **plastic-brainstorming** (Why exploration): enriches `## Context` and records
+  `### Decisions` with rationale.
+- **plastic-spec-specialist** (Why-to-How boundary): consolidates the Why into
+  `spec.md` (Problem, Goals, Non-Goals, Approach, Decisions, Acceptance Criteria).
+- **plastic-planner** (How): produces `plan.md`, `actions/ACTION_N.md`, and
+  `checklist.md`.
+- **plastic-executor** (Exec): writes the code, checks off `checklist.md`, appends
+  `## Insights`, and drives the suite green.
+- **plastic-enforcer** (spans the whole cycle): orchestrates and gates.
+
+### Handoff Contracts
+
+Each specialist receives the prior stage's deliverable and produces the next stage's
+input. The enforcer dispatches one specialist per stage with a constructed context
+bundle, gates that deliverable against the stage's exit criteria, and only then hands
+off to the next stage. Dispatch is sequential on a single branch, because the stage
+deliverables share files (a parked spec, plan, and checklist all live in the same
+intent directory).
+
+The chain: intent `## Intent` / `## Context`, then enriched `## Context` plus
+`### Decisions`, then `spec.md`, then `plan.md` plus `actions/` plus `checklist.md`,
+then the code changes plus a checked-off checklist plus `## Insights`.
+
+### Spawn Preamble (L2 live-state injection)
+
+Every dispatched specialist is booted with a spawn preamble: the enforcer runs
+`scripts/spawn-preamble <intent_dir> --role <role>` and prepends its output to the
+specialist's prompt. The preamble is a pure function of the intent directory on disk
+(no network, no clock, no randomness), so it is deterministic and rebuildable. It
+carries the active intent id and intent line, the current lifecycle stage (the last
+savepoint line, else stage derived from which lifecycle files exist), the cycle
+role, and the honoring instruction that the agent must emit valid lifecycle artifacts
+and not hallucinate intents or stages. This is the standard L2 live-state mechanism
+for harnesses whose spawned sub-agents do not inherit the top-level session event. See
+`docs/reference/harness-adapters.md` for how it slots into the per-harness contract.
+
+### Completion Reports
+
+Every dispatched specialist ends its turn with a structured completion report as its final
+message (its return value), so the agent that did the work is the one that accounts for it. The
+report carries a common envelope plus a role-specific payload that fulfils the agent's place in
+the cycle; the planner explains the plan back to the orchestrator, the executor reports what was
+built and the test result, and so on. The format lives in `references/agent-report-contract.md`,
+and the verbatim instruction is injected once via the spawn preamble's `REPORT_CONTRACT`
+constant, which the role prompts reproduce.
+
+Enforcement is require-report then synthesize-fallback. The preamble and prompts make the report
+mandatory (decision-shaping), but child-agent honor is best-effort across harnesses (Tier B/C),
+so it is never a hard block. When a specialist returns no usable report, the enforcer runs
+`scripts/agent-report <intent_dir> --role <role>`, a pure function of the intent dir (no network,
+clock, or randomness, mirroring `spawn-preamble`) that emits a filesystem-derived report from the
+savepoint, the artifacts present, the checklist checked/total, and the outcome line. A handoff
+account therefore always exists: agent-authored when present, deterministically reconstructed
+otherwise. This structures the finish notification only; in-flight observations stay in
+`## Insights`, no progress chatter is added.
+
+### Gate Ownership
+
+The enforcer arms and verifies the lifecycle gate, then gates every stage transition.
+It never delegates gate ownership. At the final gate only, it dispatches an
+INDEPENDENT reviewer subagent to review the delivered work. That reviewer is not a
+permanent sixth role, it exists only for the final review.
+
+### Headless Manual Gate
+
+When running headless or in the background, the enforcer enforces gates manually and
+does not rely on hooks, because `CLAUDE_SESSION_ID` may be unset in those runs (the
+gate-check and savepoint hooks no-op without it). The enforcer arms via the bridge's
+derived-key fallback and 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
+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
+and where the gates sit; the dispatch engine, native or superpowers, does the actual
+spawning.
+
+### Fallback by Case
+
+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
+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.
+
+### Dogfood Proof
+
+Intents 60, 61, and 62 were delivered by exactly this enforcer-led team on a shared
+branch, which is the dogfooded proof that the model works end to end.
+
+## Two Modes
+
+- **Human-driven:** Human chats with the Main Orchestrator, creates intents,
+  brainstorms, then the Main Orchestrator dispatches Project Orchestrators and teams
+  for execution.
+- **Autonomous:** Human gives the Main Orchestrator a starting intent with defined
+  outcomes. The enforcer-led team runs the full cycle (the specialists do the
+  lifecycle, the enforcer reviews Insights and gates), then the orchestrator spawns
+  next intents and dispatches again.
+
+## Autonomous Delivery
+
+Human owns What and Why for human-initiated intents. The team assists (research,
+exploration) but the human drives until handoff. When Why is complete, or the human
+triggers `plastic-auto`, the enforcer-led team takes over How and Exec autonomously.
+
+- **Safe-by-default:** the executor always prefers non-destructive routes (rename vs
+  delete, additive migrations, backups before changes). Destructive actions on
+  existing projects require human approval unless `--skip-permissions` is set.
+- **Notification only on:** finish or hard stop (blocked on destructive action,
+  unresolvable error). No progress reports, `## Insights` tracks everything.
+- **Greenfield autonomy:** during initial project creation, all decisions are
+  non-destructive (nothing to destroy), so the team has full autonomy for greenfield
+  choices.
+- **Autonomous decisions** are logged in `## Insights` with the `(autonomous)` marker.
+
+## Coordinator Loop
+
+When "work on Project X":
+1. Read `projects.yml`, find the project path
+2. Load global config (defaults)
+3. Load project config (overrides)
+4. Load global INDEX.md, find hub intents tagged `project-<name>`
+5. Load project INDEX.md, find tactical intents
+6. The coordinator has the full picture, spins up an enforcer-led team per intent

package/skills/auto/references/agent-report-contract.md

@@ -0,0 +1,86 @@
+# Agent Completion Report Contract
+
+Every agent dispatched by the auto-mode enforcer MUST end its turn with a structured
+completion report. This doc defines that report: one common envelope plus a per-role payload.
+It is the format the `REPORT_CONTRACT` constant in `scripts/spawn-preamble` points at, the
+role prompts (`agents/plastic-*.md`) reproduce, and the deterministic fallback
+(`scripts/agent-report`) approximates. Keep all four in agreement; the constant in
+`scripts/spawn-preamble` is the single source of truth for the injected wording.
+
+## Purpose
+
+The report is the agent's FINAL MESSAGE (its return value), not a side-channel file. Every
+harness hands a spawned agent's final text back to the dispatcher, so the final message is the
+one carrier that works everywhere (decision D1). The report structures the FINISH notification
+only. In-flight observations still go in `## Insights`; the report does not add progress chatter
+(decision D5). An agent that finishes correct artifacts but goes idle without a report has not
+completed its handoff: the agent that did the work is the cheapest, most accurate source of the
+account.
+
+## Common envelope
+
+Every role report, whatever the stage, carries these fields:
+
+- **Role**: which specialist produced this (brainstorming, spec, planner, executor, reviewer).
+- **Intent id and stage**: the active intent id and the cycle stage just completed.
+- **Status**: `delivered` or `blocked`.
+- **Artifacts written**: the files produced or changed (store paths, and project paths for the
+  executor).
+- **Verification / tests run**: the command run and its result, or `n/a` for stages that write
+  no code.
+- **Checklist deltas**: which checklist items this turn checked off (executor), or `n/a`.
+- **Deviations from spec**: anything done differently from the spec or plan, and why, or `none`.
+- **Blockers / handoff notes**: what the next stage must watch for, or `none`.
+
+## Per-role payload
+
+Each role appends a payload that fulfils its place in the What, Why, How, Exec cycle (decision
+D2). The payload is what makes the report useful to the orchestrator beyond the envelope.
+
+### brainstorming (Why exploration)
+- Decisions recorded in `### Decisions`, each with its one-line rationale.
+- Context enriched: what was researched and the key findings.
+- Open questions resolved, and any deliberately left for the spec.
+
+### spec-specialist (Why to How boundary)
+- Spec sections produced (Problem, Goals, Non-Goals, Approach, Decisions, Acceptance Criteria).
+- How the recorded decisions resolved into the chosen approach.
+- Acceptance-criteria count, so the planner knows the surface to cover.
+
+### planner (How): worked exemplar
+The planner report EXPLAINS THE PLAN BACK TO THE ORCHESTRATOR. It carries:
+- The ordered actions, one line each: what the action does and how it is verified.
+- Decomposition rationale: why this order, and why the actions are independent.
+- Checklist coverage: item count and that every action plus suite-green is covered.
+This is the exemplar because the plan is an argument, and the orchestrator gates on whether that
+argument is sound before any code is written.
+
+### executor (Exec)
+- Actions implemented this turn, mapped to checklist items checked off (checked / total).
+- A summary of the code changed (files and the shape of the change).
+- Test result: the full-suite command and its pass / fail counts.
+- Insights appended, with the `(autonomous)` marker.
+
+### final reviewer (final gate)
+- Verdict: `pass` or `blockers found`.
+- Each acceptance criterion checked, with the evidence that confirms or refutes it.
+- Gaps or risks found, ranked, with a recommended disposition.
+
+## Fallback: always a report
+
+Decision-shaping (the preamble plus these prompts) makes the report mandatory, but child-agent
+honor is best-effort across harnesses (Tier B/C in `docs/reference/harness-adapters.md`), so the
+contract is never a hard block (decision D3). When a dispatched agent returns no usable report
+(it went idle, emitted only a bare ping, or its message was lost to a mid-run interjection), the
+enforcer synthesizes one:
+
+```
+scripts/agent-report <intent_dir> --role <role>
+```
+
+`scripts/agent-report` is a pure function of the intent directory (no network, clock, or
+randomness, mirroring `scripts/spawn-preamble`): it reads the current stage from the savepoint
+ledger, the lifecycle artifacts present, the checklist checked / total, and the `## Outcome`
+line, and emits a filesystem-derived report labelled `synthesized`. So a handoff account always
+exists: authored by the agent when possible, reconstructed deterministically when not. This
+formalizes the by-hand reconstruction the orchestrator did while delivering intent 68.

package/skills/brainstorming/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plastic:brainstorming
+name: plastic-brainstorming
 description: "Explore intent requirements and design before implementation. Produces spec.md in the active intent directory."
 ---
 
@@ -20,7 +20,7 @@ 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-creating-intent"
 3. **Resolve intent directory:** `{store}/store/{id}--{slug}/`
 
 All artifacts go to the intent directory. Never write to external paths.
@@ -40,7 +40,7 @@ You MUST create a task for each of these items and complete them in order:
 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`
+8. **Transition to planning** — invoke `plastic-writing-plans`
 
 ## Process Flow
 
@@ -54,7 +54,7 @@ digraph brainstorming {
     "Write spec" [shape=box];
     "Spec self-review\n(fix inline)" [shape=box];
     "User reviews spec?" [shape=diamond];
-    "Invoke plastic:writing-plans" [shape=doublecircle];
+    "Invoke plastic-writing-plans" [shape=doublecircle];
 
     "Explore project context" -> "Ask clarifying questions";
     "Ask clarifying questions" -> "Propose 2-3 approaches";
@@ -65,15 +65,16 @@ digraph brainstorming {
     "Write spec" -> "Spec self-review\n(fix inline)";
     "Spec self-review\n(fix inline)" -> "User reviews spec?";
     "User reviews spec?" -> "Write spec" [label="changes requested"];
-    "User reviews spec?" -> "Invoke plastic:writing-plans" [label="approved"];
+    "User reviews spec?" -> "Invoke plastic-writing-plans" [label="approved"];
 }
 ```
 
-**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 invoking `plastic-writing-plans`.** Do NOT invoke any other implementation skill. The ONLY skill you invoke after brainstorming is `plastic-writing-plans`.
 
 ## The Process
 
 **Understanding the idea:**
+- 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.
@@ -107,7 +108,7 @@ digraph brainstorming {
 
 ## After the Design
 **Documentation:**
-- Write the validated design (spec) to `{intent_dir}/spec.md`
+- 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:
   ```
@@ -130,8 +131,8 @@ After the spec review loop passes, ask the user to review the written spec befor
 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.
 
 **Implementation:**
-- Invoke `plastic:writing-plans` to create the implementation plan
-- Do NOT invoke any other skill. `plastic:writing-plans` is the next step.
+- Invoke `plastic-writing-plans` to create the implementation plan
+- Do NOT invoke any other skill. `plastic-writing-plans` is the next step.
 
 ## Key Principles
 

package/skills/brainstorming/evals/evals.json

@@ -0,0 +1,22 @@
+{
+  "skill_name": "plastic-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.",
+  "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"
+        }
+      ]
+    }
+  ]
+}

package/skills/brainstorming-grill-me/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: plastic:brainstorming-grill-me
+name: plastic-brainstorming-grill-me
 description: >-
   Deep brainstorming that interviews the user relentlessly about a plan or design until reaching shared understanding.
   Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
-  Complements superpowers:brainstorming — use brainstorming for quick ideation, grill-me for thorough interrogation.
+  Pair with plastic-brainstorming for quick ideation and use grill-me for thorough interrogation. If superpowers:brainstorming is installed it complements this skill, but it is not required.
 ---
 
 # Grill Me — Deep Brainstorming
@@ -83,18 +83,18 @@ If ALL items pass, offer autonomous delivery:
 >
 > Want to grill more, or should I go autonomous?"
 
-- If human says go → invoke `plastic:auto`
+- If human says go → invoke `plastic-auto`
 - If human says grill more → continue grilling (reset to step 2)
 - If human says neither (wants to drive manually) → proceed as before (offer planning)
 
 This offer replaces the final question in Close Out ("Ready to plan implementation, or do you want another pass?"). The new options are:
-1. Go autonomous (`plastic:auto`)
+1. Go autonomous (`plastic-auto`)
 2. Grill more (continue interrogation)
 3. Plan manually (invoke `superpowers:writing-plans` or proceed with human-driven planning)
 
 ## Relationship to superpowers:brainstorming
 
-| | superpowers:brainstorming | plastic:brainstorming-grill-me |
+| | superpowers:brainstorming | plastic-brainstorming-grill-me |
 |---|---|---|
 | Speed | Quick (5-10 min) | Thorough (20-45 min) |
 | Depth | Surface-level exploration | Exhaustive decision tree |
@@ -102,4 +102,4 @@ This offer replaces the final question in Close Out ("Ready to plan implementati
 | Output | Initial spec | Battle-tested spec with all branches resolved |
 | Style | Collaborative, exploratory | Interrogative, relentless |
 
-Use `superpowers:brainstorming` to generate ideas. Use `plastic:brainstorming-grill-me` to pressure-test them.
+Use `superpowers:brainstorming` to generate ideas. Use `plastic-brainstorming-grill-me` to pressure-test them.