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

package/skills/auto/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: plastic-auto
 description: >-
-  Autonomous intent delivery - a background team takes a registered intent from How to Done.
+  Autonomous intent delivery - a background team takes a registered intent from How to End.
   Use when user says "auto", "take it from here", "deliver this", or when a thinking
   conversation concludes and the user confirms autonomous execution. Requires an active intent
   in INDEX.md.
@@ -13,20 +13,18 @@ user-invocable: true
 Announce: "Taking over intent [ID] - [name] for autonomous delivery."
 
 **Advisory (not a rule).** At auto-mode start, recommend once that the user run this
-orchestrating main session on the best available thinking model (Fable, Opus, or whatever
-supersedes them). This is advice only: it changes no behavior. Dispatched agents keep their
-configured model and never resolve to Fable unless an explicit `agents.models.<name>` config
-override names Fable for that role. The two advisors, `plastic-advisor` and
-`plastic-faux-advisor`, are consultation roles the user or the main session summons
-deliberately; the auto pipeline never dispatches them.
+orchestrating session on the best available thinking model (Fable, Opus, or whatever supersedes
+them); this is advice only, and dispatched agents keep their configured model, never resolving
+to Fable without an explicit `agents.models.<name>` config override. `plastic-advisor` and
+`plastic-faux-advisor` are consultation roles the user or this session summons deliberately;
+the auto pipeline never dispatches them.
 
 ## Precondition
 
 An active intent MUST exist in INDEX.md. If none exists, refuse: "No active intent found.
 Create one first with /plastic-intent-creating."
 
-If several active intents exist, ask the user which one to deliver (the one question auto asks
-at boarding, before delivery starts).
+If several active intents exist, ask which to deliver (the one question auto asks at boarding).
 
 **Picking work when no intent is specified.** If the user says "auto" without naming an intent
 and none is active, consult the roadmap first (the primary planning surface), then fall back to
@@ -42,9 +40,8 @@ frontier batch is still delivering, report it and wait, never dispatch a later b
 `exhausted` means fall back to `ruby ~/.plastic/scripts/dashboard.rb all --json` and work its
 `dispatchable_queue` in `rank` order, leaving `human_only` and `next_big_thing` for the user.
 
-QMD-first (when available): when the user describes the work rather than naming an intent, run
-`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` before scanning the store, then open the
-authoritative intent file for the hit you take over. The command is a no-op when QMD is absent.
+QMD-first (when available): when the user describes the work instead of naming an intent, run
+`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` first, then open the hit's authoritative intent file; a no-op when QMD is absent.
 
 ## Take the intent (do this FIRST)
 
@@ -74,29 +71,29 @@ owner override. Do not proceed as the owner after an exit 1.
 Read `../plastic-conventions/references/locks-and-worktrees.md` for what the lock and the
 worktree mean and the station table behind them. Code edits happen only inside the worktree.
 
-## The shape (five steps, two agent boots)
+## The shape
 
-Every auto delivery runs the same shape, ruled by the owner on 2026-08-29. There is no intent
-tier and no stage agent; depth follows the work.
+Work is a graph (`graph.md`: Goal, Decisions, Graph, Status; one `nodes/*.md` per node) or,
+for work small enough to skip speccing, delivered inline with no separate plan review. There
+is no intent tier and no stage agent; depth follows the work.
 
-| Step | Who | What lands |
-|---|---|---|
-| 1. The lead writes How | this session | `plan.md`, at least one `actions/ACTION_N.md` carrying a failure-mode matrix (one row per operation: the failure and the test that catches it), `checklist.md` |
-| 2. Adversarial plan review | boot 1, a fresh agent on `plan-reviewer-prompt.md` | a review file; the lead folds every finding into the spec, the matrix, and the tests |
-| 3. Execute, tests first | boot 2, `plastic-executor` | the red commit (the matrix's tests, failing), then the code, then a green suite |
-| 4. Review by risk | boot 3 only when risk calls for it (below) | a pass or a list of fixes the executor applies |
-| 5. One suite run, then close | this session | `outcome.md`, `end-intent`, the roadmap ledger |
+`runner step` computes readiness and prints a spawn block per dispatched node - agent, model,
+packet path, the test command, the call cap - fenced for a session to paste into the Agent
+tool; the runner never spawns (327 D42). `runner status` renders the ledger; `runner answer`
+closes a `needs_decision` node.
 
-Two boots is the normal delivery; the third is the exception the risk rule names. The lead is
-this session (the `plastic-enforcer` role), never a dispatched agent.
+A lead is a choice, not a requirement (D8, 355). A lead earns its keep on a graph carrying a
+decision node, weighing its `needs_decision` stop; a graph with none runs end to end from
+`runner step` alone. When this session leads, it is the `plastic-enforcer` role, never a
+dispatched agent.
 
 ## Team
 
-- **plastic-enforcer**: this session. Writes the Why and How record, dispatches, folds reviews,
-  verifies, closes.
+- **plastic-enforcer**: this session. Writes the Why and How record, dispatches, applies
+  review findings, verifies, closes.
 - **plastic-executor**: one dispatch per intent, implements the consolidated action tests first,
   ticks the checklist, appends `## Insights`, drives the suite green.
-- **the plan reviewer**: one dispatch before code, from `plastic-intent-executing`'s
+- **the plan reviewer**: an optional dispatch before code, from `plastic-intent-executing`'s
   `plan-reviewer-prompt.md`; a fresh agent, never the lead.
 - **the post-execution reviewer**: dispatched only by the risk rule, from
   `code-quality-reviewer-prompt.md`; a fresh agent, never the maker.
@@ -148,12 +145,11 @@ each one as a delegate before (or when) it needs to write into the intent dir:
 
 Only the owner can delegate. Delegates cannot re-delegate or release.
 
-Headless note: in a headless or background run the session id may be unset; the arm verb then
-keys the lock by a derived key and the record hook still writes the savepoint ledger from the
-written path. Verify the lock with `plastic-lock status` rather than assuming.
+Headless note: in a headless or background run the session id may be unset; the arm verb then keys the lock by a derived key and the record hook still writes the ledger.
+Verify with `plastic-lock status` rather than assuming.
 
 Solo fallback: on a harness with no agent dispatch (Codex CLI today), this session walks the
-five steps itself: it still writes the matrix, still writes the tests first, and reviews its own
+graph (or the plan) itself, still writing the matrix and the tests first and reviewing its own
 plan against the matrix before code, saying so in `## Insights`.
 
 ## Stage-Aware Entry
@@ -168,7 +164,7 @@ ledger is missing (then rebuild it with `Savepoint.rebuild_savepoint`).
 | `Why  spec.md created` | How |
 | `How  plan.md created` / `How  checklist.md created` / `Exec  started` | Exec (verify plan, matrix, checklist) |
 | `Exec  outcome.md created` | Exec done; complete the intent |
-| `Done  delivered|abandoned` | Terminal; do not resume |
+| A terminal savepoint line (`delivered` or `abandoned`) | Terminal; do not resume |
 | A node or `Intent` transition line (`n1  running ...`, `Intent  needs_decision ...`) | Exec; a graph delivery is in progress - drive it through `scripts/runner`'s three public verbs, `step` (one turn of the dispatch loop), `status` (renders ledger state, safe to poll constantly), and `answer` (closes a `needs_decision` node) - read node status through `NodeLedger.status` before dispatching anything, never re-derive it by eye |
 
 Filesystem fallback, in order: `checklist.md` with items checked means resume Exec from the
@@ -179,42 +175,43 @@ Announce which stage you are entering and why.
 
 ## Why (the lead)
 
-1. Read `## Context` and `### Decisions`; assess the gaps.
-2. Research yourself: code, docs, related intents through `## Links`, the web if needed. No
-   questions to the human.
-3. Decide: pick the best option per gap, record it in `## Context > ### Decisions` with the
-   rationale, and log it in `## Insights` with the `(autonomous)` marker through
-   `scripts/insight-append`.
-4. Write `spec.md`. Then How.
+For a graph delivery, Why is already written into `graph.md`'s Goal and Decisions; nothing
+else to do here. For work with no graph: read `## Context` and `### Decisions`, assess the
+gaps, research them yourself (code, docs, related intents through `## Links`, the web if
+needed; no questions to the human), record each decision in `## Context > ### Decisions` with
+its rationale, log it in `## Insights` with the `(autonomous)` marker through
+`scripts/insight-append`, and write `spec.md` only when the intent needs one (speccing is
+optional). Then How.
 
 ## How (the lead), then the plan review
 
-1. Write `plan.md`: numbered steps.
-2. Write at least one real `actions/ACTION_N.md` (one consolidated `ACTION_1.md` by default;
-   several only when the work splits into independent, parallel-safe actions). Each action
-   carries the failure-mode matrix: one row per operation, the failure mode, and the test that
-   catches it. A `.gitkeep`-only `actions/` is not a finished How.
-3. Write `checklist.md` covering every action.
-4. Dispatch the plan reviewer (boot 1) with `plastic-intent-executing`'s
-   `plan-reviewer-prompt.md`, the spawn preamble, and the intent directory. Fold every finding
-   into the spec, the matrix, and the tests; record what was dropped and why in the action
-   file's review fold. A REVISE verdict is folded and not re-reviewed unless a finding changes
-   a decision.
-5. Print `ruby ~/.plastic/scripts/report-screen plan <intent_dir>` as the first characters of
-   the reply, nothing before it, no fence, before dispatching the executor (see
-   `references/human-report-contract.md` for the full binding table). It informs; it does not wait.
+For a graph delivery, How is `graph.md` itself: no `plan.md`, no separate plan review (D1,
+341). For work with no graph: write `plan.md` (numbered steps) and at least one real
+`actions/ACTION_N.md` carrying the failure-mode matrix (one row per operation, the failure
+mode, the test that catches it; a `.gitkeep`-only `actions/` is not a finished How), then
+`checklist.md` covering every action. The plan reviewer is optional, not a required step:
+when the delivery warrants review before code, dispatch it (boot 1) with
+`plastic-intent-executing`'s `plan-reviewer-prompt.md`, the spawn preamble, and the intent
+directory, apply every finding to the spec, the matrix, and the tests, and record what was
+dropped and why in the action file's review notes. A REVISE verdict is applied and not
+re-reviewed unless a finding changes a decision.
+
+Print `ruby ~/.plastic/scripts/report-screen plan <intent_dir>` as the first characters of
+the reply, nothing before it, no fence, before dispatching the executor (see
+`references/human-report-contract.md` for the full binding table). It informs; it does not wait.
 
 Then Exec.
 
 ## Exec (the executor)
 
-1. Dispatch `plastic-executor` (boot 2) through `plastic-intent-executing` with the whole
-   consolidated action pasted in: the spec decisions, the matrix, the checklist items, the
-   worktree path from the preamble. Tests first: the executor commits the matrix's tests red,
-   then builds, then drives the full suite green.
-2. Read its return by code: DONE or DONE_WITH_CONCERNS proceeds; NEEDS_CONTEXT re-dispatches
-   with the missing context; BLOCKED stops under the error procedure.
-3. Tick the checklist as items land (the executor does this); verify tick-versus-diff against the diff. A mismatch is a review finding, not a lead cleanup.
+For a graph delivery, `runner step` prints the spawn block for the next ready node; paste it
+into the Agent tool, verbatim. For work with no graph, dispatch `plastic-executor` (boot 2)
+through `plastic-intent-executing` with the whole consolidated action pasted in.
+
+1. Read the executor's return by code: DONE or DONE_WITH_CONCERNS proceeds; NEEDS_CONTEXT
+   re-dispatches with the missing context; BLOCKED stops under the error procedure.
+2. Tick the checklist as items land (the executor does this); verify tick-versus-diff against
+   the diff. A mismatch is a review finding, not a lead cleanup.
 
 ## Review by risk (boot 3, only when a rule fires)
 
@@ -224,13 +221,14 @@ holds, each checkable from disk with no judgment; otherwise the green suite is t
 1. `git diff --name-only <red-commit>..HEAD` touches a path on the risk list in
    `references/agent-architecture.md` (hooks, the lock, the arming module, the installer, a
    release file).
-2. A row of any `actions/ACTION_N.md` failure-mode matrix names a test file that is not in that
-   diff, or a test the green run did not execute.
+2. A row of any failure-mode matrix (an `actions/ACTION_N.md` or a `nodes/*.md` file) names a
+   test file that is not in that diff, or a test the green run did not execute.
 3. The executor's completion report carries a status other than `delivered`, or a non-empty
    `deviations` or `blockers` field.
 
 The reviewer returns a pass or a list of fixes; the executor (re-dispatched) applies them, then
-the suite runs once more.
+the suite runs once more. On a graph, the risk rule maps onto the verify nodes named in
+`graph.md`'s decisions; at most one review-fix round, never more.
 ## Project Creation
 
 If the plan calls for creating a new project, determine the path from `~/.plastic/config.yml`

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

@@ -29,12 +29,13 @@ in 2.0, intent 304; the lead writes the Why and How record itself):
 - **plastic-executor** (Exec): commits the matrix's tests red, writes the code, checks off
   `checklist.md`, appends `## Insights`, and drives the suite green.
 - **the plan reviewer**: a fresh agent on `plastic-intent-executing`'s
-  `plan-reviewer-prompt.md`, dispatched once before any code exists.
+  `plan-reviewer-prompt.md`, an optional dispatch before any code exists.
 - **the post-execution reviewer**: a fresh agent on `code-quality-reviewer-prompt.md`,
   dispatched only when the auto skill's risk rule fires; never the maker.
 
-Two agent boots is the normal delivery (the plan reviewer, the executor); the post-execution
-reviewer is the third only when risk calls for it.
+One agent boot (the executor) is the minimum delivery; the plan reviewer is a second,
+optional boot when the lead calls for review before code, and the post-execution reviewer is
+a third only when risk calls for it.
 
 ### Handoff Contracts
 
@@ -44,8 +45,8 @@ the code, the red and green commits, a checked-off checklist, `## Insights`, and
 report. Dispatch is sequential on a single branch, because the deliverables share files.
 
 The chain: intent `## Intent` / `## Context`, then enriched `## Context` plus `### Decisions`,
-then `spec.md`, then `plan.md` plus `actions/` plus `checklist.md`, then the plan review, then
-the code changes plus a checked-off checklist plus `## Insights`.
+then `spec.md`, then `plan.md` plus `actions/` plus `checklist.md`, then an optional plan
+review, then the code changes plus a checked-off checklist plus `## Insights`.
 
 ### Spawn Preamble (L2 live-state injection)
 
@@ -88,9 +89,10 @@ not revoke the registered delegate's authorization.
 
 ### Review Ownership
 
-The lead owns every review decision: it dispatches the plan reviewer before code, folds the
-findings itself, and decides from the risk rule whether the post-execution reviewer runs. It
-never delegates that decision, and neither reviewer is ever the maker of what it reviews.
+The lead owns every review decision: it dispatches the plan reviewer before code when one
+runs, takes the review into its own record, and decides from the risk rule whether the
+post-execution reviewer runs. It never delegates that decision, and neither reviewer is ever
+the maker of what it reviews.
 Nothing blocks a write in 2.0 (the gate hooks were removed, intent 302); the lock, the
 worktree, and the record are how the team keeps one delivery in one place.
 

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

@@ -78,7 +78,7 @@ an executor's intermediate commit, or an agent going idle is NOT one of them:
 
 | Trigger | Scope |
 |---|---|
-| A savepoint line lands (a stage boundary: Why, How, Exec started, outcome written, Done) | that intent |
+| A savepoint line lands (a stage boundary: Why, How, Exec started, outcome written, End) | that intent |
 | A review verdict returns (plan review or post-execution review), naming what it changed | that intent |
 | A blocker or needs-input is logged | that intent |
 | A merge or a release lands | that intent |

package/skills/conventions/references/completion-and-done.md

@@ -1,16 +1,16 @@
-# Completion and Done
+# Completion and the End Tail
 
 This chapter holds what "intent done" means and the End-stage tail.
 
 #### What "intent done" means (intent 93)
 
-Done is one law with three signals, and they must agree. INDEX `## Completed` /
+Completion is one law with three signals, and they must agree. INDEX `## Completed` /
 `## Abandoned` is the single canonical terminal marker: it is the store-wide ledger a fresh
 session reads first, so it wins on any conflict. `outcome.md` is the "deliverable exists"
-signal, and the savepoint `Done delivered|abandoned` line is the audit echo. All three must
-agree; when they disagree, INDEX is authoritative and `doctor` flags the mismatch (the
+signal, and the savepoint's terminal `delivered|abandoned` line is the audit echo. All three
+must agree; when they disagree, INDEX is authoritative and `doctor` flags the mismatch (the
 `done_signals` check: `outcome.md` real but still under `## Active`, or terminal without a
-real `outcome.md`, or a terminal intent whose savepoint carries no `Done` line).
+real `outcome.md`, or a terminal intent whose savepoint carries no terminal disposition line).
 
 `outcome.md` is mandatory at every terminal transition, delivered and abandoned alike. It
 self-declares its disposition through a `disposition: delivered|abandoned` frontmatter
@@ -18,8 +18,8 @@ header. The delivered path authors it with the result; the abandoned path author
 the abandonment reason and no longer leaves the scaffolded placeholder sentinel in place.
 
 The canonical End tail runs in this order, and the QMD reindex is always LAST, after the
-purge: `outcome.md -> INDEX terminal -> savepoint Done -> commit -> disarm (Worktree.release
--> Lock.release -> purge) -> QMD reindex`. Running the reindex last keeps the index from
+purge: `outcome.md -> INDEX terminal -> the terminal savepoint line -> commit -> disarm
+(Worktree.release -> Lock.release -> purge) -> QMD reindex`. Running the reindex last keeps the index from
 ever referencing a bridge or lock that disarm is about to remove.
 
 `scripts/end-intent` performs this order's disarm step (verify the code worktree is clean,

package/skills/conventions/references/locks-and-worktrees.md

@@ -84,13 +84,13 @@ Provisioning fails open for intents that touch no project code (pure research or
 intents in the global store, or a non-git repo): those get the lock only, and the worktree
 block stays unprovisioned. The fail-open path is always logged, never silent.
 
-Cleanup is part of Done: the End tail merges the branch, then removes the worktree. Never leave
+Cleanup is part of the End tail: it merges the branch, then removes the worktree. Never leave
 an orphaned worktree behind, and clear a stale worktree reference with `git worktree prune`.
 
 
 #### Intent delivery, station by station
 
-How one auto-team intent travels from boarding to Done, and what the lock, the pointer, and
+How one auto-team intent travels from boarding to the End tail, and what the lock, the pointer, and
 the record hook do at each station. Nothing in the third column blocks; the fourth column is
 what gets written down.
 
@@ -101,7 +101,7 @@ what gets written down.
 | Why | `spec.md` | owner writes refresh the lease (lock file mtime heartbeat) | savepoint `Why started`, `Why spec.md created` |
 | How | `plan.md`, `actions/ACTION_N.md` (at least one), `checklist.md` | heartbeat on writes | savepoint `How started`, `How plan.md created`, `How checklist.md created`, `Exec started` |
 | Exec | code on the intent branch, checklist checked off | heartbeat; code edits confined to the provisioned worktree; delegates write under the owner's lock | checklist boxes; savepoint milestones; the day-ledger line promotes when a project file lands |
-| End (done) | mandatory `outcome.md` (`disposition: delivered\|abandoned`), INDEX moves to Completed or Abandoned | ordered End tail: verify, merge and remove worktrees, disarm clears `delivery.lock`, then the pointer is purge-eligible, and the QMD reindex runs LAST (after purge); `end-intent` backfills a placeholder `outcome.md` from the record and its structure check reports (never refuses) | savepoint `Done delivered` (or `abandoned`); takeover audits, if any, remain in savepoint.md |
+| End (done) | mandatory `outcome.md` (`disposition: delivered\|abandoned`), INDEX moves to Completed or Abandoned | ordered End tail: verify, merge and remove worktrees, disarm clears `delivery.lock`, then the pointer is purge-eligible, and the QMD reindex runs LAST (after purge); `end-intent` backfills a placeholder `outcome.md` from the record and its structure check reports (never refuses) | the savepoint's terminal `delivered` (or `abandoned`) line; takeover audits, if any, remain in savepoint.md |
 | Maintenance (Future, Terminal, or Active-with-a-stale-or-no-lock) | `revisions.md` move-and-record entries | detects (never acquires) `delivery.lock`; defers and reports while the target's lock is FRESH (`Lock.fresh?`); a stale or absent lock is not-active, maintenance proceeds | append-only, rule-tagged `revisions.md` entry written in the same operation as the change, or the change is refused; lands via a fresh branch off store main merged back as one closed op, never `git add -A` |
 
 ## The write guard is not residue

package/skills/conventions/references/maintenance-and-revisions.md

@@ -8,7 +8,7 @@ Plastic separates two different things an earlier doctrine blurred under one wor
 "immutable." WORK is the delivered CONTENT an intent produced: the code and project files a
 delivery changed, the research it recorded, the outcome it wrote. Once the intent is terminal
 (Completed or Abandoned), that content is immutable - the only way to change it is another
-intent that continues or reverts it. Editing a Done intent's own artifacts so it looks like it
+intent that continues or reverts it. Editing a terminal intent's own artifacts so it looks like it
 delivered something different, or that parts are missing, is forbidden (the book analogy:
 never rewrite the text on the pages of an old, valuable book).
 

package/skills/doctor/report.md

@@ -18,7 +18,7 @@
        core_files         -> "Core Files"
        project_stores     -> "Project Stores"
        deprecations       -> "Deprecations"
-       done_signals       -> "Done Signals"
+       done_signals       -> "Completion Signals"
        session_ledger     -> "Session Ledger" (global store only)
   4. For each check within a category, emit one line with the status icon
      and the check message. If the check has non-empty details, list them

package/skills/intent-continuing/references/boarding-matrix.md

@@ -12,7 +12,7 @@ Classify from the last line alone, then verify only that line's artifact is real
 | `How  started` / `How  plan.md created` | (How in progress) | **How** | finish `plan.md` and `checklist.md` |
 | `How  checklist.md created` / `Exec  started` | How | **Exec** | do the work, check off the checklist |
 | `Exec  outcome.md created` | Exec | **ready to complete** | the ending procedure (`plastic-intent-ending`) |
-| `Done  delivered` / `Done  abandoned` | terminal | **report only** | immutable; ask what is next |
+| A terminal savepoint line (`delivered` or `abandoned`) | terminal | **report only** | immutable; ask what is next |
 | A node or `Intent` transition line (`n1  running ...`, `Intent  needs_decision ...`) | Exec | **Exec** | a graph delivery is in progress; read node status through `NodeLedger.status`, never re-derive it by eye |
 
 ## Per-stage behaviour (what "continue" means)
@@ -24,7 +24,7 @@ Classify from the last line alone, then verify only that line's artifact is real
   The first unchecked `checklist.md` item is the next step; the newest `## Insights` entry
   supplies the context.
 - **ready to complete**: `outcome.md` is real; run the ending procedure.
-- **Done**: terminal. Report the outcome, ask what is next. Never reopen; `INDEX.md` is
+- **End**: terminal. Report the outcome, ask what is next. Never reopen; `INDEX.md` is
   authoritative.
 
 ## Notes

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.