@zalom/plastic 1.0.3 → 1.1.0

package/skills/{intent-curator → store-curating}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plastic-intent-curator
+name: plastic-store-curating
 description: |
   Use when completing or reviewing intents, reorganizing the index,
   or when the intent store needs maintenance. Examples:
@@ -28,9 +28,9 @@ Dispatches to the `plastic-intent-curator` agent for intent store maintenance.
 
 Invoke the `plastic-intent-curator` agent via the Agent tool with `subagent_type: "plastic-intent-curator"`. Pass the user's request as the prompt, including:
 
-1. **What to do** — complete intent, reorganize, triage stale, etc.
-2. **Which store** — global (`~/.plastic/`) or project (`.plastic/store/`)
-3. **Which intents** — by ID or "all active"
+1. **What to do** - complete intent, reorganize, triage stale, etc.
+2. **Which store** - global (`~/.plastic/`) or project (`.plastic/store/`)
+3. **Which intents** - by ID or "all active"
 
 The agent handles:
 - Intent lifecycle management (status transitions, Outcome sections)
@@ -39,10 +39,9 @@ The agent handles:
 - Cluster management (create, merge, rename)
 - Orphan detection
 
-When an intent reaches a terminal state — moved to Completed OR Abandoned — do these things as the closing act of the transfer, in the canonical End-tail order (see PLASTIC.md `## Delivery Isolation and the Single-Owner Lock`):
+When an intent reaches a terminal state, moved to Completed OR Abandoned, do these things:
 
 1. Author a real `outcome.md` in the intent directory from `~/.plastic/templates/outcome.md`, with the frontmatter `disposition: delivered` for a completed intent or `disposition: abandoned` for an abandoned one. `outcome.md` is MANDATORY at every terminal, delivered and abandoned alike: on abandon it records the abandonment reason and replaces the scaffolded placeholder sentinel (never leave `outcome.md` a placeholder at a terminal).
-2. Stamp the terminal savepoint bookend (intent 81), so the ledger's last line records the disposition: `ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.append_terminal_savepoint("<intent_dir>", "delivered")'` (use `"abandoned"` for an abandoned intent). Idempotent.
-3. Refresh the QMD index for the affected store LAST, after the terminal move and savepoint (no-op when QMD absent), running in the background so it never blocks: `ruby ~/.plastic/scripts/qmd-sync reindex --store <store-root> --async`.
+2. Call `plastic-intent-ending` for the terminal-transition close (INDEX move, savepoint `Done` bookend, store commit, disarm, and the QMD reindex last): `ruby ~/.plastic/scripts/end-intent --store <store> --id <id> --disposition delivered|abandoned`, then follow that skill's own disarm and reindex steps. Never restate those one-liners here.
 
 After the agent completes, report what changed.

package/skills/{intent-curator → store-curating}/evals/evals.json

@@ -1,5 +1,5 @@
 {
-  "skill_name": "plastic-intent-curator",
+  "skill_name": "plastic-store-curating",
   "notes": "Intent 66a. Spec for the QMD-first discovery step in agents/plastic-intent-curator.md (locate a specific intent before grep/find; distinct from the completion-time reindex step). Runner is intent 76; spec only.",
   "evals": [
     {

package/skills/{managing-index → store-indexing}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plastic-managing-index
+name: plastic-store-indexing
 description: Use after creating, completing, or abandoning intents, when the user says "index" or "organize", or when INDEX.md needs maintenance. Curates the INDEX.md structure note.
 user-invocable: false
 ---
@@ -7,14 +7,14 @@ user-invocable: false
 # Managing the Index
 
 ## When to Use
-- After creating a new intent (automatic — part of creating-intent workflow)
+- After creating a new intent (automatic - part of intent-creating workflow)
 - After completing or abandoning an intent
 - User says "index", "organize", or "clean up"
 - Periodic maintenance when the store grows
 
 ## INDEX.md Structure
 
-INDEX.md is a Zettelkasten main structure note — the brain's entry point. It has four sections:
+INDEX.md is a Zettelkasten main structure note - the brain's entry point. It has four sections:
 
 ### Active
 Intents currently being worked on. Max 1-2 for focus.
@@ -42,11 +42,10 @@ Topic-based groupings. Manually curated. Create a new cluster when 3+ intents sh
 ### Completed
 All completed intents with dates. Links preserved, never deleted.
 
-When you move an intent INTO Completed or Abandoned, run the closing acts of the transfer in the canonical End-tail order (see PLASTIC.md `## Delivery Isolation and the Single-Owner Lock`):
+When you move an intent INTO Completed or Abandoned, do these things:
 
 1. Author a real `outcome.md` in the intent directory from `~/.plastic/templates/outcome.md`, with the frontmatter `disposition: delivered` for a completed intent or `disposition: abandoned` for an abandoned one. `outcome.md` is MANDATORY at every terminal, delivered and abandoned alike: on abandon it records the abandonment reason and replaces the scaffolded placeholder sentinel (never leave `outcome.md` a placeholder at a terminal).
-2. Stamp the terminal savepoint bookend (intent 81), so the ledger's last line records the disposition: `ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.append_terminal_savepoint("<intent_dir>", "delivered")'` (use `"abandoned"` for an abandoned intent). Idempotent.
-3. Refresh the QMD index for that store LAST, after the terminal move and savepoint (no-op when QMD is absent), in the background so it never blocks: `ruby ~/.plastic/scripts/qmd-sync reindex --store <store-root> --async`.
+2. Call `plastic-intent-ending` for the terminal-transition close (INDEX move, savepoint `Done` bookend, store commit, disarm, and the QMD reindex last): `ruby ~/.plastic/scripts/end-intent --store <store> --id <id> --disposition delivered|abandoned`, then follow that skill's own disarm and reindex steps. Never restate those one-liners here.
 
 ## Workflow
 
@@ -76,7 +75,7 @@ When 3+ intents share tags but aren't in a cluster, suggest a new cluster headin
 ### Flag Orphans
 Intents with no links (empty `sources`, empty `chain`, no `## Links` entries, not in any cluster) should be flagged for curation.
 
-REQUIRED BACKGROUND: linking-intents (for understanding connection types and Zettelkasten theory)
+REQUIRED BACKGROUND: intent-linking (for understanding connection types and Zettelkasten theory)
 
 ## References
 

package/skills/{managing-index → store-indexing}/evals/evals.json

@@ -1,5 +1,5 @@
 {
-  "skill_name": "plastic-managing-index",
+  "skill_name": "plastic-store-indexing",
   "notes": "Intent 66a. Spec for the QMD-first step when locating a specific intent to reclassify/flag/cluster before grep/Read. Runner is intent 76; spec only.",
   "evals": [
     {

package/skills/{add-project-store → store-provisioning}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plastic-add-project-store
+name: plastic-store-provisioning
 description: >-
   Add an intent store to a project that is already registered in projects.yml
   but has no store on disk. Use when a project is registered but has no store,
@@ -13,7 +13,7 @@ user-invocable: false
 
 Provision the intent store for a project that is already registered in
 `projects.yml` but whose `~/.plastic/projects/{slug}/store/` is missing. This is
-the standalone path; `plastic-creating-project` provisions the store for brand
+the standalone path; `plastic-project-creating` provisions the store for brand
 new projects.
 
 The provisioner is the single source of truth for store creation. It is pure

package/skills/tutorial/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: plastic-tutorial
+description: >-
+  Teach a new user how Plastic works through one of three hands-on tracks: deliver a first
+  intent stage by stage, hand delivery to the agent in auto mode, or grow a founding intent
+  into a small project with a roadmap. Use when the user says "tutorial", "teach me Plastic",
+  "walk me through Plastic", "how do I use Plastic", or asks what Plastic can actually do
+  before trying it on real work.
+user-invocable: true
+---
+
+# Plastic Tutorial
+
+An interactive coach, not an automator. It walks one of three tracks, one step at a time, and
+keeps no state of its own: the intent being used for the walkthrough is the progress bar.
+
+## The three tracks
+
+This is the one menu in the whole skill. Offer it, then route into the picked track's
+reference. Every checkpoint inside a track is prose, never another menu.
+
+1. **Guided**: deliver a first intent, stage by stage, approving each step yourself. Routes to
+   `references/track-1-guided.md`.
+2. **Auto**: hand delivery to the agent and watch the gates and reports as it works. Routes to
+   `references/track-2-auto.md`.
+3. **Projects and roadmaps**: grow a founding intent into a small real project, add more
+   intents, and plan a delivery batch with a roadmap. Routes to
+   `references/track-3-projects-and-roadmaps.md`.
+
+If the user names what they want instead of picking a number ("show me auto mode", "I want a
+roadmap", "walk me through my first intent"), route straight to the matching track without
+showing the menu again.
+
+## The coach contract
+
+Narrate one step at a time: say what the next station does, then hand control back so the
+user types the real command themselves. After they run it, look at what appeared (a file, a
+gate message, a report) and debrief in plain words before moving to the next station. Never
+run a station's command on the user's behalf; the tutorial teaches the shape of the work, it
+does not do the work.
+
+Keep no new state. The intent's own lifecycle stage and savepoint are the only progress
+record. This skill never writes a "tutorial progress" file of its own.
+
+## The resume rule
+
+To pause, the user says "continue the tutorial." Read the walkthrough intent's current stage
+and savepoint (for track 3, check which project-scaffolding steps are already on disk) and
+resume at the matching station. Do not restart from station one, and do not ask the user to
+remember where they left off.
+
+## Routing table
+
+| Trigger | Reference |
+|---|---|
+| User picks "guided", or names their first intent, a first delivery, or learning the stages one at a time | `references/track-1-guided.md` |
+| User picks "auto", or says "hand it to the agent", "run the whole thing", "show me auto mode" | `references/track-2-auto.md` |
+| User picks "projects and roadmaps", or says "start a project", "I want a roadmap", "plan a batch of work" | `references/track-3-projects-and-roadmaps.md` |
+
+## Before any track
+
+Every track opens with the same two checks: run `/plastic-update` first, so the walkthrough
+matches what is actually installed, and work in a sandbox (a throwaway repo, or a global-store
+intent) so nothing real is touched by mistake. Each reference restates this briefly; do not
+skip it even if the user seems experienced.

package/skills/tutorial/evals/evals.json

@@ -0,0 +1,186 @@
+{
+  "skill_name": "plastic-tutorial",
+  "notes": "Intent 166, Phase 1. Scopes: triggering (1-6, should and should-not with near-misses) and track routing (7-10, one case per track plus a direct-menu case). plastic-tutorial is a natural-language guided command with no backing Ruby test, so every assertion carries result: expect-pass pending a real observed run, per the intent-speccing evals.json convention. Phase 2 (post-164) can tighten these into observed pass/fail after a paired run.",
+  "evals": [
+    {
+      "id": 1,
+      "scope": "triggering",
+      "set": "train",
+      "prompt": "I want a tutorial on how Plastic works.",
+      "expected_output": "Activates plastic-tutorial and offers the three-track menu.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE == plastic-tutorial",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 2,
+      "scope": "triggering",
+      "set": "train",
+      "prompt": "Teach me Plastic from scratch.",
+      "expected_output": "Activates plastic-tutorial and offers the three-track menu.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE == plastic-tutorial",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 3,
+      "scope": "triggering",
+      "set": "train",
+      "prompt": "Walk me through Plastic before I try it on my real project.",
+      "expected_output": "Activates plastic-tutorial and offers the three-track menu.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE == plastic-tutorial",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 4,
+      "scope": "triggering",
+      "set": "validation",
+      "prompt": "How do I use Plastic day to day?",
+      "expected_output": "Activates plastic-tutorial and offers the three-track menu.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE == plastic-tutorial",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 5,
+      "scope": "triggering",
+      "set": "validation",
+      "prompt": "I have never touched this tool before. What can it actually do for me before I commit real work to it?",
+      "expected_output": "Activates plastic-tutorial; an indirect trigger that names neither the skill nor the word tutorial.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE == plastic-tutorial",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 6,
+      "scope": "triggering",
+      "set": "train",
+      "prompt": "Create an intent for adding a search feature.",
+      "expected_output": "Does NOT activate plastic-tutorial; activates plastic-intent-creating (a near-miss that shares the word intent but starts real work, not a walkthrough).",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE != plastic-tutorial",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 7,
+      "scope": "triggering",
+      "set": "validation",
+      "prompt": "Just run the whole thing for me, I do not want to steer any of it.",
+      "expected_output": "Does NOT activate plastic-tutorial; activates plastic-auto (a near-miss that describes autonomous delivery of real work, not a walkthrough of how auto works).",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "router CHOICE != plastic-tutorial",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 8,
+      "scope": "track-routing",
+      "set": "train",
+      "prompt": "Inside the tutorial menu: show me auto mode.",
+      "expected_output": "Routes to track 2 (references/track-2-auto.md), the auto handover track.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "TRACK == track-2-auto",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 9,
+      "scope": "track-routing",
+      "set": "train",
+      "prompt": "Inside the tutorial menu: I want a roadmap.",
+      "expected_output": "Routes to track 3 (references/track-3-projects-and-roadmaps.md), the projects and roadmaps track.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "TRACK == track-3-projects-and-roadmaps",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 10,
+      "scope": "track-routing",
+      "set": "validation",
+      "prompt": "Inside the tutorial menu: start a project.",
+      "expected_output": "Routes to track 3 (references/track-3-projects-and-roadmaps.md), the projects and roadmaps track.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "TRACK == track-3-projects-and-roadmaps",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 11,
+      "scope": "track-routing",
+      "set": "validation",
+      "prompt": "Walk me through my first intent, one stage at a time.",
+      "expected_output": "Routes to track 1 (references/track-1-guided.md), the guided delivery track.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "code",
+          "check": "TRACK == track-1-guided",
+          "result": "expect-pass"
+        }
+      ]
+    },
+    {
+      "id": 12,
+      "scope": "track-routing",
+      "set": "train",
+      "prompt": "Tutorial. (No further detail given.)",
+      "expected_output": "Activates plastic-tutorial and presents the three-track menu itself, since no track was named; this is the one case where the menu is the expected output rather than a routed track.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "the reply shows the three-track menu (guided, auto, projects and roadmaps) and does not jump into any one track uninvited",
+          "result": "expect-pass"
+        }
+      ]
+    }
+  ]
+}

package/skills/tutorial/references/track-1-guided.md

@@ -0,0 +1,123 @@
+# Track 1: Guided, your first intent
+
+## Who it is for and what you will have done
+
+For a new user who wants to feel the whole cycle once, one stage at a time, approving each
+step before the next one starts. After this track, one small, real change will be delivered
+end to end: a piece of work moved through What, Why, How, and Exec, with a finished
+`outcome.md` to show for it.
+
+## Before you start
+
+Run `/plastic-update` first, so the commands below match what is actually installed.
+
+Work in a sandbox: this track always creates a global-store intent; the throwaway repo below
+is never registered as a Plastic project. Pick a throwaway git repository if you have one
+handy, since the worked example edits its README: station 6's deliverable is that file edit.
+No repo handy? Station 6's deliverable becomes a short written note saved in the intent's own
+directory instead (see station 6). Either way, nothing in this track touches a real project.
+
+## Stations
+
+### 1. Create the intent
+
+Type `/plastic-intent-creating` and describe the work in plain words, for example "add a
+short Usage section to this project's README."
+
+Artifact: a new intent directory, `{id}--slug.md`, plus the sentinel placeholder lifecycle
+files (`spec.md`, `plan.md`, `checklist.md`, `outcome.md`) and empty `actions/` and
+`resources/` folders.
+
+Checkpoint: open the new file. It already has a real id and a one-line description; nothing
+was hand-typed into it directly. That is the point: intents are always scaffolded by the
+tool, never written by hand.
+
+### 2. Board the intent
+
+Type `/plastic-intent-starting`.
+
+Artifact: a delivery lock (a `delivery.lock` file in the intent directory) naming this
+session as the one owner, and a line in `savepoint.md` recording the stage. The agent then
+asks exactly one question: "auto or guided?"
+
+Checkpoint: answer "guided." Explain in one sentence why the lock matters: it stops two
+sessions from editing the same intent at the same time.
+
+### 3. Why, rulings one at a time
+
+Type `/plastic-intent-brainstorming` (or `/plastic-intent-grilling` for a harder,
+interview-style pass over the same ground). It asks conversational prose questions, one at a
+time, never a multiple-choice menu, and answers them one at a time in return.
+
+Artifact: `## Context` and `### Decisions` in the intent file fill in as each answer lands, and
+each ruling also lands as its own `## Insights` entry the moment it is made, never batched for
+later. This station's product is the enriched Why; it hands off to `/plastic-intent-speccing`
+next, it does not write `spec.md` itself.
+
+Checkpoint: after two or three answers, look at the intent file. Every ruling given out loud
+is already sitting in `### Decisions` and in `## Insights`, in writing.
+
+### 4. Consolidate the spec
+
+Type `/plastic-intent-speccing`.
+
+Artifact: `spec.md`, stamped with a tier (`S`, for this small worked example) and its eight
+sections filled from the rulings recorded in station 3.
+
+Checkpoint: name the stamped tier and point at one sentence in `spec.md` that traces back to
+an answer given in station 3.
+
+### 5. Plan
+
+Type `/plastic-intent-planning`.
+
+Artifact: `plan.md` and `checklist.md`. At the S tier used here, `actions/` stays empty and
+the task rationale lives inline in `plan.md` instead of separate action files; only the L
+tier (many independent tasks, dispatched in parallel) gets one `actions/ACTION_N.md` file
+per task. `checklist.md` follows a fixed form: tasks start under `## In Progress`, move to
+`## Completed` as they land, and a `## Session Log` table records what happened each session.
+A task that depends on an owner decision landing first (a destructive step, a structural
+ruling) gets an `[ORCHESTRATOR]` prefix and blocks every other item until that decision is
+made; this worked example has none.
+
+Checkpoint: open `checklist.md`. Every task in `plan.md` has a matching checkbox under
+`## In Progress`; that checklist, not `plan.md` itself, is what gets ticked off and moved to
+`## Completed` during Exec.
+
+### 6. Exec, verify before the gate
+
+Type `/plastic-intent-executing`.
+
+Teach the order: first the agent syncs its working copy with the main line, so no edit lands
+on a path a merged change upstream has already touched or removed. Then it makes the change,
+runs whatever verifies it (a test suite, or a manual check for a docs change like this one),
+and only then ticks the checklist box, moving the task from `## In Progress` to
+`## Completed` and adding a `## Session Log` row, before moving to the next task. Verifying
+always comes before checking a box, never after, and each task is ticked the moment it lands,
+never batched for later.
+
+Artifact: the actual change on disk (the new README Usage section, or, in the global-store
+fallback, a short written note saved as the intent's deliverable) and a fully ticked
+`checklist.md`.
+
+Checkpoint: find the new Usage section in the README (or the written note) and confirm every
+box in `checklist.md` is checked and moved to `## Completed`, with a `## Session Log` row for
+this session, before moving to station 7.
+
+### 7. Done
+
+Type `/plastic-intent-ending`.
+
+Artifact: a real `outcome.md` (Summary, Delivered, Verification, Follow-ups), the intent
+moved from `## Active` to `## Completed` in `INDEX.md`, and a closing `Done` line in
+`savepoint.md`.
+
+Checkpoint: open `outcome.md` and read its Summary. It should describe, in a sentence or
+two, exactly the README section (or note) just delivered.
+
+## Wrap and where to go next
+
+That is the full cycle once: create, board, decide, spec, plan, build, done. Read
+`docs/guides/your-first-intent-in-10-minutes.md` for the same path condensed to a single
+read, and `docs/guides/what-the-gates-are-telling-you.md` for what to do if a station denies
+an action instead of completing it.

package/skills/tutorial/references/track-2-auto.md

@@ -0,0 +1,95 @@
+# Track 2: Auto, hand delivery to the agent
+
+## Who it is for and what you will have done
+
+For someone who has seen the stages once (track 1) and now wants to hand the work to the
+agent, watch it move through the gates and reports on its own, and learn how to check in on
+it and step back in later. After this track, one small intent will have been delivered by the
+agent end to end, and pausing and resuming that delivery will feel familiar.
+
+## Before you start
+
+Run `/plastic-update` first, so the commands below match what is actually installed.
+
+Work in a sandbox: a throwaway git repository, or a global-store intent. Nothing in this
+track touches a real project.
+
+## Stations
+
+### 1. Board a small intent and choose auto
+
+Start from an active intent (create one first with `/plastic-intent-creating` if none
+exists, the same way as track 1 station 1). Type `/plastic-auto`.
+
+Artifact: the delivery lock arms, and the agent announces it is taking over the intent for
+autonomous delivery.
+
+Checkpoint: name the one precondition auto needs before it will start: an active intent must
+already exist for the intent you name. (Say "auto" with nothing named, and it can pick a
+queued intent from the dashboard's queue itself.)
+
+### 2. What auto does, and what stays with the user
+
+No new command at this station. Watch how the work splits.
+
+Auto owns How (the plan, the checklist, the action files) and Exec (the code, the tests, the
+mechanical close) from here on. Inside Exec it follows a few fixed habits: it syncs its
+working copy with the main line before touching anything, ticks each task the moment it
+lands rather than batching several into one later edit, and independently verifies its own
+work (running the test suite, or checking the changed file) before presenting anything back
+to you. For a task shaped like an audit or a sweep, checking many files rather than building
+one artifact, it also drops a short methods report into `resources/` before the gate, so you
+can review how it checked, not just what it found.
+
+The user keeps two things: the rulings made along the way, and the review points, moments
+auto is built to pause for, such as confirming a project path or stopping before a
+destructive action with no safe way back. When auto tells you to run a command yourself
+("run /plastic-intent-speccing"), that is an instruction for you to type; it is a different
+thing from the prompts auto hands to its own dispatched subagents, and the two are never
+mixed up in what it tells you.
+
+Checkpoint: name one thing auto will always stop and ask about, rather than decide alone.
+
+### 3. Walking the gates
+
+No new command. Auto still honors every hard gate a guided session would hit: the delivery
+lock (one owner at a time), the code gate (shut until `plan.md` and `checklist.md` exist),
+and the create gate (intents only come from the tool that makes them, never hand-authored).
+One gate, retrieval, is advisory only and never blocks anything; it just adds a note.
+
+Checkpoint: read one gate message from the run so far and say whether it is one of the hard
+gates or the one advisory note.
+
+### 4. Reading the per-stage reports
+
+No new command. At each stage boundary (What, Why, How, Exec, Done) the agent briefs in a
+fixed three-line shape: State (what happened and why it matters), Risk (the one thing that
+could bite, or "nothing flagged"), and Call (the decision left to the user, or the call the
+agent is taking on its own).
+
+Checkpoint: in the most recent report, point at the State line, the Risk line, and the Call
+line.
+
+### 5. Continue and where-was-I after time away
+
+Type `/plastic-intent-continuing`.
+
+Artifact: the current state, presented and then the session stops. If a specific intent is
+named, the agent reads its stage and savepoint and resumes exactly there, rather than
+starting over.
+
+Checkpoint: after stepping away and running this command, name the stage the intent resumed
+at and how that matched what was actually on disk.
+
+## Wrap and where to go next
+
+Auto keeps the same stages and the same gates as guided; the only difference is who steers.
+Read `docs/guides/pick-your-mode.md` for the honest trade-off between guided and auto, and
+`docs/guides/using-plastic-with-claude-code.md` for how that choice feels day to day and how
+it connects to roadmap-driven delivery. For denial messages met along the way, read
+`docs/guides/what-the-gates-are-telling-you.md`.
+
+Note on terms: "guided" means the user starts each stage with a command and the agent
+narrows the thinking inside it, the same shape track 1 walked. "Manual", editing project
+files outside the lifecycle entirely, is not a third mode; it is the anti-pattern both guided
+and auto exist to avoid.