@zalom/plastic 1.14.0 → 2.0.0-alpha.1

package/skills/intent-grilling/SKILL.md

@@ -1,108 +0,0 @@
----
-name: plastic-intent-grilling
-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".
-  Pair with plastic-intent-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.
-user-invocable: true
----
-
-# Grill Me — Deep Brainstorming
-
-You are about to interview the user relentlessly. This is NOT a quick brainstorm — it is a thorough interrogation of every assumption, dependency, and design decision until you reach shared understanding.
-
-## Detect Mode
-
-**Coding mode** — the user is designing something that involves code (feature, architecture, refactor, system design):
-- You CAN and SHOULD explore the codebase to answer your own questions
-- Before asking "how does X work?", check if you can find out yourself
-- Ground your questions in what actually exists, not what you imagine
-
-**Non-coding mode** — the user is designing something conceptual (process, workflow, strategy, product):
-- No codebase to explore
-- Focus purely on the design tree
-
-## Workflow
-
-### 1. Identify the Root
-
-Ask: "What are we designing?" Get the one-sentence version. Restate it back to confirm.
-
-### 2. Walk the Decision Tree
-
-For each branch of the design:
-
-1. **State the branch** — "Let's talk about [aspect]."
-2. **Ask your question** — Be specific. "How will X handle Y when Z happens?"
-3. **Provide your recommended answer** — Always lead with what YOU think the answer should be, based on what you know. Let the user confirm, correct, or redirect.
-4. **Resolve before moving on** — Do not leave ambiguity. If the user says "I'm not sure", help them decide. Push.
-5. **Track dependencies** — If decision A affects decision B, say so. Resolve A first.
-
-### 3. Be Relentless
-
-- Do NOT accept vague answers. "It depends" requires "on what?"
-- Do NOT skip edge cases. "What happens when the list is empty?"
-- Do NOT assume. If you think you know, verify.
-- Do NOT be polite at the expense of thoroughness. Friendly but unrelenting.
-- DO challenge the user's assumptions. "Why not [alternative]?"
-- DO synthesize as you go. After every 3-4 questions, summarize what's been decided.
-
-### 4. Time Awareness
-
-This process is thorough. It typically takes 20-45 minutes for a complex design. At natural checkpoints (~every 10 questions), offer:
-
-> "We've covered [areas]. Still to explore: [areas]. Continue, or pause and capture what we have?"
-
-If the user wants to pause, capture all decisions made so far into the active intent's `## Context` / `### Decisions`, ready for /plastic-intent-speccing to consolidate later.
-
-### 5. Close Out
-
-When all branches are resolved:
-
-1. Record every ruling in the active intent's `## Context` / `### Decisions`, then hand off
-   to /plastic-intent-speccing to consolidate them into `spec.md` (that skill owns
-   `spec.md` exclusively)
-2. List all decisions made
-3. List any deferred items (things the user explicitly chose to decide later)
-4. Proceed to Autonomous Handoff Offer (step 6)
-
-### 6. Autonomous Handoff Offer
-
-After closing out (decisions listed, spec consolidated by /plastic-intent-speccing), assess whether the agent has enough context to deliver the intent autonomously.
-
-**Self-assessment checklist:**
-- All key decisions resolved (no open "it depends" or "TBD")
-- Scope is clear and bounded
-- Dependencies are identified
-- Success criteria are defined
-
-If ALL items pass, offer autonomous delivery:
-
-> "I have enough context to take this from here. Here's my understanding:
->
-> **Decisions:** [list key decisions]
-> **Scope:** [one-line scope summary]
-> **Approach:** [high-level approach]
->
-> Want to grill more, or should I go autonomous?"
-
-- 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`)
-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-intent-grilling |
-|---|---|---|
-| Speed | Quick (5-10 min) | Thorough (20-45 min) |
-| Depth | Surface-level exploration | Exhaustive decision tree |
-| When | Starting ideation, exploring options | Stress-testing a design, resolving ambiguity |
-| Output | Initial spec | Battle-tested spec with all branches resolved |
-| Style | Collaborative, exploratory | Interrogative, relentless |
-
-Use `superpowers:brainstorming` to generate ideas. Use `plastic-intent-grilling` to pressure-test them.

package/skills/intent-linking/SKILL.md

@@ -1,128 +0,0 @@
----
-name: plastic-intent-linking
-description: Use when creating connections between intents, the user says "link" or "connect", or when discovering that two intents are related. Manages sources, chain, and cross-reference links.
-user-invocable: false
----
-
-# Linking Intents
-
-## When to Use
-- During intent creation (automatic: ask about related intents)
-- User says "link", "connect", "relates to"
-- Agent discovers a relationship between intents during work
-
-## Discovery and ranking are separate
-
-Two distinct steps, do not conflate them:
-
-1. **Discovery** (finding candidate related intents) may use any tool: grep, find, ripgrep,
-   or QMD/Serena when present (QMD-first per the project rule). Discovery casts a wide net.
-2. **Ranking** the candidates is a CONTEXT-INFLUENCE judgement: read each candidate's `## Intent`
-   and `## Context` and ask whether that context actually informed this intent. Ranking is NOT a
-   structural metric (no shared-file or shared-symbol grading: on intent 90, matching whole files
-   flagged 35 intents because ~20 touch `bridge.rb`). It is NOT a similarity score either (QMD
-   relevance measures topic proximity, not influence). A script cannot make this call; an agent
-   does.
-
-## The three tiers (by context influence)
-
-Read `../plastic-conventions/references/knowledge-graph.md` for the full linking doctrine behind
-these tiers, the sources-versus-chain distinction, and the `## Links` projection. This path
-resolves relative to this skill's own installed directory.
-
-- **sources:** the foundational context that shaped this intent's CREATION (a split, an idea born
-  during development, a merge). Earns an edge. Decided by origin, never inferred.
-- **chain:** the context that materially helps DELIVER this intent. HIGH bar: only the genuinely
-  delivery-moving intents, not everything in the same area. Earns an edge, reflected in `## Links`.
-  Worked example (intent 90): 79 created it so 79 is a source; 80 deferred the exact fix 90 makes,
-  so its context directly helps delivery and 80 is chain; 49/66/73 are same-area background, so
-  they get a shared tag and no link.
-- **tags:** loose theme grouping for search. NOT a link.
-
-**Timing.** The influence judgement happens at What/Why (and during upkeep), guided by this rule.
-It does not wait for code to exist; it is reasoning over the candidate's context, not over a diff.
-
-**Record the call.** For every edge an agent adds, store a rating (high / medium / low) plus a
-one-line reason as a dated line under the intent file's `## Insights` section (per 96 D3, link
-rationale lives in the intent file, not a side file). It stays out of frontmatter (graph only) and
-out of the projected `## Links` label, so the audit trail never breaks the projection identity.
-
-## `## Links` is derived (never author it by hand)
-
-`## Links` is a DERIVED view of `sources` then `chain`, not a place to write links. Never
-hand-write a `## Links` line, and never auto-delete one. To add a link, add the frontmatter
-edge (below), then let the projection regenerate the section (`scripts/project-links`).
-
-Run `scripts/link-suggest <id>` to gather candidate intents WITH each one's Intent and Context (the
-evidence you judge influence on) and to flag drift (a `## Links` line with no frontmatter edge
-behind it). To record a confirmed edge plus its rating and reason, run it with
-`--record <id> --edge <sources|chain> --rating <high|medium|low> --reason "..." --confirm`. It never
-grades influence itself, never writes an edge without `--confirm`, and never deletes.
-
-## Connection Types (the frontmatter edges)
-
-### 1. Sources (Backward)
-The `sources` array in frontmatter. The direct ascendant(s) this intent was created from / emerged from the lifecycle of (formation, not topic similarity), backward links to the work it was built out of:
-```yaml
-sources: ["1a", "1a2"]
-```
-
-### 2. Chain (Forward)
-The `chain` array in frontmatter. What this intent spawned AND related-but-not-spawned successors it leads to, forward links to children, follow-on, and related work:
-```yaml
-chain: ["1b1", "1b2"]
-```
-
-### 3. Tags (for discovery, not links)
-Shared tags in frontmatter enable filtered discovery. Use `project-<name>` tags for project membership. A shared tag is a loose theme grouping: it earns NO edge.
-```yaml
-tags: [plastic, project-reddit-kb]
-```
-
-## Workflow
-
-### 1. Identify Intents to Connect
-
-QMD-first (when available): before scanning the store with grep/Read, run
-`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` to surface candidate, prior, or related
-intents to propose as sources/chain, 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 directory scan below.
-
-Show existing intents by scanning the store's directory for intent files:
-```bash
-for dir in $STORE_ROOT/store/*/; do
-  f=$(find "$dir" -maxdepth 1 -name "*.md" ! -name "spec.md" ! -name "plan.md" ! -name "checklist.md" ! -name "outcome.md" ! -name "savepoint.md" | head -1)
-  [ -n "$f" ] && ruby -ryaml -e '
-    data = File.read(ARGV[0]).split("---")[1]
-    parsed = YAML.safe_load(data)
-    puts "#{parsed["id"]} | #{parsed["intent"]}" if parsed
-  ' "$f" 2>/dev/null
-done
-```
-
-### 2. Choose Connection Type
-Ask the user which type of connection:
-- **source**: "this was CREATED FROM that" (D1). The reciprocal update is one-directional (I1): add the ascendant id to this intent's `sources[]` AND add this intent's id to the ascendant's `chain[]`. A merely-related (not-created-from) connection is NOT a source: record it on the predecessor's `chain[]` only, plus a `## Links` wikilink, with NO `sources` (the related-but-not-spawned rule).
-- **cross-reference**: "these are related" (add wikilink in `## Links` of both intents)
-
-### 3. Apply Connection
-
-**For sources (a true created-from edge only):**
-Update frontmatter arrays on both intents (I1, two-sided):
-- Add the parent's ID to the child's `sources` array
-- Add the child's ID to the parent's `chain` array
-
-For the merely-related case, only the predecessor's `chain` (and both sides' `## Links`)
-get the link, never `sources`. `chain` is NOT strictly the reverse of `sources` (I2):
-relational `chain` entries are valid and must never be "corrected" by adding a reciprocal
-`sources`.
-
-**For cross-references:**
-Add a wikilink in the `## Links` section of **both** intents (bidirectional).
-
-### 4. Update INDEX.md Clusters
-If both intents share a topic, ensure they're in the same cluster.
-
-## References
-
-- Read `references/zettelkasten.md` for the three Zettelkasten structures (Folgezettel, directed graph, tags), ID encoding rules, and dual-mode (Obsidian + programmatic) design

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

@@ -1,22 +0,0 @@
-{
-  "skill_name": "plastic-intent-linking",
-  "notes": "Intent 66a. Spec for the QMD-first discovery step (surface candidate/related intents to propose as sources/chain before grep/Read). Runner is intent 76; this case is a spec, not executed.",
-  "evals": [
-    {
-      "id": 1,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "QMD is present. The user says: link this intent to the related upload-pipeline work.",
-      "expected_output": "Before scanning the store directory with grep/Read to identify related intents, runs `ruby ~/.plastic/scripts/qmd-sync search \"upload pipeline\"` to surface candidate or related intents to propose as sources/chain, then opens the authoritative intent file for any hit it links. No-op fallback to the directory scan when QMD is absent.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "qmd-sync search is run before the directory scan; authoritative file opened for any hit before proposing sources/chain",
-          "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/intent-linking/references/zettelkasten.md

@@ -1,45 +0,0 @@
-# Zettelkasten Structure
-
-Plastic implements three Zettelkasten structures:
-
-| Structure | Implementation | Purpose |
-|---|---|---|
-| Folgezettel (linked list) | `sources` + `chain` in frontmatter | Sequential provenance |
-| Directed graph (web of notes) | `## Links` with wikilinks | Obsidian navigation |
-| Tag-based taxonomy | `tags` in frontmatter | Topic grouping |
-
-INDEX.md is a structure note (hub), not a table of contents.
-
-`## Links` mirrors the frontmatter graph exactly. Each entry is
-`- [[id--slug|<target's full intent: text>]]` (cross-store: `- [[store:id--slug|...]]`),
-a clickable `id--slug` target with the target's full `intent:` text as the label.
-Ordering is mandatory: all `sources` first (top), then all `chain`, frontmatter order
-preserved within each group. Sources never appear at the end. No source/chain tags, no
-sub-grouping. An intent with empty `sources` and `chain` carries the empty-state comment.
-
-## Folgezettel IDs
-
-IDs encode lineage using Luhmann's alternating convention:
-- Root intents: sequential numbers (`1`, `2`, `3`...)
-- Branches alternate letters and numbers: `1` → `1a` → `1a1` → `1a1a` → ...
-- Multiple branches from the same parent increment: `1a`, `1b`, `1c`
-- IDs are assigned at creation time and never change
-
-## Knowledge Graph
-
-`sources` and `chain` form the directed knowledge graph:
-- `sources` = the direct ascendant(s) this intent was created from / emerged from the
-  lifecycle of (formation, not topic similarity); a DAG (acyclic), strong must-load context.
-- `chain` = forward continuations AND related-but-not-spawned successors it leads to; a
-  directed graph that may cycle, lighter contributory context.
-- Reciprocity is one-directional: every `sources` edge has a reciprocal `chain` entry (I1),
-  but `chain` may carry relational entries with no reciprocal `sources` (I2), so the graph is
-  NOT strictly double-linked.
-
-## Dual-Mode
-
-This store works in two modes without modification:
-- **Obsidian** (human, offline) — browse, link, write markdown
-- **Programmatic** (any agent) — read/write via filesystem operations
-
-No special tooling required for either mode.

package/skills/intent-locking/SKILL.md

@@ -1,64 +0,0 @@
----
-name: plastic-intent-locking
-description: Inspect, repair, release, or reclaim an intent's delivery lock. Use when a lock-gate deny names /plastic-lock, when resuming interrupted work after a crash, reboot, or /tmp wipe, when a lock reads held or stale, or when the user says "fix the lock", "who holds the lock", or "reclaim the lock".
-user-invocable: false
----
-
-# Plastic Lock
-
-Command-only wrapper around `~/.plastic/scripts/plastic-lock`. The durable
-delivery lock is a `delivery.lock` file in the intent directory: ownership is
-session-keyed, liveness is a lease (the owner's hooks refresh the file mtime;
-stale means the heartbeat is older than the TTL). The /tmp bridge is only a
-cache; the lock file wins every disagreement.
-
-Read `../plastic-conventions/references/locks-and-worktrees.md` for delivery isolation in full:
-the single-owner lock, claims, worktrees, solo mode, and the station ledger behind every verb
-below. This path resolves relative to this skill's own installed directory.
-
-## Verbs
-
-Run from the project (the intent resolves from this session's bridge), or pass
-`--intent-dir` explicitly:
-
-| Verb | What it does | When |
-|---|---|---|
-| `who` | Print a compact owner, heartbeat, claim, and delegate view from durable files only | Safe human inspection; requires `--intent-dir` |
-| `status` | Report the lock file, bridge cache, freshness, agreement | Always safe; run first |
-| `fix` | Idempotent repair: rebuild lock + bridge from disk truth for THIS session. Never touches a fresh foreign lock | Interrupted work, corrupted state, /tmp wiped, legacy pid locks |
-| `release` | Owner clears the lock | Ending or abandoning a boarding |
-| `reclaim` | Explicit takeover of a STALE lock; appends an audit line to savepoint.md | The owner is gone and the lease expired |
-| `delegate` | Owner registers a subagent session and optional provenance, or marks it `finished`/`failed` | Auto-mode orchestration |
-
-```
-ruby ~/.plastic/scripts/plastic-lock status
-ruby ~/.plastic/scripts/plastic-lock who --intent-dir <store>/<id>--<slug>
-ruby ~/.plastic/scripts/plastic-lock fix --intent-dir <store>/<id>--<slug>
-ruby ~/.plastic/scripts/plastic-lock reclaim --intent-dir <store>/<id>--<slug>
-ruby ~/.plastic/scripts/plastic-lock delegate --delegate <subagent-session-id> \
-  --harness codex --agent plastic-executor --model <model> --thread <thread-id>
-ruby ~/.plastic/scripts/plastic-lock delegate --delegate <subagent-session-id> --status finished
-```
-
-When the current controller knows its provenance, `fix` and `reclaim` accept
-`--harness`, `--agent`, `--model`, `--thread`, and `--mode auto|guided`.
-Provenance is descriptive; the session remains the authorization identity.
-
-## Rules
-
-- `fix` exits non-zero when another session holds a FRESH lock: back off, do
-  not retry in a loop. `status` shows the owner.
-- `who` is strictly read-only. It reads `delivery.lock`, its mtime, and claim
-  files; it never reads or repairs a bridge, searches transcripts, heartbeats,
-  or writes. Missing legacy provenance displays as `Unknown` rather than being
-  inferred.
-- The `delivery.lock` file mtime is the sole heartbeat and freshness truth.
-  Provenance timestamps do not replace it.
-- Only the lock owner may register delegates or mark them `finished` or
-  `failed`. Terminal status is observational and does not remove the delegate
-  session from the authorization list. Finished and failed activity history is
-  bounded to the 20 most recent terminal entries.
-- `reclaim` refuses a fresh lock. There is no silent reclaim anywhere; every
-  takeover is audited in the intent's savepoint.md.
-- Acquiring a lock for new work is NOT this skill's job: board through
-  `/plastic-intent-starting`, which calls the same repair internally.

package/skills/intent-planning/SKILL.md

@@ -1,145 +0,0 @@
----
-name: plastic-intent-planning
-description: "Write implementation plans from a spec. Produces plan.md, checklist.md, and at least one real actions/ACTION_N.md (every tier) in the active intent directory."
-user-invocable: true
----
-
-# Writing Plans
-
-## Overview
-
-Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
-
-Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
-
-## Active Intent Gate
-
-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-intent-creating"
-3. **Resolve intent directory:** `{store}/store/{id}--{slug}/`
-4. **Read spec:** Load `{intent_dir}/spec.md`. If no spec exists → refuse: "No spec found. Run /plastic-intent-speccing first."
-
-All artifacts go to the intent directory. Never write to external paths.
-
-## Scope Check
-
-If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans, one per subsystem. Each plan should produce working, testable software on its own.
-
-## Tier shapes
-
-Read `../plastic-conventions/references/tiers-and-dispatch.md` for tier sizing and the
-stage-to-agent dispatch rules behind this section. This path resolves relative to this skill's own
-installed directory.
-
-Read the spec's stamped `Tier:` line (written by intent-speccing) and pick the action shape it calls for. Every tier produces at least one REAL action file in `actions/`; the tier only changes how many:
-
-- **S or M (default):** write ONE consolidated `actions/ACTION_1.md` that carries the whole ordered delivery (the steps plus the exact changes). `plan.md` still holds the overall map and `checklist.md` still mirrors the task list. You may split into a few action files when that reads cleaner, but one real action file is the floor.
-- **L (many independent tasks, dispatched in parallel):** self-contained `actions/ACTION_N.md`, one per task, each readable without the plan (see `references/plan-format.md`).
-
-A `.gitkeep` never counts as an action, and an empty `actions/` fails the How gate at every tier. At S/M, keep it to a single consolidated action file rather than one-per-task; over-splitting a small intent is the S/M failure mode, an empty `actions/` is the tier-wide one.
-
-## File Structure
-
-Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.
-
-- Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.
-- You reason best about code you can hold in context at once, and your edits are more reliable when files are focused. Prefer smaller, focused files over large ones that do too much.
-- Files that change together should live together. Split by responsibility, not by technical layer.
-- In existing codebases, follow established patterns. If the codebase uses large files, don't unilaterally restructure - but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.
-
-This structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.
-
-## Bite-Sized Task Granularity
-
-Granularity follows the `Tier:` line the spec stamped.
-
-**At M or L, each step is one action (2-5 minutes):**
-- "Write the failing test" - step
-- "Run it to make sure it fails" - step
-- "Implement the minimal code to make the test pass" - step
-- "Run the tests and make sure they pass" - step
-- "Commit" - step
-
-**At S, size each step to the work.** Do not slice a small delivery into fixed 2-5 minute steps. Keep steps coarse enough to read in one pass, and let the one consolidated `actions/ACTION_1.md` carry the whole delivery. Each step still names its exact file paths, its exact changes, and how it is verified. Only the slicing relaxes.
-
-This changes granularity, nothing else. Every tier still produces at least one real `actions/ACTION_N.md`, and an empty or `.gitkeep`-only `actions/` still fails the How gate (see `## Tier shapes` above).
-
-## Plan Format
-
-For the exact plan/task/checklist/action format (the Plan Document Header
-template, the full Task Structure worked example, and the checklist.md /
-actions/ACTION_N.md templates), read `references/plan-format.md` before
-writing plan.md. Every plan starts with the header template and decomposes
-into tasks matching the Task Structure shape.
-
-## No Placeholders
-
-Every step must contain the actual content an engineer needs. These are **plan failures**, never write them:
-- "TBD", "TODO", "implement later", "fill in details"
-- "Add appropriate error handling" / "add validation" / "handle edge cases"
-- "Write tests for the above" (without actual test code)
-- "Similar to Task N" (repeat the code; the engineer may be reading tasks out of order)
-- Steps that describe what to do without showing how (code blocks required for code steps)
-- References to types, functions, or methods not defined in any task
-
-## Remember
-- Exact file paths always
-- Complete code in every step: if a step changes code, show the code
-- Exact commands with expected output
-- DRY, YAGNI, TDD, frequent commits
-
-## Self-Review
-
-After writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself, not a subagent dispatch.
-
-**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.
-
-**2. Placeholder scan:** Search your plan for red flags, any of the patterns from the "No Placeholders" section above. Fix them.
-
-**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clear_layers` in Task 3 but `clear_full_layers` in Task 7 is a bug.
-
-If you find issues, fix them inline. No need to re-review, just fix and move on. If you find a spec requirement with no task, add the task.
-
-## Plastic Artifacts
-
-After writing `plan.md`, create `checklist.md` (execution registry following the
-FORM: `## In Progress`, `## Completed`, `## Session Log`) and at least one real
-`actions/ACTION_N.md` (self-contained, in an `actions/` directory inside the intent
-directory). At S/M write one consolidated `actions/ACTION_1.md`; at L write one
-`actions/ACTION_N.md` per task (see Tier shapes above). For the exact format of
-both, read `references/plan-format.md`.
-
-## Owner-decision hard-gate items
-
-When a task depends on an owner decision that must be made before any code edit
-happens (a destructive step, a structural ruling, a merge that must land first),
-add a checklist item prefixed `[ORCHESTRATOR]` that names the decision and states
-plainly that it blocks all code edits until the owner rules on it. Order these
-items first: destructive or structural rulings apply before the sweeping edits
-that depend on them.
-
-When collecting owner rulings for `[ORCHESTRATOR]` hard-gate items, read
-`~/.plastic/_decision-tables.md` and follow the numbered-table procedure.
-
-## Gate position
-
-- **Before:** `spec.md` exists.
-- **Produces:** `plan.md`, `checklist.md`, and at least one real `actions/ACTION_N.md` (every tier; one consolidated file at S/M, one per task at L).
-- **Next:** /plastic-intent-executing.
-
-Read `../plastic-conventions/references/lifecycle-and-savepoints.md` for the subagent
-report-home contract this handoff relies on.
-
-## Git Commit
-
-After writing all artifacts (plan.md, checklist.md, and the actions/ACTION_N.md files), commit to the store:
-
-```bash
-cd {store_root} && git add . && git commit -m "docs: plan for intent {id}: {name}"
-```
-
-## Execution Handoff
-
-Plan complete. Invoke `plastic-intent-executing` to begin execution.

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

@@ -1,81 +0,0 @@
-{
-  "skill_name": "plastic-intent-planning",
-  "notes": "Intent 164, updated by 133a. Evals for the writing-plans skill: action-file enforcement at every tier (S/M consolidate the delivery into one real actions/ACTION_1.md, L writes one actions/ACTION_N.md per task) and the checklist FORM plus [ORCHESTRATOR] hard-gate item convention. All assertions are pending a real observed run per the plastic-evaluating-skills convention.",
-  "evals": [
-    {
-      "id": 1,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "spec.md is stamped Tier: M and describes a single subsystem change touching four files across two tasks. Write the plan.",
-      "expected_output": "Produces plan.md plus checklist.md plus at least one real actions/ACTION_N.md. At M the planner consolidates the whole delivery into a single actions/ACTION_1.md (it may split into a few files if that reads cleaner); the actions/ directory is never left empty or .gitkeep-only. checklist.md mirrors plan.md's task list.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "at least one real (non-empty, non-.gitkeep) file exists under actions/ for this intent; checklist.md exists and mirrors plan.md's task list",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 2,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "spec.md is stamped Tier: S and describes a single-file config change. Write the plan.",
-      "expected_output": "Produces plan.md plus checklist.md plus one consolidated actions/ACTION_1.md carrying the whole ordered delivery (the steps plus the exact changes). The actions/ directory is never left empty or .gitkeep-only, matching the every-tier action-file rule.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "at least one real (non-empty, non-.gitkeep) actions/ACTION_N.md exists under actions/ for this intent; no empty or .gitkeep-only actions/ dir remains",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 3,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "spec.md is stamped Tier: L and describes a cross-cutting redesign decomposed into eight independent tasks meant to be dispatched to separate subagents in parallel. Write the plan.",
-      "expected_output": "Produces self-contained actions/ACTION_N.md, one file per task, each readable without the plan (full task text, code, and commands copied in). checklist.md has one item per task.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "actions/ directory contains one ACTION_N.md per task; each action file is self-contained (no bare references like \"see Task 3\" without the content)",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 4,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "spec.md names an owner decision (whether to delete or archive a legacy table) that must be ruled on before any code edit in the plan can proceed. Write the plan.",
-      "expected_output": "checklist.md includes a checklist item prefixed [ORCHESTRATOR] that names the owner decision and states it blocks all code edits until the owner rules; this item is ordered before the sweeping edit tasks that depend on it. checklist.md follows the FORM: ## In Progress, ## Completed (empty), ## Session Log with Date | Items Completed | Notes columns.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "an [ORCHESTRATOR] item exists, names the decision, states it blocks code edits, and precedes dependent tasks; checklist.md has the three FORM sections in the right shape",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 5,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "spec.md is stamped Tier: S. A prior draft left actions/ with only a .gitkeep. Write the plan and its actions.",
-      "expected_output": "Writes at least one real actions/ACTION_1.md (non-empty, not the placeholder sentinel, not a .gitkeep) that consolidates the whole S-tier delivery. Leaving actions/ empty or .gitkeep-only is a plan failure that would block the How gate; the planner never does this at any tier.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "actions/ contains at least one real action file (non-empty *.md, first line not the placeholder sentinel); no .gitkeep-only or empty actions/ dir remains",
-          "result": "expect-pass"
-        }
-      ]
-    }
-  ]
-}