@zalom/plastic 2.0.0-alpha.21 → 2.0.0-alpha.22

package/skills/intent-creating/SKILL.md

@@ -6,110 +6,51 @@ user-invocable: true
 
 # Creating an Intent
 
-## When to Use
+Creating writes the thought to disk: an id, a directory, a born-complete intent file.
+Nothing else runs here; specifying, planning, and execution are separate, later skills.
+
+## When to use
 - User starts new work ("build X", "fix Y", "research Z")
 - No active intent matches the current task
 - User explicitly says "new intent" or "create intent"
 - An agent discovers work needed during implementation
 
-## Determine the store
-
-**Global intent** (strategic): created when working outside a registered project, or when the user expresses a high-level goal. Stored in `~/.plastic/store/`.
-
-**Project intent** (tactical): created when working inside a registered project directory. Stored in `~/.plastic/projects/{slug}/store/`. Automatically linked to the project's governing intent.
-
-### Detection logic:
-1. Read `~/.plastic/projects.yml`
-2. **CWD match:** Match CWD against registered project paths
-   - If CWD is inside a registered project → **project intent (tactical)**
-3. **Explicit mention:** User mentions an existing project by name ("add this to reddit-kb", "new intent for plastic")
-   - Look up project in `projects.yml` by slug
-   - If found → **project intent (tactical)** in that project's store at `~/.plastic/projects/{slug}/store/`
-   - Agent changes working directory to the project path for execution
-4. **No match:** CWD is not in a project AND no project mentioned
-   - → **global intent (strategic)** in `~/.plastic/store/`
-
-When creating a tactical intent in a project store:
-- Read the project's `AGENTS.md` for project context and decisions
-- Link back to the project's governing intent (from `projects.yml` `parent` field) via `sources` (the project genuinely is formed from its founding intent, a true formative edge, reciprocated on the founding intent's `chain`)
-- Add `[[global:<parent_ID>]]` backlink in `## Links`
-- The intent's Folgezettel ID is scoped to the project store (run `folgezettel-id` against the project's store at `~/.plastic/projects/{slug}/store/`)
-
-## Workflow
+## Decide the store and the shape, before scaffolding
+
+- **CWD inside a registered project** (`~/.plastic/projects.yml`), or the user names a
+  project by slug -> **project intent (tactical)**, `~/.plastic/projects/{slug}/store/`,
+  linked back to the project's governing intent (`projects.yml` `parent` field) via
+  `sources`, with `[[global:<parent_ID>]]` in `## Links` and a Folgezettel id scoped to
+  that store.
+- **No match** -> **global intent (strategic)**, `~/.plastic/store/`.
+- **Duplicate or predecessor check (QMD-first):** before allocating an id, run
+  `ruby ~/.plastic/scripts/qmd-sync search "<terms>"` (a no-op when QMD is absent, fall
+  back to INDEX.md) so a near-duplicate is reused and a true predecessor lands in
+  `--sources`.
+- **Branch vs root**, decided by meaning, not by "a parent in mind": branch
+  (`--parent <parent_id>`) when the intent only makes sense as part of the parent's work;
+  root with `--sources <ascendant_id>` when it was created from another intent's
+  lifecycle; root with no `--sources` when it is merely related (record that relation on
+  the PREDECESSOR's `chain` instead - topic similarity alone is never a `sources` edge).
 
-### 1. Determine Store Location
-
-- **Global:** `~/.plastic/store/`
-- **Project:** `~/.plastic/projects/{slug}/store/`
-
-### 2. Check for a Duplicate or Predecessor (QMD-first)
-
-QMD-first (when available): before scanning the store with grep/Read, run
-`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` to surface candidate, prior, or duplicate
-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. Do this before allocating
-the id so a near-duplicate can be reused and a true predecessor can be set in `--sources`.
-
-### 3. Decide Branch vs Root
+When a branch intent exists because a late ruling arrived AFTER its parent was already
+completed, the parent is restored to v1 via `scripts/restore-intent-v1`, never a hand-run
+`git checkout`/revert (see `plastic-conventions > references/maintenance-and-revisions.md`,
+WORK vs MAINTENANCE).
 
-Decide this BEFORE scaffolding, because it sets whether you pass `--parent`.
-Having a "parent" in mind does NOT automatically mean branch. Choose by meaning:
+`## Links` is a DERIVED view of `sources`/`chain`: never hand-write a `## Links` line, add
+the frontmatter edge and reproject. Links follow context influence (a `chain` edge needs
+the candidate's context to materially help deliver this intent), never shared files or a
+similarity score; `scripts/link-suggest` and `scripts/project-links` gather candidates.
+Read `../plastic-conventions/references/knowledge-graph.md` for the full linking doctrine:
+the tiers of influence, sources versus chain, and how `## Links` is derived.
 
-- **Branch (`14a`, `14b`)**: a sub-task, refinement, or direct continuation. It only
-  makes sense as part of the parent's work. Pass `--parent <parent_id>`.
-- **Root (`15`, `16`)**: an independent thought. Two cases, decided by ORIGIN:
-  - **Created from another intent** (it emerged from that intent's lifecycle): make it a
-    root and set `--sources <ascendant_id>`. `sources` is reserved for true created-from /
-    direct-ascendant provenance (D1).
-  - **Merely related to / inspired by another intent** (it did NOT come out of that
-    intent's lifecycle): carry NO `--sources`. Record the relation on the PREDECESSOR's
-    `chain` instead (the related-but-not-spawned rule); the `## Links` section follows
-    from that edge, you do not write it by hand.
-- **Rule of thumb:** if the intent could exist without its parent, make it a root; only set
-  `--sources` when it was genuinely created from / emerged from that intent's lifecycle.
-  Topic similarity alone is not a `sources` edge.
+## Scaffold
 
-When a branch intent exists because a late ruling arrived AFTER its parent was already
-completed (the owner's late-ruling rule), the parent is restored to v1 via
-`scripts/restore-intent-v1`, never by a hand-run `git checkout`/revert. See
-`plastic-conventions > references/maintenance-and-revisions.md`, WORK vs MAINTENANCE, for the
-rule and the tool.
-
-`## Links` is a DERIVED view of `sources`/`chain`. Never hand-write a `## Links` line; add the
-frontmatter edge and reproject. Links are decided by context influence (a `chain` edge has a high
-bar: the candidate's context must materially help deliver this intent), not by shared files or a
-similarity score. To gather candidates with their context and record an edge, use the
-`scripts/link-suggest` and `scripts/project-links`.
-
-Read `../plastic-conventions/references/knowledge-graph.md` for the full linking doctrine: the
-tiers of influence, sources versus chain, and how the `## Links` projection is derived. This path
-resolves relative to this skill's own installed directory.
-
-### 4. Determine Intent Properties
-
-Ask or infer from context:
-- **intent**: one-line description
-- **slug**: short hyphenated handle for the directory name
-- **author**: `human` | `claude-code` | other agent name
-- **sources**: the direct ascendant(s) this intent was created from / emerged from the
-  lifecycle of (formation, not topic similarity), e.g., `4a1`. For a project intent,
-  include the governing intent's id. A branch's structural parent is ALSO recorded in
-  `sources` (the ID carries it for the human/paper tree, `sources` carries it for
-  software), which `new-intent` does automatically (see `new-intent:126`).
-- **tags**: freeform list (use `project-<name>` for project membership)
-
-`chain` carries what this intent spawns AND related-but-not-spawned successors it leads to;
-it starts empty and is populated later. See
-[`how-plastic-sources-and-chains-intents.md`](https://github.com/zalom/plastic/blob/main/docs/concepts/how-plastic-sources-and-chains-intents.md) for the full model.
-Place the intent in `## Active` or `## Future` in INDEX.md (status is
-convention-derived, not a frontmatter field).
-
-### 5. Scaffold via new-intent (single call)
-
-Delegate id allocation, directory and file creation, the born-complete intent
-file, the sentinel placeholder lifecycle files, the reciprocal file links, and
-self-validation to one `new-intent` invocation. Do NOT hand-author any of these
-files.
+One call does the rest: id allocation, the directory, `actions/` and `resources/`, the
+born-complete intent file, sentinel placeholder lifecycle files (each marked
+`<!-- plastic:placeholder -->` so no stage detector reads them as reached), reciprocal
+`[[id]]` links, and self-validation. Do NOT hand-author any of these files.
 
 ```bash
 ruby ~/.plastic/scripts/new-intent \
@@ -118,47 +59,31 @@ ruby ~/.plastic/scripts/new-intent \
   [--sources "id,id"] [--tags "project-<slug>,tag"]
 ```
 
-`new-intent` allocates the Folgezettel id (root, or a branch of `--parent`),
-creates `<STORE>/<id>--<slug>/` plus `actions/` and `resources/`, renders the
-born-complete `<id>--<slug>.md` from the intent template, writes the sentinel
-placeholder `spec.md`/`plan.md`/`checklist.md`/`outcome.md` (each marked
-`<!-- plastic:placeholder -->` so no stage detector reads them as reached), wires
-the reciprocal `[[id]]` links, and self-validates (frontmatter plus the sanctioned
-`##` sections). It prints the created directory path and exits 0.
-
-It does NOT touch INDEX.md, git, or project creation: those stay in this skill
-(steps 6 to 9 below).
-
-If `new-intent` exits non-zero, read the stderr report and fix the inputs (slug,
-intent, sources). Do not commit or announce an intent that did not scaffold
-cleanly, and do not work around the failure by hand-writing the files.
-
-### 6. If Implementation Intent Spawns a Project
-
-When the user says "start building" or the plan calls for a new project, invoke the
-`plastic-project-creating` skill; it owns project directory creation, AGENTS.md
-population, projects.yml registration, store provisioning, and the auto-commit of
-both stores. Add `project-<slug>` to this intent's `tags` array either before
-invoking it or as part of that skill's handoff.
-
-### 7. Update INDEX.md
+It does NOT touch INDEX.md, git, or project creation (Finish, below). If it exits
+non-zero, read the stderr report, fix the inputs (slug, intent, sources), and retry;
+never work around a failed scaffold by hand-writing the files.
 
-- **Global intents:** update `~/.plastic/INDEX.md`
-- **Project intents:** no global INDEX.md change (tactical intents are project-scoped)
-
-Add to `## Active` (or `## Future`) and appropriate cluster.
-
-### 8. Auto-commit
-
-```bash
-cd <store-root> && git add . && git commit -m "feat: create intent ID - [name]"
-```
+`chain` carries what this intent spawns AND related-but-not-spawned successors it leads
+to; it starts empty and is populated later. See
+[`how-plastic-sources-and-chains-intents.md`](https://github.com/zalom/plastic/blob/main/docs/concepts/how-plastic-sources-and-chains-intents.md)
+for the full model.
 
-### 9. Announce
+## Finish
 
-"Created intent ID - [name]. Placed in: [Active|Future]. Store: [global|project:<slug>|local]."
+1. **Global intent:** add a line to `~/.plastic/INDEX.md` under `## Active` (or
+   `## Future`) and the right cluster. **Project intent:** no global INDEX.md change.
+2. When the user says "start building" or the plan calls for a new project, invoke
+   `plastic-project-creating`; it owns project directory creation, AGENTS.md population,
+   `projects.yml` registration, store provisioning, and the auto-commit of both stores.
+   Add `project-<slug>` to this intent's `tags` either before invoking it or as part of
+   that skill's handoff.
+3. Commit: `cd <store-root> && git add . && git commit -m "feat: create intent ID - [name]"`.
+4. Announce: "Created intent ID - [name]. Placed in: [Active|Future]. Store:
+   [global|project:<slug>]."
 
 ## References
 
-- Read `references/lifecycle.md` for the full What→Why→How→Exec stage detail, filesystem-as-schema conventions, and creating-intent step-by-step
-- Read `references/wikilinks.md` for the wikilink syntax table when adding `## Links` to intents
+- Read `references/lifecycle.md` for the full What->Why->How->Exec stage detail and the
+  filesystem-as-schema conventions.
+- Read `references/wikilinks.md` for the wikilink syntax table when hand-checking a
+  `## Links` projection.

package/skills/intent-ending/SKILL.md

@@ -1,9 +1,11 @@
 ---
 name: plastic-intent-ending
 description: >
-  Wrap, finish, close, or mark an intent Done, delivered or abandoned. Use
-  when completing or abandoning an intent, when a checklist reaches 100
-  percent and Exec is finished, or when asked to "wrap this up".
+  Wrap, finish, or close an intent as delivered or abandoned. Use
+  when completing or abandoning an intent, when a graph's last node
+  reaches a terminal status (or, for a legacy intent, a checklist
+  reaches 100 percent) and Exec is finished, or when asked to "wrap
+  this up".
 user-invocable: true
 ---
 
@@ -26,7 +28,7 @@ installed directory.
 | 0 | Precondition check | You, before touching outcome.md |
 | 1 | backfill spec/plan/action/outcome from the record, self-check, intent-file `## Outcome` summary | `scripts/end-intent` |
 | 2 | INDEX.md terminal move (Active -> Completed/Abandoned) | `scripts/end-intent` |
-| 3 | savepoint `Done` bookend | `scripts/end-intent` |
+| 3 | the terminal savepoint line | `scripts/end-intent` |
 | 4 | store auto-commit | `scripts/end-intent` |
 | 5 | disarm (worktree + lock) | `scripts/end-intent` (intent 188) |
 | 6 | QMD reindex, async, LAST | You |
@@ -45,50 +47,47 @@ Nothing refuses the close any more (the 1.x write-time gate and `end-intent`'s
 exit-6 structure gate were retired in 2.0, intents 302 and 308). What you leave
 on disk is what the record becomes, so before the call:
 
-1. Read checklist.md. Tick every item as it is actually performed, including
-   an item that describes the close itself: running this very procedure IS
-   what that item describes. An unchecked box is not a refusal, it is a
-   reported gap that lands verbatim in the backfilled `## Follow-ups`.
-2. Confirm every acceptance criterion in spec.md is verifiable (tests pass,
-   or the manual check described in its HOW line was actually run).
-3. Decide what you have to say. For an intent with a `graph.md`, `outcome.md` is
-   GENERATED by `scripts/end-intent` itself, through `scripts/lib/outcome_report.rb`
-   (`scripts/outcome-report` is its standalone CLI, useful for checking the
-   generated text before the close): `## Delivered`, `## Verification`,
-   `## Graph diff`, and `## Findings` are read straight from `graph.md`, `nodes/`,
-   and the ledger every time, never hand-typed. `## Summary`, `## Needs you`, and
-   `## Follow-ups`, and every frontmatter key but `disposition`, are preserved
-   byte for byte when you author them and generated as plain facts otherwise, so
-   writing a summary yourself still works exactly as before. For an intent with
-   no `graph.md`, or when the generated text would be refused by the close's own
-   gates, a spec.md, plan.md, action file, or outcome.md left as the scaffold
-   placeholder is written from the record by `scripts/end-intent` (the intent
-   file's `## Intent`, `### Decisions`, and `## Insights`, the checklist, the
-   diff on the intent's own worktree). A file you wrote, even under a
-   still-present sentinel, is never touched.
+1. For an intent with a `graph.md`: confirm every node's Status in `graph.md` is
+   terminal (`done` or `failed_verification`, nothing left `running`, `blocked`, or
+   waiting `needs_decision`), and that the last verify node's gates were
+   accepted. A node still open is not a refusal, it is a reported gap that lands
+   verbatim in the backfilled `## Follow-ups`.
+   For an intent with no `graph.md` (legacy): read checklist.md, tick every item as
+   it is actually performed, including an item that describes the close itself:
+   running this very procedure IS what that item describes; an unchecked box is not
+   a refusal, it is a reported gap. Also confirm every acceptance criterion in
+   spec.md is verifiable (tests pass, or the manual check described in its HOW line
+   was actually run).
+2. Decide what you have to say. For an intent with a `graph.md`, never hand-write
+   `outcome.md`: `scripts/end-intent` GENERATES it, through
+   `scripts/lib/outcome_report.rb` (`scripts/outcome-report` is its standalone
+   CLI, useful for checking the generated text before the close). `## Delivered`,
+   `## Verification`, `## Graph diff`, and `## Findings` are read straight from
+   `graph.md`, `nodes/`, and the ledger every time, in plain wording a reader
+   recognizes, never hand-typed; when the generated wording is wrong, fix
+   `graph.md` or `nodes/`, the source it reads from, not the report. `## Summary`,
+   `## Needs you`, and `## Follow-ups`, and every frontmatter key but
+   `disposition`, are preserved byte for byte when you author them and
+   generated as plain facts otherwise. For an intent with no `graph.md`, a
+   spec.md, plan.md, action file, or outcome.md left as the scaffold placeholder
+   is written from the record by `scripts/end-intent` (the intent file's
+   `## Intent`, `### Decisions`, and `## Insights`, the checklist, the worktree
+   diff). A file you wrote, even under a still-present sentinel, is never touched.
 
 ### Step 1-5. Run `scripts/end-intent`
 
-Author outcome.md yourself when the summary deserves more prose than the generator's
-plain facts: copy `templates/outcome.md`, set the frontmatter to `disposition: delivered`
-or `disposition: abandoned`, and fill `## Summary`, `## Delivered`, `## Verification`,
-`## Follow-ups`. `## Delivered` is a `| Row | What |` table: one row per thing delivered,
-in plain wording a reader recognizes, not a method name or an implementation summary
-(that detail belongs in `## Summary`). Each row's label must appear as a standalone token
-in an action-file heading (or a node-file heading, for an intent whose graph replaces
-actions/ with nodes/) that owns the matrix table (`### S1 - ...` or
-`## n1 failure-mode matrix` with a table beneath it proves that row; a table-less
-heading naming the label is skipped); that heading's matrix rows become the row's
-Proven-by cell on `report-screen delivered`'s post-delivery screen. `## Needs you` is
-the literal None or a `| N | What | Why |` table. On abandon, `## Summary` states the
-abandonment reason and the trail (see Pivot below). An intent with a `graph.md` and no
-hand-written outcome.md gets one generated instead (Step 0.3 above); a placeholder
-outcome.md on an intent with no `graph.md` is backfilled from the record, with the
-close's disposition and the `--outcome-summary` line as its summary. Also author
-the rich INDEX entry note now (a short line in the store's existing
-Completed/Abandoned convention: mode, what shipped or why it was
-abandoned, suite result, merge/spawn notes); content authoring stays with
-you, `--index-note` only appends what you write.
+For an intent with a `graph.md`, do not author `outcome.md` by hand: run
+`ruby ~/.plastic/scripts/outcome-report <intent_dir> --write --disposition delivered|abandoned`
+if you want to see the generated text before the close, or let the single call below write it.
+`## Summary`, `## Needs you`, and `## Follow-ups` are the sections worth your own words; edit
+those into the file before the call when the generator's plain facts say too little (they are
+preserved byte for byte). `## Needs you` is the literal None or a `| N | What | Why |` table.
+On abandon, `## Summary` states the abandonment reason and the trail (see Pivot below). An
+intent with no `graph.md` gets a placeholder outcome.md backfilled from the record instead,
+with the close's disposition and the `--outcome-summary` line as its summary. Also author the
+rich INDEX entry note now (a short line in the store's existing Completed/Abandoned
+convention: mode, what shipped or why it was abandoned, suite result, merge/spawn notes);
+content authoring stays with you, `--index-note` only appends what you write.
 
 Then call the script once:
 
@@ -110,23 +109,16 @@ line from `## Active` to `## Completed` or `## Abandoned` (dated today,
 idempotent, accepting either a real em dash or a plain hyphen as the id/
 title separator on read while always emitting the real em dash on write)
 with the `--index-note` text appended after the date so the entry stays
-rich, appends the savepoint `Done` bookend, commits the store repo, and
+rich, appends the terminal savepoint line, commits the store repo, and
 disarms (releases the code worktree and clears `delivery.lock`, verified
 against the durable lock file on disk, never merely trusted). Omit
 `--index-note` for a thin id+date entry, add `--no-commit` when a separate
 commit step already covers the store (this never skips disarm), and
 `--dry-run` to preview steps 1-5 with no writes.
 
-A pre-flight lock guard runs before anything is written: it resolves the
-calling session (`--session`, else `CLAUDE_CODE_SESSION_ID`, else the
-existing lock's own recorded owner, else a no-op) and checks it against any
-existing `delivery.lock`. A live foreign session refuses the whole run
-(exit 4, nothing written); a stale foreign lock is reclaimed automatically
-(audited to savepoint.md) and the run proceeds as the new owner. Before
-removing the worktree, step 5 also refuses on an unexpectedly dirty code
-worktree (exit 5, naming the worktree path) rather than force-discarding
-uncommitted changes; pass `--discard-worktree-changes` only when you mean
-to override that deliberately.
+Read `../plastic-conventions/references/completion-and-done.md` for the pre-flight lock guard
+and the dirty-worktree refusal this call runs before writing anything (exit 4 and exit 5
+below); this procedure only calls `end-intent`, it never re-implements them.
 
 On the auto mode / curator path (no release), this single call performs the
 FULL disarm (plain worktree remove, since the branch survives for later

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

@@ -19,7 +19,7 @@
       "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).",
+      "expected_output": "The terminal savepoint line 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" },

package/skills/intent-executing/SKILL.md

@@ -1,116 +1,61 @@
 ---
 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.
+description: Use when you have a graph or a plan to execute. A graph delivery runs on
+  `scripts/runner`'s three verbs, `step`, `status`, and `answer`; older, non-graph work
+  dispatches the `plastic-executor` agent for one consolidated action.
 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:
+Before touching any file the graph or the plan names, sync the code worktree with main 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.
+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 before
+touching the worktree above.
 
-**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
+## step
 
-### 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.
+`ruby scripts/runner step <intent_dir>` computes which nodes in `graph.md`/`nodes/*.md` are
+ready, applies dispatch policy (model, call cap), and prints a spawn block per dispatched node
+- agent, model, packet path, the one test command, the call cap - fenced in its own stdout.
+The runner itself never spawns an agent (327 D42). Call `step` again after each dispatched
+node returns.
 
 ### Graph dispatch: the paste
 
-When the plan is a graph (`nodes/*.md`, not `plan.md` plus action files), the dispatch step is the paste, not a lead's hand-typed brief. `runner step` computes readiness, applies policy, and prints a spawn block per dispatched node - agent, model, packet path, the one test command, the call cap - fenced in its own stdout. Copy each block into the Agent tool as its own dispatch, verbatim; the runner itself never spawns an agent (327 D42).
-
-### 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.
-
-Print `ruby ~/.plastic/scripts/report-screen state <intent_dir> --changed "<what just landed>"` as the first characters of the reply, nothing before it, no fence, right after the red commit and again once the suite goes green (intent 331f).
-
-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 dispatch step is the paste, not a lead's hand-typed brief: copy each spawn block into the
+Agent tool as its own dispatch, verbatim.
 
-**The D19 heading convention.** An action file's `## Delivered` row (in `outcome.md`) is proven by the first `actions/ACTION_N.md` OR `nodes/*.md` heading that carries that row's label as a standalone token AND owns the matrix table (322 D1r, 334 D10r) - `### Row A -` with a table beneath it proves row A, `### S1 -` proves row S1, `## n1 failure-mode matrix` proves row n1; a heading that only names the label, with no table under it, is skipped. Readers check `actions/` first, then `nodes/` (334 D15r). Write action-file or node-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 owns a matching table and no matrix row cell carries the label either.
+## status
 
-### Step 4: Update Intent and Complete
-Capture observations in `## Insights`. When ALL checklist items are checked:
+`ruby scripts/runner status <intent_dir>` renders the graph's ledger state: which nodes are
+running, done, blocked, or waiting on a decision. Safe to poll constantly; read node status
+through `NodeLedger.status` before dispatching anything, never re-derive it by eye.
 
-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.
+## answer
 
-**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.
+`ruby scripts/runner answer <intent_dir> --node <id> --decision "<text>"` closes a
+`needs_decision` node with the owner's ruling, recorded to the ledger, so `step` can resume
+the graph past it.
 
-## Inline Workflow
+## Non-graph work
 
-### 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.
+When the intent has no `graph.md`, dispatch ONE `plastic-executor` subagent with the whole
+consolidated action pasted in (never a file reference): every task's full text, every action
+file with its failure-mode matrix, the checklist items it must tick, the project context, and
+the worktree path. It 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. Read its response by code: DONE or DONE_WITH_CONCERNS proceeds;
+NEEDS_CONTEXT provides the missing context and re-dispatches; BLOCKED stops and reports.
 
 ## Tick-as-you-land
 
@@ -124,57 +69,13 @@ progress. 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.
+- **Before:** the graph (`graph.md`, `nodes/*.md`), or `plan.md`/`checklist.md`, exists; the
+  worktree is armed.
+- **Produces:** code changes and a ticked checklist.
+- **Next:** `plastic-intent-ending` owns `outcome.md`, generated through
+  `scripts/outcome-report`, and the rest of the mechanical close.
 
 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-speccing/SKILL.md

@@ -14,6 +14,9 @@ user-invocable: true
 
 # Intent Speccing: thinking mode
 
+Speccing is optional: a ruled or small-enough intent skips straight to How/Exec, and this
+skill runs only when the request genuinely needs a design conversation first.
+
 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