@zalom/plastic 1.0.3 → 1.1.1

package/skills/auto/SKILL.md

@@ -1,38 +1,54 @@
 ---
 name: plastic-auto
 description: >-
-  Autonomous intent delivery — agent takes over How and Exec. Use when user says
+  Autonomous intent delivery - agent takes over How and Exec. Use when user says
   "auto", "take it from here", "deliver this", or when brainstorming-grill-me concludes
   and user confirms autonomous execution. Requires an active intent in INDEX.md.
 user-invocable: true
 ---
 
-# Auto — Autonomous Intent Delivery
+# Auto - Autonomous Intent Delivery
 
-Announce: "Taking over intent [ID] — [name] for autonomous delivery."
+Announce: "Taking over intent [ID] - [name] for autonomous delivery."
 
 **Advisory (not a gate).** 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) for the sharpest gating and synthesis. This is advice only: it changes no
 behavior and blocks nothing if ignored. It concerns the human's MAIN session; dispatched
-subagents keep their pinned tier and never resolve to Fable.
+subagents keep their pinned tier and never resolve to Fable, unless an explicit
+`agents.models.<name>` config override names Fable for that role, in which case the override
+is honored as written.
 
 ## Precondition
 
-An active intent MUST exist in INDEX.md. If none exists, refuse: "No active intent found. Create one first with /plastic-creating-intent."
+An active intent MUST exist in INDEX.md. If none exists, refuse: "No active intent found. Create one first with /plastic-intent-creating."
 
 If multiple active intents exist, ask the user which one to deliver (this is the only question auto asks).
 
 **Picking work when no intent is specified.** If the user says "auto" without naming an
-intent and none is active, consult the dashboard's machine-readable queue to choose the
-next dispatchable intent:
+intent and none is active, consult the roadmap first (the primary planning surface), then
+fall back to the dashboard queue. Read the tier's mid-flight roadmap:
+
+```bash
+ruby ~/.plastic/scripts/roadmap-next --roadmaps-dir <tier>/roadmaps
+```
+
+Branch on `state`:
+- `dispatchable`: work its `dispatchable_queue` in `rank` order (the head is the next batch
+  entry). These are the current batch's `queued` intents, parallel-safe within the wave.
+- `in_flight`: the frontier batch is still delivering. Report it and wait. Do NOT dispatch a
+  later batch and do NOT fall through to the dashboard, the roadmap is live.
+- `none` or `exhausted`: no roadmap, or nothing left to dispatch. Fall back to the dashboard
+  queue below. (The global store has no roadmap, so it always reports `none` and falls back.)
+
+Dashboard fallback:
 
 ```bash
 ruby ~/.plastic/scripts/dashboard.rb all --json
 ```
 
-Work `dispatchable_queue` in `rank` order (these are `defer`/`research` dispositions —
-safe to deliver autonomously). Leave `human_only` and `next_big_thing` for the user — those
+Work `dispatchable_queue` in `rank` order (these are `defer`/`research` dispositions -
+safe to deliver autonomously). Leave `human_only` and `next_big_thing` for the user - those
 are `drive`/`triage` items the human should lead. See the `plastic-dashboard` skill.
 
 QMD-first (when available): when the user describes the work to deliver rather than naming an
@@ -65,7 +81,7 @@ and artifact depth to that size. Extended walkthrough: `references/tiers.md`.
 
 ## Arm the Lifecycle Gate (do this FIRST)
 
-Immediately after selecting the intent — before any other work — arm auto mode. This
+Immediately after selecting the intent - before any other work - arm auto mode. This
 writes the session bridge that makes the code-edit gate live, so project code cannot be
 edited before the plan exists (the gate applies to YOU, the orchestrator):
 
@@ -88,7 +104,7 @@ Honor the cycle: What → Why (spec.md) → How (plan.md + actions/ + checklist.
 
 ## Flags
 
-- `--skip-permissions` — bypass hard stops on destructive actions on existing projects. Full trust mode. Default: off.
+- `--skip-permissions` - bypass hard stops on destructive actions on existing projects. Full trust mode. Default: off.
 
 ## Team Spin-Up
 
@@ -104,11 +120,13 @@ Roster (one role per cycle stage):
 - **plastic-executor** (code + checklist + `## Insights`)
 - **plastic-enforcer** (orchestrates + gates; that is YOU)
 
-Dispatch rule: sequential, one specialist per stage on one branch (the deliverables share files). Gate each deliverable against the stage's exit criteria before handing off. The How and Exec phases below default to Plastic's native dispatch (`plastic-executing-plan`) and delegate to the superpowers skills only when they are available or the user asks; do not restate the phase mechanics here.
+Dispatch rule: sequential, one specialist per stage on one branch (the deliverables share files). Gate each deliverable against the stage's exit criteria before handing off. The How and Exec phases below default to Plastic's native dispatch (`plastic-intent-executing`) and delegate to the superpowers skills only when they are available or the user asks; do not restate the phase mechanics here.
 
 Spawn preamble (live-state injection): before dispatching any specialist, run `scripts/spawn-preamble <intent_dir> --role <role>` and PREPEND its output to that specialist's prompt. The preamble is a deterministic, filesystem-only snapshot of the active intent (id, intent line, current stage, and the provisioned code worktree path when one exists on disk) plus the honoring instruction, so every spawned agent boots with accurate live state instead of guessing. This is the authoritative L2 mechanism for harnesses whose sub-agents do not inherit a top-level session event (see `docs/reference/harness-adapters.md`).
 
-Dispatch-time model contract (belt-and-braces): alongside the preamble, resolve each specialist's model through the config chain (`read-config agents.models.<basename> --project <repo>`: project override, then global, then the shipped tier default) and pass it explicitly at dispatch. Never rely on the dispatched role's frontmatter alone; a resolved subagent model is never Fable.
+Dispatch-time model contract (belt-and-braces): alongside the preamble, resolve each specialist's model through the config chain (`read-config agents.models.<basename> --project <repo>`: project override, then global, then the shipped tier default) and pass it explicitly at dispatch. Never rely on the dispatched role's frontmatter alone; a resolved subagent model is never Fable,
+unless an explicit `agents.models.<name>` config override names Fable for that role, in which
+case the override is honored as written.
 
 Completion report (require-then-synthesize): every dispatched specialist MUST end with a structured completion report as its final message. The preamble's `REPORT_CONTRACT` injects this and the role prompts carry the per-role format (see `references/agent-report-contract.md`). Because child-agent honor is best-effort across harnesses, this is decision-shaping, not a hard block. When a specialist returns no usable report (it went idle, emitted only a bare ping, or its message was lost to a mid-run interjection), run `scripts/agent-report <intent_dir> --role <role>` to synthesize a deterministic filesystem-derived report so the handoff account always exists. Use the agent-authored report when present, the synthesized one otherwise.
 
@@ -168,15 +186,15 @@ this is worth doing, or proceed).
 When entering at Why stage:
 
 1. Read existing `## Context` and `### Decisions` from the intent file
-2. Assess gaps — what decisions are missing? What context is incomplete?
-3. Self-directed research — read code, search docs, explore related intents (via wikilinks in `## Links`), web search if needed. NO questions to human.
-4. Adaptive budget — assess complexity and set your own research budget:
+2. Assess gaps - what decisions are missing? What context is incomplete?
+3. Self-directed research - read code, search docs, explore related intents (via wikilinks in `## Links`), web search if needed. NO questions to human.
+4. Adaptive budget - assess complexity and set your own research budget:
    - Simple (config change, small feature): 2-3 research steps
    - Medium (new feature, integration): 5-8 research steps
    - Complex (new project, architecture): 10-15 research steps
-5. Make decisions — pick best option, document in `## Context > ### Decisions` with rationale
+5. Make decisions - pick best option, document in `## Context > ### Decisions` with rationale
 6. Log all autonomous decisions in `## Insights` with `(autonomous)` marker: "Decision: chose X because Y (autonomous)"
-7. Write `spec.md` — consolidated specification
+7. Write `spec.md` - consolidated specification
 8. Notify user (Why briefing): brief per `references/human-report-contract.md`
    (State: the approach chosen, one line; Risk: the main trade-off; Call: the one decision
    needed, approve or pick an option).
@@ -191,9 +209,9 @@ intent birth and persists at every tier; only writing `ACTION_N.md` files into i
 only (S/M leave the directory empty).
 
 1. If `superpowers:writing-plans` is available as a skill, delegate plan creation to it. Tell it the plan saves to the active intent's directory (not `docs/superpowers/plans/`).
-2. Otherwise, write `plan.md` directly — implementation plan with numbered tasks
-3. Write `ACTION_N.md` files into the existing `actions/` directory (one per task, self-contained) — L only
-4. Write `checklist.md` — execution registry with checkboxes covering all actions
+2. Otherwise, write `plan.md` directly - implementation plan with numbered tasks
+3. Write `ACTION_N.md` files into the existing `actions/` directory (one per task, self-contained) - L only
+4. Write `checklist.md` - execution registry with checkboxes covering all actions
 5. Notify user (How briefing): brief per `references/human-report-contract.md`
    (State: the plan shape, task count and what it builds; Risk: the riskiest task or
    dependency; Call: approve the plan to build).
@@ -205,9 +223,9 @@ Then proceed to Exec.
 If the plan calls for creating a new project (the intent is an implementation intent that needs a new codebase):
 
 1. Determine project path from `~/.plastic/config.yml` `project_roots` or from intent context
-2. **Confirm path with user** — this is the ONE human interaction during auto delivery:
+2. **Confirm path with user** - this is the ONE human interaction during auto delivery:
    > "Creating project `<slug>` at `<path>`. Confirm path, or provide alternative."
-3. Invoke `plastic-creating-project` skill
+3. Invoke `plastic-project-creating` skill
 4. The global intent is now Completed (creating-project handles this)
 5. The tactical mirror in the project store becomes the active intent
 6. Continue execution from the project directory using the tactical intent
@@ -215,7 +233,7 @@ If the plan calls for creating a new project (the intent is an implementation in
 ## Exec Phase
 
 1. If `superpowers:subagent-driven-development` or `superpowers:executing-plans` is available, delegate execution to it
-2. Otherwise invoke `plastic-executing-plan`
+2. Otherwise invoke `plastic-intent-executing`
 3. Execute actions from checklist sequentially
 4. Check off items in `checklist.md` as completed
 5. Append observations to `## Insights` with `(autonomous)` marker
@@ -224,7 +242,7 @@ If the plan calls for creating a new project (the intent is an implementation in
    (State: what got built and the test result; Risk: residual failures or deviations;
    Call: go to review, or done).
 
-## Permission Model — Safe-by-Default
+## Permission Model - Safe-by-Default
 
 The agent MUST prefer non-destructive routes:
 
@@ -232,7 +250,7 @@ The agent MUST prefer non-destructive routes:
 |---|---|
 | Drop table | Rename to `_deprecated_<table>`, flag for cleanup |
 | Delete files | Move to `.archive/` or backup branch |
-| Alter column | Additive migration — new column + backfill |
+| Alter column | Additive migration - new column + backfill |
 | Remove feature | Feature flag off, code stays until human confirms |
 | Database migration | Backup before migration, keep rollback path |
 
@@ -247,7 +265,7 @@ With `--skip-permissions`, the agent logs the action in Insights but proceeds wi
 
 ### Greenfield Exception
 
-During initial project creation, all decisions are non-destructive by definition (there's nothing to destroy). The agent has full autonomy for greenfield choices — DB engine, framework, gems, architecture.
+During initial project creation, all decisions are non-destructive by definition (there's nothing to destroy). The agent has full autonomy for greenfield choices - DB engine, framework, gems, architecture.
 
 ## Completion
 
@@ -258,55 +276,38 @@ During initial project creation, all decisions are non-destructive by definition
    and End tail in PLASTIC.md `## Delivery Isolation and the Single-Owner Lock`).
 3. Write `## Outcome` summary in the intent file (1-2 sentences)
 4. **Release (if configured)**
-   1. Detect project — match CWD against paths in `~/.plastic/projects.yml` to find the project slug. If no match, skip to step 5 (default commit-only behavior).
+   1. Detect project - match CWD against paths in `~/.plastic/projects.yml` to find the project slug. If no match, skip to step 5 (default commit-only behavior).
    2. Read `~/.plastic/projects/{slug}/project.yml`. If the file doesn't exist or has no `release` key, skip to step 5.
    3. Based on `release.on_complete`:
-      - `commit` — git add + commit (same as default, proceed to step 5)
-      - `commit_and_push` — git add + commit + push
-      - `manual` — skip auto-commit, notify user: "Release configured as manual — commit when ready."
+      - `commit` - git add + commit (same as default, proceed to step 5)
+      - `commit_and_push` - git add + commit + push
+      - `manual` - skip auto-commit, notify user: "Release configured as manual - commit when ready."
    4. If `release.verify` is set, run the verify command (e.g. `bundle exec rake test`):
       - **Exit 0 (green):** proceed to sub-step 5
       - **Non-zero (red):** check `release.on_red`:
-        - `fix_and_retry` — attempt to fix the failure, re-run verify (max 2 retries)
-        - `stop` — write `savepoint.md` with current state, notify user: "Verify failed — savepoint written.", **STOP**
-        - `manual` — notify user: "Verify failed: [summary]. Resolve manually."
-   5. If `release.on_green` has items, invoke `plastic-releasing` to handle them (tag, changelog, publish, etc.). Do NOT duplicate release logic — delegate entirely.
+        - `fix_and_retry` - attempt to fix the failure, re-run verify (max 2 retries)
+        - `stop` - write `savepoint.md` with current state, notify user: "Verify failed - savepoint written.", **STOP**
+        - `manual` - notify user: "Verify failed: [summary]. Resolve manually."
+   5. If `release.on_green` has items, invoke `plastic-releasing` to handle them (tag, changelog, publish, etc.). Do NOT duplicate release logic - delegate entirely.
 5. Review `## Insights` for observations that should spawn future intents. If any:
-   - Create them (using `plastic-creating-intent` conventions)
+   - Create them (using `plastic-intent-creating` conventions)
    - Update `chain` in the current intent's frontmatter
-6. Move intent from `## Active` to `## Completed` in INDEX.md (with today's date). As the
-   closing act of the transfer, stamp the terminal ledger bookend (intent 81) so the savepoint's
-   last line records delivery:
-   ```bash
-   ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.append_terminal_savepoint("<intent_dir>", "delivered")'
-   ```
-   (Use `"abandoned"` instead when the intent is being moved to `## Abandoned`.) Idempotent.
-7. Auto-commit: `cd <store-root> && git add . && git commit -m "feat: deliver intent <ID> — <name>"`
-8. Disarm the lifecycle gate (auto delivery is finished). Substitute the intent's own id for
-   `<ID>` (a session can be delivering more than one intent at once, intent 131, so disarm must
-   name which of the session's bridges to clear):
-   ```bash
-   ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.disarm_auto(ENV["CLAUDE_CODE_SESSION_ID"], intent_id: "<ID>")'
-   ```
-   Disarm runs the ordered End tail (release worktrees, then clear the `delivery.lock`,
-   then the bridge becomes purge-eligible) and performs the mandatory worktree cleanup
-   (intent 73c3): both per-intent worktrees are removed and both repos pruned. This is
-   the plain remove path (no merge); when the work ships through a release, the release
-   path merges the branch BEFORE the worktree is removed instead of relying on this step.
-   Never leave an orphaned worktree, and run `git worktree prune` if you hit a stale
-   reference. For the full ordering rationale and the release-vs-plain-disarm
-   distinction, read `references/end-tail.md`.
-9. QMD reindex LAST (canonical End tail), run only after disarm has released the
-   worktrees, cleared the `delivery.lock`, and purged the bridge. It runs in the
-   background so it never blocks the turn:
+6. Run the mechanical close through `plastic-intent-ending`: it owns steps 1-6 of the Done
+   procedure (outcome/INDEX/savepoint/commit, disarm, and the QMD reindex last) as ONE
+   delegation, not five separate one-liners restated here. Run its backing script for the
+   outcome/INDEX/savepoint/commit core, passing `--index-note` with a rich Completed/
+   Abandoned entry description (mode/tier, what shipped or why abandoned, suite result):
    ```bash
-   ruby ~/.plastic/scripts/qmd-sync reindex --store <store-root> --async
+   ruby ~/.plastic/scripts/end-intent --store <store_path> --id <ID> --disposition delivered \
+     --index-note "<mode, tier>; <what shipped>; <suite result>"
    ```
-   `<store-root>` is the store that holds this intent (the global store or the project
-   store); the command is a no-op when QMD is absent. For why the reindex must be last
-   (so the index never references a bridge or lock about to disappear), read
-   `references/end-tail.md`.
-10. Notify user (Done briefing): brief per `references/human-report-contract.md`
+   (Use `--disposition abandoned` when the intent is being moved to `## Abandoned`.) Then
+   follow `plastic-intent-ending`'s Step 5 (disarm: `Bridge.disarm_auto` on this auto/curator
+   path, the plain-remove branch) and Step 6 (QMD reindex, async, last) exactly as that skill
+   states them. Never leave an orphaned worktree; run `git worktree prune` on a stale
+   reference. If any of this ever needs to change, change `plastic-intent-ending`, not this
+   skill.
+7. Notify user (Done briefing): brief per `references/human-report-contract.md`
     (State: the delivered impact; Risk: residual risk; Call: the decision left to you, merge,
     release, or accept). See `outcome.md` for details.
 
@@ -315,7 +316,7 @@ During initial project creation, all decisions are non-destructive by definition
 If the agent gets stuck (can't resolve a gap, dependency is missing, tests fail persistently):
 1. Log the blocker in `## Insights`
 2. Write `savepoint.md` with current state
-3. Notify user: "Blocked on intent [ID] — [name]: [description]. Savepoint written."
+3. Notify user: "Blocked on intent [ID] - [name]: [description]. Savepoint written."
 4. **STOP.** Do not attempt workarounds that could leave the project in a broken state.
 
 ## References

package/skills/auto/evals/evals.json

@@ -116,13 +116,13 @@
       "scope": "triggering",
       "set": "train",
       "prompt": "create a new intent for the dashboard idea",
-      "expected_output": "Does NOT activate plastic-auto; activates plastic-creating-intent.",
+      "expected_output": "Does NOT activate plastic-auto; activates plastic-intent-creating.",
       "files": [],
       "assertions": [
         {
           "type": "code",
           "check": "router CHOICE != plastic-auto",
-          "observed": "plastic-creating-intent",
+          "observed": "plastic-intent-creating",
           "result": "pass"
         }
       ]
@@ -132,13 +132,13 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "what's the status of my active intents?",
-      "expected_output": "Does NOT activate plastic-auto; this is a read/continuing/managing-index query.",
+      "expected_output": "Does NOT activate plastic-auto; this is a read/intent-continuing/store-indexing query.",
       "files": [],
       "assertions": [
         {
           "type": "code",
           "check": "router CHOICE != plastic-auto",
-          "observed": "plastic-managing-index",
+          "observed": "plastic-store-indexing",
           "result": "pass"
         }
       ]

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

@@ -101,7 +101,7 @@ verifies state itself.
 ### Delegation
 
 The roles are thin handoff contracts, not a spawning engine. Dispatch and review run
-by default through Plastic's own engine, `plastic-executing-plan` (implementer plus
+by default through Plastic's own engine, `plastic-intent-executing` (implementer plus
 two-stage review, no external plugin). When `superpowers:subagent-driven-development`
 and `superpowers:dispatching-parallel-agents` are available, or the user asks for them,
 they delegate to those as an enhancement. The team model defines who hands what to whom
@@ -112,7 +112,7 @@ spawning.
 
 The default is always Plastic's native engine, so a user without superpowers still gets
 the full behavior. If the harness supports subagents but superpowers is absent, auto
-mode dispatches through `plastic-executing-plan`. If the harness has no subagent dispatch
+mode dispatches through `plastic-intent-executing`. If the harness has no subagent dispatch
 at all, auto mode falls back to a single agent walking the full What, Why, How, Exec
 cycle itself. The enforcer's gate discipline still applies in every case.
 

package/skills/continuing/SKILL.md

@@ -1,141 +1,34 @@
 ---
 name: plastic-continuing
-description: Use when the user says "continue", "resume", or "pick up where we left off", or when starting a new session. Continues work with the latest project context: lands on the right dashboard, then presents choices. Boot (health check, core context, version, statusline) is owned by the SessionStart hook, not this skill. Does not drive work autonomously (that is plastic-auto).
+description: >-
+  Use when the user says "continue", "resume", or "pick up where we left off", starts a new
+  session and wants to keep going, asks "what should I work on", or asks a where-was-I question
+  that never says "continue" (for example "where was I"). This is the front door for resuming
+  work: it dispatches to plastic-intent-continuing (a specific intent named to resume),
+  plastic-project-continuing (the default, general board landing), or
+  plastic-roadmap-continuing (a roadmap or delivery batch named to resume).
 user-invocable: true
 ---
 
-# Continuing
+# Continuing - the front door
 
-`plastic-continuing` continues work. It presents the latest state via the dashboard and offers
-choices, then stops. It does NOT execute work autonomously (that is `plastic-auto`) and does
-NOT render the dashboard itself (it only invokes it).
+`plastic-continuing` is the front door for resuming work (ruling 96: continuing routes,
+starting does the lock plus resume plus work). It routes to exactly one of three skills and
+does nothing else: no ledger-resume, no dashboard render, no roadmap read happens here.
 
-**Boot is not this skill's job.** The `hook-session-start` hook already runs by construction on
-every session start: it runs the core health check (`doctor --core`), primes `PLASTIC.md` +
-store/project state, and prints the `Plastic Core loaded — v{version}` banner. The
-`plastic-statusline` hook sets the statusline. So by the time this skill runs, core is loaded
-and healthy (or the banner already warned otherwise). This skill picks up from there and
-continues work. This is the seam future continue-flags build on (see [[39]]).
+## Route
 
-## When to Use
-- UserPromptSubmit hook detects "continue" (automatic)
-- User says "continue", "resume", or "pick up where we left off"
-- Starting a new session and you want to resume work with the latest context
+| Args / context | Route to |
+|---|---|
+| `--intent {id}`, or the user names one specific intent (by id or description) to resume | `plastic-intent-continuing` (intent route) |
+| `--roadmap {slug}`, or the user asks to continue/resume a roadmap or delivery batch | `plastic-roadmap-continuing` (roadmap route) |
+| bare "continue" / "resume" / no further target (default) | `plastic-project-continuing` (project route) |
 
-## Determine Store
+## Announce, then hand off
 
-1. **Global store** — `~/.plastic/INDEX.md` exists → global mode.
-2. **Local store** — a project store under `~/.plastic/projects/{slug}/` whose registered
-   path (in `~/.plastic/projects.yml`) matches the current working directory → project mode.
-   The SessionStart hook already detects this; here you only need the slug to scope the
-   dashboard.
-3. If neither exists → announce "No Plastic store found. Run /plastic-install."
+State the chosen route in one line before delegating (this is the router's own "present state
+before any ask" - the router asks nothing itself). Example: "Routing to the project board (no
+specific intent or roadmap named)."
 
-## Continue (present the dashboard)
-
-Land on the Markdown board via the `plastic-dashboard` skill. Rendering belongs there, not
-here — run the data payload and fill + present the matching template:
-- Project loaded → `ruby ~/.plastic/scripts/dashboard.rb project <slug> --data`
-- Otherwise → `ruby ~/.plastic/scripts/dashboard.rb continue --data`
-
-Fill the matching template from this skill's `templates/` and **present the filled Markdown
-in your reply** (every time, non-optional). If the reply does not contain the filled Markdown,
-the user sees nothing — tool-call stdout and hook `additionalContext` are both invisible to
-them. `hook-continue` also emits a one-line `systemMessage` summary as a hook-owned fallback;
-treat it as a floor only, never as a substitute for presenting the full board here. See
-`plastic-dashboard` for the fill rules and entry flow.
-
-The board load runs the scoped store check on every load (`doctor --store <scope>`): the
-global board runs `--store global` and a project board runs `--store <slug>`. The result
-arrives in the payload as `store_health`; surface it as a one-line store-health note. It is
-non-fatal (a warn or fail is shown as data, it does not block continuing).
-
-### Then stop
-Present "here is the state, what next?" and wait. Offer active intents first, then future
-intents. Do not start executing work. The branches below are the only follow-ups:
-- User/agent names a specific intent to continue → **Conditional ledger-resume** (below).
-- User says "auto" / an agent is instructed to deliver → hand to `plastic-auto`.
-
-## Conditional Ledger-Resume
-
-Fires ONLY when the user explicitly asks to continue a SPECIFIC intent, or an agent is
-instructed to continue one. It is not part of every boot.
-
-QMD-first (when available): when the user names the intent by description rather than id, before
-scanning the store with grep/Read run `ruby ~/.plastic/scripts/qmd-sync search "<terms>"` to
-surface the candidate intent, then open the authoritative intent file for the hit you resume. The
-command is a no-op when QMD is absent, so fall back to the existing INDEX.md / file scan.
-
-For that intent's directory:
-
-1. **Read `savepoint.md` FIRST (intent 81).** It is a deterministic, append-only ledger
-   (one line per event, newest at the bottom): `{utc-iso8601}  {Stage}  {milestone}`. Classify
-   the state from the **last line** alone, then verify ONLY that line's artifact. The bookends
-   are fixed: first line `What  created`, last line either a cycle position or
-   `Done  delivered|abandoned`.
-
-   | Last line | State | Verify only |
-   |---|---|---|
-   | `What  {id}--{slug}.md` | born / parked | intent file exists |
-   | `Why  started` | Why entered, no spec yet | spec.md not yet real; continue Why |
-   | `Why  spec.md created` | Why done | spec.md present; continue to How |
-   | `How  started` / `How  plan.md created` | How in progress | plan.md; continue How |
-   | `How  checklist.md created` / `Exec  started` | ready for / in Exec | plan.md + checklist.md present; continue Exec |
-   | `Exec  outcome.md created` | Exec done | outcome.md present; ready to complete |
-   | `Done  delivered` / `Done  abandoned` | terminal | do NOT cycle-resume; INDEX is authoritative |
-
-2. **Verify the stage file.** Confirm only the last line's artifact exists and is non-empty
-   (ledger `How  plan.md created` → `plan.md` must be present and non-empty). Do not re-probe
-   every lifecycle file.
-3. **Drift handling.** If the ledger's last line disagrees with files-on-disk, rebuild the
-   ledger from filesystem state and note the correction. A rebuilt ledger is the file-landing
-   skeleton (no `started`/`Done` lines), which still pins cycle position:
-   ```bash
-   ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.rebuild_savepoint("<intent_dir>")'
-   ```
-4. **Derive the next step:**
-   - First unchecked item in `checklist.md` if it exists, else
-   - "advance to the next lifecycle stage" (e.g. ledger shows Why/spec.md → next is How).
-   - The newest `## Insights` entry supplies human-readable context (Insights are
-     append-only, newest at the bottom).
-5. **Announce and stop:**
-   ```
-   Resuming intent [ID] — [name]
-   Store: [global | project:<slug> | local]
-   Stage: [from ledger last line]
-   Next step: [first unchecked checklist item | advance to <stage>]
-   Context: [newest ## Insights entry]
-   Drift: [none | ledger rebuilt from filesystem]
-   ```
-   Then proceed with the next step. Autonomy is `plastic-auto`'s job — if the intent's
-   `## Insights` contains `(autonomous)` entries, it was being delivered autonomously; hand
-   to `plastic-auto` to continue from the current stage.
-
-## Priority Order
-
-1. **Active intents first** — surface work in progress.
-2. **Project context** — if in a registered project, show governing + tactical intents.
-3. **Stale future intents** — surface for triage (see below).
-4. **Fresh future intents** — offer as next work.
-
-## Stale Future Intents
-
-If a future intent's `created` date is older than the configured `stale_threshold_days`
-(default 3), surface it for triage without taking action:
-
-```
-Stale future intents (no action taken):
-
-- [ID — name] (X days old)
-  a) Activate — start working on it now
-  b) Abandon — mark as abandoned
-  c) Defer to agent: implement | research | ideate
-  d) Auto — go fully autonomous (invokes plastic-auto)
-```
-
-When the user activates a future intent, move it to `## Active` in INDEX.md and auto-commit.
-
-## References
-
-- Read `references/context-management.md` for the full save/continue protocol and for
-  debugging the resume flow.
+Then hand off to the chosen skill. Do not inline any of the routed skill's own work here -
+that belongs to the routes.