@zalom/plastic 1.0.0-alpha.3 → 1.0.0-alpha.31

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

@@ -0,0 +1,60 @@
+# Agent Architecture
+
+## Main Orchestrator
+
+The Main Orchestrator manages the global store (Main Knowledge Base). It:
+- Recognizes, creates, updates, and groups intents
+- Spawns Project Orchestrators for registered projects
+- Receives contributions back from Project Orchestrators
+- Is the only agent that runs in a loop (continuous Build→Observe→Repeat)
+
+## Project Orchestrators
+
+Project Orchestrators manage project stores (Project Knowledge Bases). They:
+- Care about intents and execution within their project
+- Spawn teams to develop and execute intents
+- Contribute back to the Main Orchestrator when new intents are born
+  that could enrich the Main Knowledge Base
+
+Rules:
+- 1 Main Orchestrator : 1 Global Store (`~/.plastic/`)
+- 1 Main Orchestrator : N Project Orchestrators
+- 1 Project Orchestrator : 1 Project Store
+- 1 Agent : 1 Intent (exclusive assignment)
+- 1 Agent : N Sub-agents (for parallel Actions within an intent)
+
+## Two Modes
+
+- **Human-driven:** Human chats with Main Orchestrator, creates intents,
+  brainstorms, then Main Orchestrator dispatches Project Orchestrators and
+  Agents for execution.
+- **Autonomous:** Human gives Main Orchestrator a starting intent with defined
+  outcomes. Main Orchestrator runs the full cycle — Agents do the lifecycle
+  (What→Why→How→Exec), Main Orchestrator reviews Insights, spawns next intents,
+  dispatches again.
+
+## Autonomous Delivery
+
+Human owns What and Why for human-initiated intents. Agent assists (research,
+exploration) but human drives until handoff. When Why is complete — or human
+triggers `plastic-auto` — the agent takes over How and Exec autonomously.
+
+- **Safe-by-default:** Agent always prefers non-destructive routes (rename vs
+  delete, additive migrations, backups before changes). Destructive actions on
+  existing projects require human approval unless `--skip-permissions` is set.
+- **One agent per intent.** Agent follows the full W→W→H→E lifecycle.
+- **Notification only on:** finish or hard stop (blocked on destructive action,
+  unresolvable error). No progress reports — `## Insights` tracks everything.
+- **Greenfield autonomy:** During initial project creation, all decisions are
+  non-destructive (nothing to destroy). Agent has full autonomy for greenfield choices.
+- **Autonomous decisions** are logged in `## Insights` with `(autonomous)` marker.
+
+## Coordinator Loop
+
+When "work on Project X":
+1. Read `projects.yml` → find project path
+2. Load global config (defaults)
+3. Load project config (overrides)
+4. Load global INDEX.md → find hub intents tagged `project-<name>`
+5. Load project INDEX.md → tactical intents
+6. Coordinator has full picture, dispatches Agent teams

package/skills/brainstorming/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: plastic-brainstorming
+description: "Explore intent requirements and design before implementation. Produces spec.md in the active intent directory."
+---
+
+# Brainstorming Ideas Into Designs
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Announce: "I'm using the brainstorming skill to explore the design for intent {id} — {name}."
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
+
+<HARD-GATE>
+Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
+</HARD-GATE>
+
+## Active Intent Gate
+
+Before proceeding, resolve the active intent:
+
+1. **Detect store:** Read `~/.plastic/projects.yml`, match CWD against registered project paths. If match → project store at `~/.plastic/projects/{slug}/store/`. If no match → global store at `~/.plastic/store/`.
+2. **Find active intent:** Read `INDEX.md` from the detected store. Look under `## Active`. If exactly one → use it. If multiple → ask which. If none → refuse: "No active intent. Create one first with /plastic-creating-intent"
+3. **Resolve intent directory:** `{store}/store/{id}--{slug}/`
+
+All artifacts go to the intent directory. Never write to external paths.
+
+## Anti-Pattern: "This Is Too Simple To Need A Design"
+
+Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
+
+## Checklist
+
+You MUST create a task for each of these items and complete them in order:
+
+1. **Explore project context** — check files, docs, recent commits, read active intent
+2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
+3. **Propose 2-3 approaches** — with trade-offs and your recommendation
+4. **Present design** — in sections scaled to their complexity, get user approval after each section
+5. **Write spec** — save to `{intent_dir}/spec.md` and commit to store repo
+6. **Spec self-review** — placeholder scan, consistency, scope, ambiguity
+7. **User reviews written spec** — ask user to review before proceeding
+8. **Transition to planning** — invoke `plastic-writing-plans`
+
+## Process Flow
+
+```dot
+digraph brainstorming {
+    "Explore project context" [shape=box];
+    "Ask clarifying questions" [shape=box];
+    "Propose 2-3 approaches" [shape=box];
+    "Present design sections" [shape=box];
+    "User approves design?" [shape=diamond];
+    "Write spec" [shape=box];
+    "Spec self-review\n(fix inline)" [shape=box];
+    "User reviews spec?" [shape=diamond];
+    "Invoke plastic-writing-plans" [shape=doublecircle];
+
+    "Explore project context" -> "Ask clarifying questions";
+    "Ask clarifying questions" -> "Propose 2-3 approaches";
+    "Propose 2-3 approaches" -> "Present design sections";
+    "Present design sections" -> "User approves design?";
+    "User approves design?" -> "Present design sections" [label="no, revise"];
+    "User approves design?" -> "Write spec" [label="yes"];
+    "Write spec" -> "Spec self-review\n(fix inline)";
+    "Spec self-review\n(fix inline)" -> "User reviews spec?";
+    "User reviews spec?" -> "Write spec" [label="changes requested"];
+    "User reviews spec?" -> "Invoke plastic-writing-plans" [label="approved"];
+}
+```
+
+**The terminal state is invoking `plastic-writing-plans`.** Do NOT invoke any other implementation skill. The ONLY skill you invoke after brainstorming is `plastic-writing-plans`.
+
+## The Process
+
+**Understanding the idea:**
+- Check out the current project state first (files, docs, recent commits)
+- Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
+- If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
+- For appropriately-scoped projects, ask questions one at a time to refine the idea
+- Prefer multiple choice questions when possible, but open-ended is fine too
+- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- Focus on understanding: purpose, constraints, success criteria
+
+**Exploring approaches:**
+- Propose 2-3 different approaches with trade-offs
+- Present options conversationally with your recommendation and reasoning
+- Lead with your recommended option and explain why
+
+**Presenting the design:**
+- Once you believe you understand what you're building, present the design
+- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
+- Ask after each section whether it looks right so far
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+**Design for isolation and clarity:**
+- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently
+- For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?
+- Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.
+- Smaller, well-bounded units are also easier for you to work with - you reason better about code you can hold in context at once, and your edits are more reliable when files are focused. When a file grows large, that's often a signal that it's doing too much.
+
+**Working in existing codebases:**
+- Explore the current structure before proposing changes. Follow existing patterns.
+- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design - the way a good developer improves code they're working in.
+- Don't propose unrelated refactoring. Stay focused on what serves the current goal.
+
+## After the Design
+**Documentation:**
+- Write the validated design (spec) to `{intent_dir}/spec.md` using the `${CLAUDE_PLUGIN_ROOT}/templates/spec.md` form
+- Use elements-of-style:writing-clearly-and-concisely skill if available
+- Commit to the store repo:
+  ```
+  cd {store_root} && git add . && git commit -m "docs: spec for intent {id} — {name}"
+  ```
+
+**Spec Self-Review:**
+After writing the spec document, look at it with fresh eyes:
+1. **Placeholder scan:** Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
+2. **Internal consistency:** Do any sections contradict each other? Does the architecture match the feature descriptions?
+3. **Scope check:** Is this focused enough for a single implementation plan, or does it need decomposition?
+4. **Ambiguity check:** Could any requirement be interpreted two different ways? If so, pick one and make it explicit.
+
+Fix any issues inline. No need to re-review — just fix and move on.
+
+**User Review Gate:**
+After the spec review loop passes, ask the user to review the written spec before proceeding:
+> "Spec written and committed to `{intent_dir}/spec.md`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
+
+Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.
+
+**Implementation:**
+- Invoke `plastic-writing-plans` to create the implementation plan
+- Do NOT invoke any other skill. `plastic-writing-plans` is the next step.
+
+## Key Principles
+
+- **One question at a time** - Don't overwhelm with multiple questions
+- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs
+- **Explore alternatives** - Always propose 2-3 approaches before settling
+- **Incremental validation** - Present design, get approval before moving on
+- **Be flexible** - Go back and clarify when something doesn't make sense

package/skills/brainstorming-grill-me/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plastic:brainstorming-grill-me
+name: plastic-brainstorming-grill-me
 description: >-
   Deep brainstorming that interviews the user relentlessly about a plan or design until reaching shared understanding.
   Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
@@ -83,18 +83,18 @@ If ALL items pass, offer autonomous delivery:
 >
 > Want to grill more, or should I go autonomous?"
 
-- If human says go → invoke `plastic:auto`
+- If human says go → invoke `plastic-auto`
 - If human says grill more → continue grilling (reset to step 2)
 - If human says neither (wants to drive manually) → proceed as before (offer planning)
 
 This offer replaces the final question in Close Out ("Ready to plan implementation, or do you want another pass?"). The new options are:
-1. Go autonomous (`plastic:auto`)
+1. Go autonomous (`plastic-auto`)
 2. Grill more (continue interrogation)
 3. Plan manually (invoke `superpowers:writing-plans` or proceed with human-driven planning)
 
 ## Relationship to superpowers:brainstorming
 
-| | superpowers:brainstorming | plastic:brainstorming-grill-me |
+| | superpowers:brainstorming | plastic-brainstorming-grill-me |
 |---|---|---|
 | Speed | Quick (5-10 min) | Thorough (20-45 min) |
 | Depth | Surface-level exploration | Exhaustive decision tree |
@@ -102,4 +102,4 @@ This offer replaces the final question in Close Out ("Ready to plan implementati
 | Output | Initial spec | Battle-tested spec with all branches resolved |
 | Style | Collaborative, exploratory | Interrogative, relentless |
 
-Use `superpowers:brainstorming` to generate ideas. Use `plastic:brainstorming-grill-me` to pressure-test them.
+Use `superpowers:brainstorming` to generate ideas. Use `plastic-brainstorming-grill-me` to pressure-test them.

package/skills/continuing/SKILL.md

@@ -1,104 +1,114 @@
 ---
-name: plastic:continuing
-description: Use when the user says "continue" after a /clear, or when resuming work in a new session. Reads intent state from global store (~/.plastic/) or local store, offers active intents first, then future intents, and surfaces stale intents for triage.
+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).
 ---
 
 # Continuing
 
+`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).
+
+**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]]).
+
 ## When to Use
 - UserPromptSubmit hook detects "continue" (automatic)
 - User says "continue", "resume", or "pick up where we left off"
-- Starting a new session with existing active intents
+- Starting a new session and you want to resume work with the latest context
 
 ## Determine Store
 
-1. Check `~/.plastic/INDEX.md` → global mode
-2. 
-3. If neither exists → announce "No Plastic store found. Run /plastic:install."
-
-## Workflow
-
-### 1. Read INDEX.md
-Read the INDEX.md from the active store. Extract intents under `## Active` and `## Future`.
-
-### 2. Detect Current Project (global mode only)
-Read `~/.plastic/projects.yml`, match CWD against registered project paths. If in a project:
-- Load the governing intent (from `parent` in projects.yml)
-- Load tactical intents from `~/.plastic/projects/{slug}/store/`
-
-### 3. If Active Intents Exist → Resume
-
-For each active intent in the store:
-
-**a. Read `{ID}--{slug}.md`:**
-- What we're doing (`## Intent`)
-- Why (`## Context`)
-- What insights have emerged (`## Insights`)
-
-**b. Read savepoint.md** (if exists):
-- What was in progress, what's next, blockers
-
-**c. Read checklist.md** (if exists):
-- What's completed, what's next
-
-**d. Announce:**
-```
-Resuming intent [ID] — [name]
-Store: [global | project:<slug> | local]
-Status: active
-Last session: [date from savepoint]
-In progress: [from savepoint]
-Next step: [from checklist or savepoint]
-Blockers: [from savepoint, or "none"]
-```
-
-**e. Resume** — proceed with the next step.
-
-### 3b. Detect Autonomous Resume
-
-When resuming an active intent, check `## Insights` for entries containing `(autonomous)`.
-
-If found — this intent was being delivered autonomously:
-
-**Announce:**
-```
-Resuming autonomous delivery of intent [ID] — [name]
-Store: [global | project:<slug> | local]
-Last autonomous action: [last (autonomous) insight entry]
-Next step: [from checklist or savepoint]
-```
-
-**Then:** Continue autonomous execution by invoking `plastic:auto`. The auto skill will pick up from the current lifecycle stage (it reads filesystem state to determine where to resume).
-
-If NOT found — resume normally as described in step 3.
-
-### 4. If No Active Intents → Offer Future Intents
-
-Present future intents as options. When user picks one, move to Active in INDEX.md. Auto-commit.
-
-### 5. Surface Stale Future Intents
-
-If any future intent has `created` date older than the configured `stale_threshold_days` (default 3):
+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."
+
+## 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). 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. For that intent's directory:
+
+1. **Read `savepoint.md`.** It is a deterministic, append-only stage ledger (one line per
+   milestone, newest at the bottom): `{utc-iso8601}  {Stage}  {milestone}`. The **last line =
+   current stage**.
+2. **Verify the stage file.** Confirm the file the ledger names exists and is non-empty
+   (ledger `How  plan.md created` → `plan.md` must be present and non-empty).
+3. **Drift handling.** If the ledger's last line disagrees with files-on-disk, rebuild the
+   ledger from filesystem state and note the correction:
+   ```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)
-  Options:
   a) Activate — start working on it now
   b) Abandon — mark as abandoned
-  c) Defer to agent:
-     - implement: agent builds it
-     - research: agent investigates feasibility
-     - ideate: agent explores the problem space
-  d) Auto — go fully autonomous (invokes plastic:auto — agent delivers the intent end-to-end)
+  c) Defer to agent: implement | research | ideate
+  d) Auto — go fully autonomous (invokes plastic-auto)
 ```
 
-Auto-commit all triage changes.
+When the user activates a future intent, move it to `## Active` in INDEX.md and auto-commit.
 
-### 6. Priority Order
+## References
 
-1. **Active intents first** — resume work in progress
-2. **Project context** — if in a registered project, show governing intent + tactical intents
-3. **Stale future intents** — surface for triage
-4. **Fresh future intents** — offer as next work
+- Read `references/context-management.md` for the full save/continue protocol and for
+  debugging the resume flow.

package/skills/continuing/evals/evals.json

@@ -0,0 +1,136 @@
+{
+  "skill_name": "plastic-continuing",
+  "notes": "Intent 36, updated for 36a (boot moved into hook-session-start; the skill is now work-continuation only). Scopes: description triggering (1-8) and behavior/convention compliance of the work-continuation skill (9-14). Triggering assertions follow the plastic-auto eval style (one subagent router per case). Behavior assertions are convention checks against the SKILL.md.",
+  "results": {
+    "triggering": { "cases": 8, "passed": 8, "run": "2026-06-16, one subagent per case" },
+    "behavior": { "cases": 6, "passed": 6, "evidence": "convention checks against skills/continuing/SKILL.md after the intent-36 rewrite; doctor --core verified at 0.07s with 9 liveness checks and full doctor unchanged at 30 checks" }
+  },
+  "evals": [
+    {
+      "id": 1, "scope": "triggering", "set": "train",
+      "prompt": "continue",
+      "expected_output": "Activates plastic-continuing (the bare 'continue' keyword is the documented trigger).",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-continuing", "observed": "plastic-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 2, "scope": "triggering", "set": "train",
+      "prompt": "resume where we left off",
+      "expected_output": "Activates plastic-continuing.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-continuing", "observed": "plastic-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 3, "scope": "triggering", "set": "validation",
+      "prompt": "pick up where we left off in this project",
+      "expected_output": "Activates plastic-continuing.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-continuing", "observed": "plastic-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 4, "scope": "triggering", "set": "train",
+      "prompt": "boot plastic and show me where things stand",
+      "expected_output": "Activates plastic-continuing (continuing work + presenting state is the skill's purpose; boot itself is hook-owned).",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-continuing", "observed": "plastic-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 5, "scope": "triggering", "set": "train",
+      "prompt": "continue delivering this intent autonomously, don't ask me",
+      "expected_output": "Does NOT settle on plastic-continuing for execution. Shares 'continue' but the autonomous-delivery intent routes to plastic-auto.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-auto", "observed": "plastic-auto", "result": "pass" }
+      ]
+    },
+    {
+      "id": 6, "scope": "triggering", "set": "validation",
+      "prompt": "continue the for-loop to the next iteration in this function",
+      "expected_output": "Does NOT activate plastic-continuing. Near-miss: shares 'continue' but is a code-editing task.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE != plastic-continuing", "observed": "none", "result": "pass" }
+      ]
+    },
+    {
+      "id": 7, "scope": "triggering", "set": "train",
+      "prompt": "resume the paused background download",
+      "expected_output": "Does NOT activate plastic-continuing. Near-miss: shares 'resume' but is unrelated to Plastic sessions.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE != plastic-continuing", "observed": "none", "result": "pass" }
+      ]
+    },
+    {
+      "id": 8, "scope": "triggering", "set": "validation",
+      "prompt": "what's the dashboard look like right now",
+      "expected_output": "May activate plastic-dashboard rather than plastic-continuing; an overview request without 'continue/resume' is a dashboard task.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE != plastic-continuing", "observed": "plastic-dashboard", "result": "pass" }
+      ]
+    },
+    {
+      "id": 9, "scope": "behavior", "set": "train",
+      "prompt": "Does the skill defer boot to the SessionStart hook rather than running it itself?",
+      "expected_output": "SKILL.md states boot (health check, core context, version banner, statusline) is owned by hook-session-start / plastic-statusline, not this skill.",
+      "files": ["skills/continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "SKILL.md says boot is owned by the SessionStart hook and the skill does not run it", "observed": "'Boot is not this skill's job.' paragraph naming hook-session-start and plastic-statusline", "result": "pass" }
+      ]
+    },
+    {
+      "id": 10, "scope": "behavior", "set": "train",
+      "prompt": "Does the skill avoid running doctor / setting the statusline itself?",
+      "expected_output": "SKILL.md does NOT instruct running doctor.rb --core or setting the statusline; it attributes those to the hooks.",
+      "files": ["skills/continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "no in-skill boot step invokes doctor.rb --core or sets the statusline; both are attributed to hooks", "observed": "doctor --core and statusline mentioned only as hook-owned in the 'Boot is not this skill's job' note", "result": "pass" }
+      ]
+    },
+    {
+      "id": 11, "scope": "behavior", "set": "train",
+      "prompt": "Is dashboard selection project-aware?",
+      "expected_output": "Project loaded -> `dashboard.rb project <slug>`; otherwise -> `dashboard.rb continue`. Skill only invokes, does not render.",
+      "files": ["skills/continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "both dashboard invocations present and gated on project detection", "observed": "'dashboard.rb project <slug>' and 'dashboard.rb continue' in the 'Continue (present the dashboard)' section", "result": "pass" }
+      ]
+    },
+    {
+      "id": 12, "scope": "behavior", "set": "validation",
+      "prompt": "Is ledger-resume conditional and ledger-driven?",
+      "expected_output": "Resume fires only when a specific intent is named; reads savepoint.md last line as stage, verifies the stage file, rebuilds on drift, derives next step from first unchecked checklist item.",
+      "files": ["skills/continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "Conditional Ledger-Resume section reads last ledger line, verifies stage file, calls rebuild_savepoint on drift, uses first unchecked checklist item", "observed": "all four present in 'Conditional Ledger-Resume'", "result": "pass" }
+      ]
+    },
+    {
+      "id": 13, "scope": "behavior", "set": "validation",
+      "prompt": "Are the stale prose-savepoint fields gone?",
+      "expected_output": "No 'In progress' / 'Blockers' fields read from a prose savepoint remain; the ledger model is used instead.",
+      "files": ["skills/continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "no prose-savepoint announce template (In progress / Blockers from prose)", "observed": "absent; announce uses Stage/Next step/Context/Drift derived from ledger + checklist", "result": "pass" }
+      ]
+    },
+    {
+      "id": 14, "scope": "behavior", "set": "validation",
+      "prompt": "Is the 'Determine Store' local-store gap filled?",
+      "expected_output": "Step 2 of Determine Store describes local/project-store detection (no empty step).",
+      "files": ["skills/continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "Determine Store step 2 documents local/project store detection via projects.yml + CWD match", "observed": "filled", "result": "pass" }
+      ]
+    }
+  ]
+}

package/skills/continuing/references/context-management.md

@@ -0,0 +1,32 @@
+# Context Management (Start-Save-Continue)
+
+## Save Point
+Triggered by PreCompact hook or manually:
+1. Find active intent(s) from `~/.plastic/INDEX.md`
+2. Update active intent's `checklist.md` (check off completed items)
+3. Update active intent's `savepoint.md` (in-progress, next steps, blockers, discoveries)
+4. Add observations to `## Insights`
+5. Update INDEX.md
+6. Commit: `cd ~/.plastic && git add . && git commit -m "chore: savepoint — [intent name]"`
+7. Notify user to `/clear`
+
+## Continue
+Triggered by UserPromptSubmit hook when user says "continue". Priority order:
+
+**1. Active intents first (resume work):**
+1. Read INDEX.md → find active intent(s)
+2. Read active intent's `intent.md` → what and why
+3. Read active intent's `savepoint.md` → where we left off
+4. Read active intent's `checklist.md` → what's next
+5. Announce: intent name, current state, next step, blockers
+6. Resume
+
+**2. No active intents → offer future intents:**
+1. List all future intents from INDEX.md
+2. Present them as options
+3. When user picks one, move to Active in INDEX.md
+
+**3. Stale future intents (untouched 3+ days) → triage:**
+- **activate** — start working on it now
+- **abandon** — mark as abandoned
+- **defer to agent** — implement, research, or ideate