@zalom/plastic 1.0.0-alpha.2 → 1.0.0-alpha.21

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,129 @@
 ---
-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. Boots Plastic — runtime health check, loads core context + store/project state, prints version + statusline, and lands on the right dashboard — then presents choices. Does not drive work autonomously (that is plastic-auto).
 ---
 
 # Continuing
 
+`plastic-continuing` is a deterministic **boot orchestrator**. It loads and presents choices,
+then stops. It does NOT execute work autonomously (that is `plastic-auto`) and does NOT render
+the dashboard itself (it only invokes it).
+
 ## 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 with an existing Plastic store
 
 ## 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.
+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.
+   Project detection happens in boot step 2 below; this just records that a local store is
+   in play.
+3. If neither exists → announce "No Plastic store found. Run /plastic-install."
 
-### 3b. Detect Autonomous Resume
+## Boot Sequence (run in this fixed order)
 
-When resuming an active intent, check `## Insights` for entries containing `(autonomous)`.
+### 1. Core doctor (health first)
+Run the fast runtime-liveness check synchronously (it returns in well under a second):
 
-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]
+```bash
+ruby ~/.plastic/scripts/doctor.rb --core
 ```
 
-**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):
+Print one compact health line:
+- All pass → `Plastic core: healthy`
+- Otherwise → `Plastic core: issues` followed by the failing checks (name + message).
+
+This runs first so a broken runtime (missing hooks, scripts, core files) surfaces before any
+state is loaded on top of it. For a full diagnosis, point the user at `/plastic-doctor`.
+
+### 2. Load core (context + state)
+- Prime `PLASTIC.md` and the harness docs so the conventions are in mind.
+- Load live state:
+  - Read the active store `INDEX.md` (`## Active`, `## Future`).
+  - Read `~/.plastic/projects.yml`.
+  - **Detect the current project** by matching CWD against registered project paths.
+  - If in a project: load that project's `INDEX.md`; load the governing intent (from
+    `parent` in projects.yml) and the tactical intents from
+    `~/.plastic/projects/{slug}/store/`.
+
+### 3. Version + statusline
+- Print the current Plastic version (from `~/.plastic/VERSION`).
+- Set the statusline.
+
+### 4. Dashboard
+Invoke the dashboard. Rendering belongs to the dashboard skill, not here — only invoke:
+- Project loaded → `ruby ~/.plastic/scripts/dashboard.rb project <slug>`
+- Otherwise → `ruby ~/.plastic/scripts/dashboard.rb continue`
+
+Show its output verbatim. See `plastic-dashboard` for how to read the matrix.
+
+### 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. Scopes: description triggering (1-8) and behavior/convention compliance of the rewritten boot orchestrator (9-14). Triggering assertions follow the plastic-auto eval style (one subagent router per case). Behavior assertions are convention checks against the rewritten 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 (boot + present state is the skill's purpose).",
+      "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 document the four-step boot sequence in the fixed order?",
+      "expected_output": "SKILL.md lists, in order: (1) core doctor, (2) load core, (3) version + statusline, (4) dashboard.",
+      "files": ["skills/continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "boot steps appear in order doctor -> load core -> version/statusline -> dashboard", "observed": "headings '### 1. Core doctor', '### 2. Load core', '### 3. Version + statusline', '### 4. Dashboard'", "result": "pass" }
+      ]
+    },
+    {
+      "id": 10, "scope": "behavior", "set": "train",
+      "prompt": "Does step 1 run the fast core health check synchronously?",
+      "expected_output": "Step 1 invokes `doctor.rb --core` and prints a single health line.",
+      "files": ["skills/continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "SKILL.md contains 'doctor.rb --core' and a 'Plastic core: healthy' health line", "observed": "present in '### 1. Core doctor'", "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 '### 4. Dashboard'", "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

package/skills/creating-intent/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: plastic:creating-intent
+name: plastic-creating-intent
 description: Use when new work begins, the user expresses a new goal, says "new intent", or no active intent exists for the current task. Creates intents in the global store (~/.plastic/store/) or in a project's store (~/.plastic/projects/{slug}/store/) depending on context.
 ---
 
@@ -60,6 +60,16 @@ IDs are scoped to the store they live in. Use the correct store path:
 "${CLAUDE_PLUGIN_ROOT}/scripts/folgezettel-id" "<STORE>" "<parent_id>"
 ```
 
+**Branch vs root — decide before assigning the ID.** Having a "parent" in mind does
+NOT automatically mean branch. Choose by meaning:
+
+- **Branch (`14a`, `14b`)** — a sub-task, refinement, or direct continuation. It only
+  makes sense as part of the parent's work.
+- **Root (`15`, `16`)** — an independent thought, even if inspired by another intent.
+  Capture the inspiration in `sources` (e.g., `sources: ["14"]`), not in the ID.
+- **Rule of thumb:** if the intent could exist without its parent, make it a root and
+  set `sources`. Only branch when it genuinely cannot stand alone.
+
 ### 3. Determine Intent Properties
 
 Ask or infer from context:
@@ -120,3 +130,8 @@ cd <store-root> && git add . && git commit -m "feat: create intent ID — [name]
 ### 8. Announce
 
 "Created intent ID — [name]. Placed in: [Active|Future]. Store: [global|project:<slug>|local]."
+
+## 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