@zalom/plastic 2.0.0-alpha.9 → 2.0.2

package/skills/feedback/SKILL.md

@@ -1,98 +0,0 @@
----
-name: plastic-feedback
-description: Use when the user hits a Plastic quirk, bug, or feature idea in a project and wants to report it back to the Plastic project. Builds a sanitized report file and a prefilled GitHub issue URL the user reviews and submits. Only the user sends.
-disable-model-invocation: true
-user-invocable: true
----
-
-# Plastic Feedback
-
-Turn a described Plastic problem into a local report file and a prefilled GitHub
-issue URL. The script does the mechanics (redaction, naming, URL building); the
-user alone opens the URL and submits it. This skill has no send step, by design.
-
-Because `disable-model-invocation` hides this skill's description from your own
-context, you cannot discover it by browsing available skills mid-task. If the
-user hits a Plastic quirk, bug, or missing feature, offer to run
-`/plastic-feedback` yourself; do not wait for the user to ask for it by name.
-
-## Procedure
-
-### 1. Gather the narrative
-
-Ask the user for:
-- What happened (the observed behavior).
-- The root cause, if they already know it.
-- The expected behavior.
-
-Keep it to about one page. Do not pad it with speculation; a short, accurate
-report beats a long, padded one.
-
-### 2. Obfuscate before it leaves this session
-
-Before filling the template, strip anything that identifies the user's project
-or its content:
-- Remove project names, directory paths, and file names specific to the user's
-  codebase.
-- Turn any Plastic intent names into their bare numeric or slug ids (drop the
-  descriptive title if it leaks project context).
-- Keep only Plastic's own operational content: what Plastic did, what it should
-  have done, which command or hook was involved.
-
-Read `references/transport-and-privacy.md` before filling the template, for the
-full obfuscation checklist and the reasoning behind it.
-
-### 3. Fill the report template
-
-Read `report.md` from this skill's directory (`~/.plastic/skills/feedback/report.md`
-at runtime, or the plugin source `skills/feedback/report.md` during development).
-Fill every placeholder except `{{plastic_version}}`, which the script fills.
-Assemble the final markdown body from the filled template.
-
-### 4. Run the script
-
-```bash
-ruby ~/.plastic/scripts/feedback-report --title "<short title>"
-```
-
-Pipe the filled body on STDIN. Parse the JSON on stdout:
-
-| Key | Meaning |
-|---|---|
-| `report_path` | Local file the full, uncapped report was written to |
-| `url` | Prefilled GitHub new-issue URL |
-| `encoded_url_bytes` | Byte length of the encoded URL |
-| `truncated` | Whether the URL body is a capped page-one, not the full report |
-| `page_break_note` | The end-marker text appended when `truncated` is true, else null |
-
-The script only ever writes a local file and prints a URL. It has no network
-call, no token, and no way to open a browser or submit anything on its own.
-
-### 5. Present the result
-
-Show the user:
-- The local file path (`report_path`).
-- A short preview of the report.
-- The URL.
-
-If `truncated` is true, tell the user plainly: the URL carries page one of the
-report, and the full report is in the local file at `report_path`. They can
-paste more from the local file into the opened issue if they want.
-
-Then tell them, in these words or close to them: open the URL, review it, drag
-a screenshot onto the form if they have one, and submit it under their own
-GitHub account. Or, if they would rather edit first, copy the local file
-contents into a new issue themselves.
-
-### 6. Never submit
-
-State plainly that this skill has no send step: it never posts to GitHub, never
-runs `gh issue create`, and never opens a browser on the user's behalf. The user
-is the only one who can submit the report.
-
-## Gotchas
-
-- If the described report is long, the script may hand back `truncated: true`.
-  This is expected, not an error: the local file always holds the full text.
-- Do not try to route around the missing send step (no `gh` call, no API POST).
-  The absence of a send path is the point of this skill, not a gap to fill.

package/skills/feedback/references/transport-and-privacy.md

@@ -1,65 +0,0 @@
-# Transport and Privacy
-
-Read this before filling `report.md` and before presenting the URL to the user.
-
-## Obfuscation checklist (do this before filling the template)
-
-Run through this list on the narrative gathered from the user, before it goes
-into `report.md`:
-
-- Strip project names. Refer to "the project" or "a consumer project", never
-  the user's actual project name.
-- Strip file paths and directory names specific to the user's codebase.
-- Turn Plastic intent names into their bare ids. Drop the descriptive title if
-  it names project content (an intent title like "Fix the checkout flow" leaks
-  what the user is building; "intent 42" does not).
-- Keep only Plastic's own operational content: which command, hook, or skill
-  ran, what it did, what it should have done instead.
-- Before presenting the URL, re-read the filled report once and confirm none
-  of the above slipped back in.
-
-## Mechanical redaction (what the script also strips)
-
-`scripts/lib/feedback_report.rb` redacts these patterns to `[REDACTED]` before
-the report ever touches disk, as a second, mechanical layer under the
-obfuscation above:
-
-| Secret kind | Pattern shape |
-|---|---|
-| GitHub tokens | `ghp_`, `gho_`, `ghs_`, `ghr_`, `ghu_`, `github_pat_` prefixes |
-| Anthropic/OpenAI keys | `sk-ant-...`, `sk-...` |
-| AWS access key id | `AKIA...` |
-| Bearer tokens | `Bearer <token>` |
-| Slack tokens | `xoxb-`, `xoxa-`, `xoxp-`, `xoxr-`, `xoxs-` prefixes |
-| Google API keys | `AIza...` |
-| PEM private key blocks | `-----BEGIN ... PRIVATE KEY----- ... -----END ... PRIVATE KEY-----` |
-| Key/value assignments | `api_key = ...`, `secret: ...`, `token = ...`, `password: ...` (value only) |
-
-Treat this list as a safety net, not the primary defense. The mechanical
-patterns catch a specific, known shape; the obfuscation pass above is what
-catches project-identifying context a regex cannot recognize.
-
-## Why a prefilled URL, and not something else
-
-The report is sent by opening a prefilled `https://github.com/zalom/plastic/issues/new`
-URL in the user's own browser. Submission happens in an authenticated session
-that belongs to the user, not to the agent or the script. Nothing in this
-skill or in `feedback-report` can complete that submission on its own: there
-is no send method, no token, and no network call anywhere in the code path.
-
-Other transports were considered and rejected:
-
-- **`gh issue create`**: the CLI can send on its own; only `--web` is
-  browser-submitted, and the plain form cannot be guaranteed not to send
-  directly. It also assumes `gh` auth, which a consumer-project user may not
-  have.
-- **An API POST with a token**: the agent could send it, and the token itself
-  becomes a credential worth stealing.
-- **An anonymous POST endpoint**: still agent-reachable, with no built-in spam
-  resistance, and it needs server infrastructure this project does not run.
-- **Email or `git send-email`**: the CLI sends the message, review is opt-in
-  rather than forced, and it needs a working mail transport most machines do
-  not have configured.
-
-Only the prefilled-URL approach makes "the agent cannot send" a structural
-fact instead of a rule the agent could break by taking a shortcut.

package/skills/feedback/report.md

@@ -1,36 +0,0 @@
-# Plastic feedback: {{title}}
-
-<!-- =======================================================================
-  AGENT INSTRUCTIONS -- How to fill this template
-  =========================================================================
-  1. Replace every {{placeholder}} below with real content gathered from the
-     user, except {{plastic_version}}: leave that token exactly as written,
-     the feedback-report script fills it from the installed VERSION file.
-  2. Obfuscate first (see references/transport-and-privacy.md): strip project
-     names, file paths, and anything else that identifies the user's
-     codebase. Keep only Plastic's own operational content.
-  3. Keep the report to about one page. Use tables or short lists where they
-     make the report clearer than prose.
-  4. Delete this entire HTML comment block before piping the body into
-     feedback-report. It is fill instructions only, not report content.
-  ======================================================================= -->
-
-## Environment
-
-| Field | Value |
-|---|---|
-| Plastic version | {{plastic_version}} |
-| Agent | {{agent_name}} |
-| OS | {{os}} |
-
-## What happened
-
-{{what_happened}}
-
-## Root cause (if known)
-
-{{root_cause_or_not_known}}
-
-## Expected behavior
-
-{{expected_behavior}}

package/skills/install/SKILL.md

@@ -1,217 +0,0 @@
----
-name: plastic-install
-description: 'Use when initializing Plastic globally (~/.plastic/) or locally in a project, or to re-install/repair a broken installation. The package pin selects the channel (@latest, @beta, @alpha; the channel flags were removed in 2.0). First install defaults to @latest (stable); reinstalls match the already-installed channel. Global install is recommended: it creates the global intent store as a git-backed repository. Local install creates .plastic/ in the current project for testing.'
-user-invocable: true
----
-
-# Install Plastic
-
-> **Recommended path:** for a first install, run `npx -y @zalom/plastic@latest install --claude`
-> in your shell (or `bunx -y @zalom/plastic@latest install --claude` if you use Bun). This skill
-> exists to **re-install or repair** an existing setup from inside the agent, and to
-> drive interactive global configuration. Whenever this skill performs an install or
-> re-install, it **runs `/plastic-doctor` afterward** and reports the result.
-
-## Channel rule
-
-If Plastic is installed, derive `<channel>` from `~/.plastic/VERSION`: a version containing
-`-alpha` means `@alpha`, `-beta` means `@beta`, otherwise `@latest`. If not installed
-(first install), default to `@latest`. To change channel, pin the package instead of
-passing a flag: `npx -y @zalom/plastic@alpha install --claude` (or a version such as
-`@2.0.0-alpha.1`); the `--alpha`, `--beta`, and `--latest` flags were removed in 2.0
-(intent 310) because they never selected a package.
-
-## Re-install / repair
-
-If Plastic is already installed but something is broken (skills missing, hooks not
-firing, leftover legacy plugin), re-run the installer, it is idempotent, prunes
-files that no longer ship, and removes any legacy plugin/marketplace layout:
-
-```bash
-npx -y @zalom/plastic@<channel> install --reinstall --claude
-```
-
-Then **run `/plastic-doctor`** and report what it found.
-
-## Channels
-
-| Package | Channel |
-|---------|---------|
-| `@zalom/plastic@latest` | stable (default on a first install) |
-| `@zalom/plastic@beta` | beta |
-| `@zalom/plastic@alpha` | alpha; `npx -y @zalom/plastic@alpha install --claude` is the 2.0 alpha path |
-
-When invoked from within Claude Code (re-install or channel switch), the skill
-runs the appropriate npx command:
-
-```bash
-# Stable (default on a first install)
-npx -y @zalom/plastic@latest install --claude
-
-# Beta
-npx -y @zalom/plastic@beta install --claude
-
-# Alpha
-npx -y @zalom/plastic@alpha install --claude
-```
-
-The installed version and channel are recorded in `~/.plastic/VERSION`.
-
-## Modes
-
-### Global Install (default, recommended)
-
-Run `/plastic-install` with no arguments.
-
-#### Procedure
-
-**Step 1: Run the installer**
-
-Check if `~/.plastic/VERSION` exists.
-- If yes: announce "Plastic is already installed at ~/.plastic/. Run `/plastic-update` to
-  sync core files, or use the re-install command above to repair in place."
-- If no: first ask the advisor question below (Claude Code only), then run the fresh
-  install command (default `@latest`, or the channel the user named) with whichever
-  flags that answer produced:
-
-```bash
-npx -y @zalom/plastic@latest install --claude [--no-advisor] [--advisor VALUE]
-```
-
-This single command, via `install.rb` (`bootstrap` + `distribute`), creates `store/`,
-`projects/`, `config.yml`, `projects.yml`, `INDEX.md`, and `AGENTS.md` under `~/.plastic/`,
-and copies the utility scripts (`folgezettel-id`, `read-config`, and the rest of
-`scripts/`). This skill does none of that itself; it wraps the command with the
-interactive steps the CLI does not yet own, plus reporting and a doctor pass.
-
-**The advisor (Claude Code only)**
-
-Ask the user one feature question, interactive sessions only:
-> "Would you like an advisor agent for expensive reasoning: plan review, architecture
-> calls, second opinions, breaking deadlocks?"
-> - Yes (recommended) -> ask which advisor is the default, below
-> - No -> append `--no-advisor`
-
-If yes, ask which advisor is the default, exactly two choices:
-> "Which advisor should be the default?"
-> - **Faux Fable** (recommended): Opus 4.8 carrying the frontier reasoning
->   instructions. Much cheaper, available on any plan, reasons in the same
->   disciplined way. -> append `--advisor faux`
-> - **Fable 5**: the frontier model itself. The strongest reasoning available,
->   billed through usage credits, so summon it for a few rounds and close it. ->
->   append `--advisor real`
-
-Non-interactive sessions (no tty) skip the question entirely: the install ships with the
-shipped default, advisor enabled with no `--advisor` flag (the `plastic-agent-advisor`
-skill's own routing falls back to `plastic-faux-advisor` at consult time).
-
-Update flow: pending config questions, including this one, are now announced
-generically by `plastic-update`'s Step 2, sourced from `config_asks.yml` - not
-duplicated here. A value already set by either path is never re-asked by the
-other.
-
-**Statusline**
-
-On install, if an existing statusline is already configured, Plastic asks whether to
-keep it or switch to Plastic's (interactive sessions only). The choice is honored via
-`--statusline keep` or `--statusline plastic`, which skips the prompt. Non-interactive
-sessions (no tty) default to keeping the user's line: nothing is silently overwritten.
-A fresh system with no statusline configured gets Plastic's line with no prompt.
-
-**Step 2: Initialize git (retained)**
-
-Only if `~/.plastic/.git` is absent (a fresh bootstrap does not init git):
-
-```bash
-cd ~/.plastic && git init && git add . && git commit -m "chore: initialize Plastic global intent store"
-```
-
-Retained here because the CLI does not git-init the store yet (follow-up).
-
-**Step 3: Personalize config (retained)**
-
-Detect which agent is running:
-- If `CLAUDE_CODE` env var is set or we're running inside Claude Code -> `agent.type: claude-code`
-- If `HERMES_HOME` env var is set -> `agent.type: hermes`
-- Otherwise -> ask the user: "Which AI agent are you using? (claude-code / hermes / other)"
-
-Ask the user:
-> "Enable Agent Teams? (experimental: parallel project work with teammates)"
-> - Yes -> set `parallel_mode: agent-teams`
-> - No -> set `parallel_mode: linear` (subagents only)
-
-Inform the user:
-> "Plastic agents can create GitHub repositories for new projects. By default, all
-> agent-created repos are **private**. Your global intent store (~/.plastic/) is never
-> pushed, it stays local-only."
-
-Ask the user:
-> "Default visibility for agent-created repos?"
-> - Private (recommended) -> set `github.default_visibility: private`
-> - Public -> set `github.default_visibility: public`
->
-> "Allow agents to push to GitHub without asking?"
-> - No (recommended) -> set `github.auto_push: false`
-> - Yes -> set `github.auto_push: true`
->
-> "Where do you keep your projects? Default: ~/.plastic/projects/"
-> "Add additional roots? (e.g., ~/apps/personal/, ~/apps/companies/)"
-
-Write each answer via `read-config --migrate` first (ensures the v3 schema), then the
-chosen values; auto-commit each change. Retained here because the CLI writes only
-hardcoded defaults, so these interactive choices stay in the skill.
-
-**Step 4: Verify with doctor**
-
-Run `/plastic-doctor` and report the result. Resolve any fixable findings before
-announcing success.
-
-**Step 5: Register stores with QMD (retained)**
-
-QMD is an optional search layer. If it is installed, register the Plastic stores so
-they are searchable:
-
-```bash
-ruby ~/.plastic/scripts/qmd-sync detect && ruby ~/.plastic/scripts/qmd-sync register --all
-```
-
-`qmd-sync` no-ops cleanly when QMD is absent, so this is safe to run unconditionally.
-It registers `plastic-global` and every project store from `projects.yml`, then indexes
-them. Report what was registered, or that QMD was not detected and the step was skipped.
-Retained here because the CLI does not register at install time (follow-up).
-
-**Step 6: Report + announce**
-
-```
-Plastic install (<channel>)
-Command:  npx -y @zalom/plastic@<channel> install --claude <flags>
-Version:  none -> <installed>
-Doctor:   <summary or "all clear">
-```
-
-Then: "Read [`your-first-intent-in-10-minutes.md`](https://github.com/zalom/plastic/blob/main/docs/guides/your-first-intent-in-10-minutes.md) for your first intent, start to finish."
-
-### Local Install (testing/legacy)
-
-Run `/plastic-install --local`. `install.rb` has no `--local` verb, so this mode is
-genuinely skill-owned.
-
-#### Procedure
-
-**Step 1:** Check if `.plastic/` exists in CWD, if so, warn and exit.
-
-**Step 2:** Create `.plastic/` in CWD:
-- `config.yml` from templates
-- `INDEX.md` from templates
-- `store/` with `.gitkeep`
-
-**Step 3:** If global install exists (`~/.plastic/projects.yml`), register this project:
-- Determine project slug from directory name
-- Detect git remote URL if available
-- Add entry to `~/.plastic/projects.yml` with `parent: null`
-- Auto-commit in `~/.plastic/`
-
-**Step 4:** Commit in project: `git add .plastic/ && git commit -m "chore: initialize Plastic local store"`
-
-**Step 5:** Announce: "Plastic initialized locally. This is a testing/legacy mode. Consider
-`/plastic-install` for global mode."

package/skills/intent-continuing/SKILL.md

@@ -1,154 +0,0 @@
----
-name: plastic-intent-continuing
-description: >-
-  The front door for resuming work. Use when the user says "continue", "resume", "pick up
-  where we left off", "where was I", "what should I work on", names a specific intent to
-  resume (by id or description, or `--intent {id}`), or names a roadmap or delivery batch to
-  resume (`--roadmap {slug}`, "where is the roadmap", "where did that batch land"). Presents
-  state and resumes at the last delivered stage; it never asks auto or guided, never boots
-  (the SessionStart hook owns boot), and never drives work autonomously (plastic-auto does).
-  Absorbs the former continuing, project-continuing, and roadmap-continuing skills and the
-  read half of the former intent-starting skill (intent 304).
-user-invocable: true
----
-
-# Continuing: the front door for resuming work
-
-One skill with three routes. It reads state and presents it; the work itself continues in
-whatever mode the session is in (direct by default, `plastic-auto` when the owner says auto).
-There is no lock to take and no mode to ask here: locks exist only for auto teams, and the
-mode is the owner's word, not a question this skill puts.
-
-**Boot is not this skill's job.** `hook-session-start` runs on every session start: the core
-health check (`doctor --core`), `PLASTIC.md` and store or project state, the
-`Plastic Core loaded - v{version}` banner. By the time this skill runs, core is loaded and
-healthy or the banner already warned.
-
-## Route
-
-| Args or context | Route |
-|---|---|
-| `--intent {id}`, or the user names one specific intent to resume (by id or description) | Intent route (below) |
-| `--roadmap {slug}`, or the user asks to continue or resume a roadmap or delivery batch | Roadmap route (below) |
-| bare "continue", "resume", "what should I work on", or no target (the default) | Project route (below) |
-
-State the chosen route in one line before doing anything ("Landing on the project board: no
-specific intent or roadmap named.").
-
-## Determine store
-
-1. A project store under `~/.plastic/projects/{slug}/` whose registered path in
-   `~/.plastic/projects.yml` matches the working directory means project mode; the
-   SessionStart hook already detected this, the slug scopes the reads below.
-2. Otherwise the global store, `~/.plastic/store/`.
-3. Neither exists: announce "No Plastic store found. Run /plastic-install." and stop.
-
-## Project route: land on the board
-
-Land on the Markdown board through the `plastic-dashboard` skill; rendering belongs there.
-Run the data payload and fill the matching template:
-- project loaded: `ruby ~/.plastic/scripts/dashboard.rb project <slug> --data`
-- otherwise (the global fallback): `ruby ~/.plastic/scripts/dashboard.rb continue --data`
-
-Fill the template from `plastic-dashboard`'s `templates/` and present the filled Markdown in
-your reply, every time: tool-call stdout and hook context are invisible to the user. Read
-`references/board-fill.md` for the fill mechanics and the store-health line when filling the
-board. The board load runs the scoped store check (`doctor --store <scope>`); its result
-arrives in the payload as `store_health` and is shown as one line of data, never a blocker.
-
-Priority order on the board: active intents first, then project context (governing plus
-tactical intents in a registered project), then stale future intents for triage, then fresh
-future intents as next work. A future intent older than `stale_threshold_days` (default 3) is
-surfaced for triage without action: activate, abandon, or leave. Activating moves it to
-`## Active` in `INDEX.md` and auto-commits. The board's ranked next-work order is computed by
-`dashboard.rb`; cite the rule names only (Effort, Value, Flags, Override, Caps) and read
-`plastic-dashboard`'s `references/classification.md` for their definitions.
-
-When the tier root (the directory holding `INDEX.md`) has a mid-flight roadmap
-(`ruby ~/.plastic/scripts/roadmap-next --roadmaps-dir <root>/roadmaps` reports a `state`
-other than `none`), say so in one line and offer the roadmap route; the board still presents
-project state and stops.
-
-Then stop: "here is the state, what next?". Do not start executing work. When the user names
-an intent, take the intent route.
-
-## Intent route: resume one intent from its ledger
-
-QMD-first when the intent is named by description: run
-`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` to find the candidate, then open the
-authoritative intent file. The command is a no-op when QMD is absent; fall back to
-`INDEX.md`.
-
-If the intent is terminal (`## Completed` or `## Abandoned` in `INDEX.md`): print the
-intent screen (Status shows the terminal section, Next is empty), summarize its
-`outcome.md`, and ask what is next; never reopen it.
-
-For a live intent's directory:
-
-1. **Read `savepoint.md` first.** It is a deterministic, append-only ledger, one line per
-   event, newest at the bottom: `{utc-iso8601}  {Stage}  {milestone}`. Classify the stage
-   from the last line alone (the table in `references/boarding-matrix.md`, read when
-   classifying), then verify only that line's artifact is real (sentinel-aware:
-   `Savepoint.stage_file_present?`). Do not re-probe every lifecycle file.
-2. **Stale ledger.** When the last line disagrees with the files on disk, rebuild the ledger from
-   disk and note the correction. A rebuilt ledger is the file-landing skeleton, which still
-   pins the stage:
-   ```bash
-   ruby -r ~/.plastic/scripts/lib/savepoint -e 'Savepoint.rebuild_savepoint("<intent_dir>")'
-   ```
-3. **Read the hand-off.** The newest `~/.plastic/store/.sessions/<day>/handoff--*.md` (today,
-   else the newest prior day) is the prior session's own account of where things stand; read
-   it after the ledger, never instead of it.
-4. **Derive the next step:** the first unchecked item in `checklist.md` when it exists, else
-   the next thing the stage needs (see the matrix). The newest `## Insights` entry supplies
-   the human-readable context; an entry marked `(autonomous)` means an auto team was
-   delivering it, so say so and offer to hand back to `plastic-auto`.
-5. **Print the report screen as the first thing in the reply, then continue at that stage.**
-   The screen must open the message with nothing before it. On Claude Code, a fail-open
-   `MessageDisplay` hook recognizes a reply that opens this way and substitutes a styled ANSI
-   rendering for it there; the transcript and every other harness keep exactly this plain
-   form. For "where are we" on one named intent, run
-   `ruby ~/.plastic/scripts/report-screen state <intent_dir>` and print its output as it is:
-   the title, the field table, the `Changed` row, and the Steps table come from the record,
-   never by eye. For "where are we" with no intent named, run
-   `ruby ~/.plastic/scripts/report-screen state --all <store_root>` for the roster across every
-   in-delivery intent. Route "why did X take so long" to
-   `ruby ~/.plastic/scripts/report-screen delay <intent_dir>` instead - every verb prints the
-   same plain screen on any harness, painted only where the harness supports it, with no
-   branching on harness name. Under the `state` screen
-   write **What this means** as two to four bullets in plain words (what the intent is for,
-   what has landed, what is left, any defect named by step), then close with **needs input:**
-   naming the first open step. Then continue the work in the
-   session's current mode. In auto mode the running team already holds the delivery lock; if a
-   lock is held by a session that is gone, the `plastic-doctor` skill's lock section repairs or
-   reclaims it.
-
-## Roadmap route: resume the mid-flight roadmap
-
-1. Resolve the tier root (project or global) and run the shared reader in which mode:
-   ```bash
-   ruby ~/.plastic/scripts/roadmap-next --roadmaps-dir <root>/roadmaps --which
-   ```
-   Read `state` and the winning `roadmap`. A `tie` lists `tie_candidates` to present side by
-   side and let the user pick; never pick silently. The reader ranks liveness the way
-   `references/liveness-ranking.md` describes (read it when a ranking needs explaining): a
-   `delivering` or `blocked` entry wins, else the newest ledger or `## Log` timestamp.
-   `roadmaps/<slug>.savepoint.md` is a derived signal read here, never a status field;
-   `INDEX.md` stays the sole status writer.
-2. **Present state:** the roadmap's `## Goal`, the current batch with each entry's mirrored
-   status, the ledger's newest line beside the newest `## Log` line. Read
-   `../plastic-conventions/references/roadmaps.md` for the file format and the status-mirror
-   rule when a roadmap file needs interpreting.
-3. Then continue with the next dispatchable entry in the session's mode: direct work on it,
-   or `plastic-auto` when the owner says auto. The coordinator that drives a batch appends
-   to `roadmaps/<slug>.savepoint.md` at its dispatch, merge, park, and handoff points with
-   `ruby ~/.plastic/scripts/roadmap-savepoint append`; this skill only reads it.
-
-## References
-
-| Trigger | Read |
-|---|---|
-| Filling the board on the project route | `references/board-fill.md` |
-| Classifying the stage from the ledger's last line | `references/boarding-matrix.md` |
-| Explaining why one roadmap ranked above another | `references/liveness-ranking.md` |
-| Saving or restoring context across a long session, or debugging a resume | `references/context-management.md` |

package/skills/intent-continuing/references/board-fill.md

@@ -1,43 +0,0 @@
-# Board Fill Mechanics
-
-Depth reference for the "Continue (present the board)" section of `SKILL.md`. The fill itself
-is mechanical; `plastic-dashboard` owns the rules, this page is a pointer plus the detail that
-would otherwise bloat the SKILL.md body.
-
-## Fill rules (owned by plastic-dashboard, summarized here for convenience)
-
-- `{{a.b.count}}` -> the integer (e.g. `counts.active` is that count).
-- `{{<list>.rows}}` -> the two intent lists (`active`, `next_work`) render as Markdown table
-  rows. The template hard-codes each table's header and separator; the placeholder becomes one
-  data row per entry, in that table's fixed column order, cells dropped verbatim from the
-  payload (cells arrive pipe-escaped and whitespace-normalized; do not re-escape or
-  re-truncate). Column order per table:
-  - `next_work` -> `| id | what | value | disposition | flags_label |`
-  - `active` -> `| id | what | stage |`
-  Empty list -> one full-width row with `_(none)_` in the Id column, other cells blank, matching
-  that table's column count. Neither list carries an overflow "+N more" row (intent 202): the
-  true pool size rides on the payload (`active_total`/`next_total`, shown as
-  `active_shown`/`next_shown`), stated in prose by `{{footer}}` instead. Never emit `<br>`.
-- `{{projects.lines}}` (global board) -> the project rollup stays prose, one line per project.
-- Scalars (`{{date}}`, `{{slug}}`, `{{summary}}`, `{{footer}}`) -> substitute verbatim.
-  `summary` (the 2-3 sentence "what was delivered most recently") and `footer` (the
-  honest-totals + how-to-see-everything line) are finished prose built in `dashboard.rb`,
-  replacing the old recently-worked table and the raw future table respectively.
-
-No re-sorting, no re-summarizing, no hand-written prose replacing a line the payload already
-supplies. Same store state produces a byte-identical payload regardless of model.
-
-## Store-health surfacing
-
-Every board load runs the scoped `doctor --store <scope>` check server-side (inside
-`dashboard.rb`, not this skill). The payload carries the result as `store_health` (`{scope,
-status, summary, failing_checks}`). Render it as a single line, for example `store health:
-pass (3/3)` or `store health: warn (orphaned_intents)`. A warn or fail is informational only;
-it never blocks presenting the board.
-
-## Project vs. global fallback
-
-The project route's default target is the project board. When no project is loaded (the rare
-case where this route is reached without a registered project in scope), fall back to the
-global board payload (`dashboard.rb continue --data`) rather than failing. This mirrors the
-router's D6 default: a bare "continue" always lands somewhere useful.

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

@@ -1,34 +0,0 @@
-# Boarding matrix: which stage a resume lands at
-
-The stage is derived from `savepoint.md`'s last line plus the real artifacts on disk.
-Classify from the last line alone, then verify only that line's artifact is real
-(sentinel-aware). When the ledger is stale, rebuild it from disk and note it.
-
-| savepoint last line | latest delivered | lands at | continue with |
-|---|---|---|---|
-| `What  {id}--{slug}.md` (born) | What | **Why** | the thinking conversation (`plastic-intent-speccing`) or direct work |
-| `Why  started` (spec still sentinel) | What | **Why** | continue the conversation; rulings land as insights |
-| `Why  spec.md created` | Why | **How** | the action files, `plan.md`, `checklist.md` |
-| `How  started` / `How  plan.md created` | (How in progress) | **How** | finish `plan.md` and `checklist.md` |
-| `How  checklist.md created` / `Exec  started` | How | **Exec** | do the work, check off the checklist |
-| `Exec  outcome.md created` | Exec | **ready to complete** | the ending procedure (`plastic-intent-ending`) |
-| `Done  delivered` / `Done  abandoned` | terminal | **report only** | immutable; ask what is next |
-
-## Per-stage behaviour (what "continue" means)
-
-- **Why**: continue the conversation, or run the work directly when the request is already
-  clear; every ruling is recorded as it lands.
-- **How**: write or finish the action files, `plan.md`, and `checklist.md`.
-- **Exec**: verify what is delivered, then continue (or restart) the delivery or research.
-  The first unchecked `checklist.md` item is the next step; the newest `## Insights` entry
-  supplies the context.
-- **ready to complete**: `outcome.md` is real; run the ending procedure.
-- **Done**: terminal. Report the outcome, ask what is next. Never reopen; `INDEX.md` is
-  authoritative.
-
-## Notes
-
-- A Plastic 1.x ledger may carry a `Tier  <letter>` line under the `Why  spec.md created` line
-  (the intent tier was removed in 2.0, intent 304). It is inert: skip it when classifying.
-- An `## Insights` entry marked `(autonomous)` means an auto team was delivering the intent;
-  say so and offer to hand back to `plastic-auto`.