@zalom/plastic 2.0.0-alpha.27 → 2.0.0-alpha.29

package/skills/install/SKILL.md

@@ -1,215 +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?"
-> - **Primary Advisor** (recommended): Fable at medium effort for normal
->   consultation. -> append `--advisor primary`
-> - **Secondary Advisor**: Fable at high effort for explicit escalation. ->
->   append `--advisor secondary`
-
-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-primary-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,156 +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
-
-Print `ruby ~/.plastic/scripts/dashboard.rb project <slug> --screen` (or `continue --screen`
-for the global fallback) as the first characters of the reply: nothing before it, no fence, or
-the hook cannot paint it (intent 331d/331f). It carries a title, six fields (Active, In
-delivery, Delivered, Roadmap, Sessions, Changed), then the Where-we-are and Where-we-go-next
-tables. The board load runs the scoped store check (`doctor --store <scope>`); its result
-rides in the payload as `store_health` and prints as one line of data, never a blocker.
-
-Priority order on the underlying data: 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 screen 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. Read `references/board-fill.md` only when the reader asks
-for the deeper prose board (`plastic-dashboard`'s Markdown surface still exists for that ask).
-
-## 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 session <tier_root> --session <this session's id>`
-   (intent 330; pass the id your harness gives you, or the screen widens to the whole day and
-   says so): it prints one
-   `delivered` screen per intent this session actually completed, oldest first, then the same
-   roster `report-screen state --all <store_root>` prints on its own - `state --all` stays the
-   right call when only the in-flight roster is wanted, with nothing delivered above it. 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. **Print state.** Print `ruby ~/.plastic/scripts/report-screen roadmap <roadmap.md> state` as
-   the first characters of the reply: nothing before it, no fence, or the hook cannot paint it.
-   It carries Goal, Progress, Frontier, Delivering, Next, and Changed, then the entries table -
-   never hand-typed. 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,52 +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.
-
-## The screen surface (intent 331d)
-
-`dashboard.rb project <slug> --screen` (or `continue --screen`) prints the identical state -
-Active, In delivery, Delivered, Roadmap, Sessions, Changed, then the Where-we-are and
-Where-we-go-next tables - as a screen with its own grammar instead of a filled Markdown
-template. It replaces this fill mechanism once intent 331f wires the project route to print
-it first, the way the intent route already prints the intent screen first today; until then,
-this page's fill rules stay the route's own surface.

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

@@ -1,35 +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`) |
-| A terminal savepoint line (`delivered` or `abandoned`) | terminal | **report only** | immutable; ask what is next |
-| A node or `Intent` transition line (`n1  running ...`, `Intent  needs_decision ...`) | Exec | **Exec** | a graph delivery is in progress; read node status through `NodeLedger.status`, never re-derive it by eye |
-
-## 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.
-- **End**: 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`.

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

@@ -1,28 +0,0 @@
-# Context Management (Save, then resume-flow debugging)
-
-## 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`
-
-## Debugging the resume flow
-
-When a resume looks wrong (the announced stage does not match what is on disk, or the next
-step looks stale):
-
-1. Read `savepoint.md`'s last line directly; that line alone is the source of truth for stage
-   (see `SKILL.md`'s `## Conditional Ledger-Resume` for the full state table).
-2. Confirm the artifact that line implies (`plan.md`, `checklist.md`, `outcome.md`, ...) is
-   present and non-empty on disk.
-3. If the two disagree, the ledger is stale: rebuild it rather than hand-editing:
-   `ruby -r ~/.plastic/scripts/lib/savepoint -e 'Savepoint.rebuild_savepoint("<intent_dir>")'`
-4. Re-read the rebuilt last line and re-derive the next step from `checklist.md`'s first
-   unchecked item.
-
-The general "land on the board / priority order / stale future intents" flow now lives in
-`plastic-intent-continuing`; this file no longer duplicates it.

package/skills/intent-continuing/references/liveness-ranking.md

@@ -1,57 +0,0 @@
-# Liveness Ranking (read time, no new field)
-
-Depth reference for "Find the mid-flight roadmap" in `SKILL.md`. This is the full algorithm the
-body summarizes. Since intent 148, this algorithm is IMPLEMENTED in
-`scripts/lib/roadmap_queue.rb` behind the `scripts/roadmap-next` CLI; it is no longer a by-eye
-procedure. This page documents what that reader does, and is the specification the reader
-satisfies.
-
-## Why read-time, not a stored field
-
-INDEX.md stays the sole writer of intent status; the roadmap file mirrors it (see
-`plastic-roadmap`'s `references/file-format.md`). Adding a "mid-flight" flag to the roadmap
-file or to INDEX.md would create a second thing to keep in sync for a question that is cheap to
-answer by reading what is already there. So liveness is computed fresh, every call, from the
-tier's live `roadmaps/*.md` files (excluding `roadmaps/archived/`), by `RoadmapQueue` (intent
-148) rather than by eye.
-
-## The algorithm
-
-1. **Enumerate.** List every `roadmaps/*.md` at the tier (project or global), skipping
-   `roadmaps/archived/`.
-2. **Delivering/blocked wins outright.** If any candidate roadmap has at least one grouping-section
-   entry (`## Batches`, or legacy `## Waves`) whose mirrored status token is `delivering` or
-   `blocked`, it is in flight right now.
-   That candidate wins the ranking immediately; skip the rest of the ranking for it.
-3. **Otherwise, newest `## Log` entry wins.** Among the remaining candidates (none have a
-   `delivering`/`blocked` entry), read each file's last `## Log` line (append-only, newest at
-   the bottom) and rank by that line's `YYYY-MM-DD HH:MM UTC` timestamp. The most recent wins.
-   When a candidate's paired `roadmaps/<slug>.savepoint.md` (intent 134) is present, its last
-   line is a cheaper, machine-timestamped read of the same fact (the ledger is derived from `##
-   Log`, so the two should already agree); reading it first is an optimization, not a second
-   source of truth, so a missing or stale ledger never blocks falling back to `## Log` itself.
-4. **Genuine tie -> present, do not silently pick.** If two or more candidates are equally live
-   (for example two roadmaps both idle with `## Log` entries on the same timestamp, or two both
-   showing `delivering` entries with no other signal to separate them), do not choose for the
-   user. Present both/all tied candidates' state side by side, then let the single "auto or
-   guided?" ask (asked once regardless of how many candidates were presented) double as the
-   resolution: the user's answer implicitly picks by naming which roadmap to continue, or the
-   agent asks a short one-line disambiguation immediately before that same single ask, never a
-   second separate prompt.
-
-## What this closes
-
-Before this skill existed, nothing resumed a mid-flight roadmap automatically. The `171`
-(consistency-dividend) roadmap handoff had to be resumed by hand: a free-prose "SESSION
-HANDOFF" note written into `171`'s own `## Insights`, because nothing read the grouping section
-(`## Batches`/legacy `## Waves`) + `## Log` and reconstructed where the batch stood. This ranking, now a deterministic reader
-rather than a by-eye judgment, is the mechanism that replaces that hand-carried note.
-
-## Grammar pointer (do not duplicate)
-
-The roadmap file's four sections, entry line shape, and status vocabulary
-(`queued|delivering|delivered|abandoned|blocked`) are owned by `plastic-roadmap`:
-`skills/roadmap/references/file-format.md` for the shape, and
-`skills/roadmap/references/operations.md#read--consume` for how a reader (human or
-coordinator) is meant to walk `## Batches` (or legacy `## Waves`) and `## Log`. This page assumes that grammar and adds
-only the liveness-ranking judgment on top of it.

package/skills/intent-creating/SKILL.md

@@ -1,89 +0,0 @@
----
-name: plastic-intent-creating
-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.
-user-invocable: true
----
-
-# Creating an Intent
-
-Creating writes the thought to disk: an id, a directory, a born-complete intent file.
-Nothing else runs here; specifying, planning, and execution are separate, later skills.
-
-## When to use
-- User starts new work ("build X", "fix Y", "research Z")
-- No active intent matches the current task
-- User explicitly says "new intent" or "create intent"
-- An agent discovers work needed during implementation
-
-## Decide the store and the shape, before scaffolding
-
-- **CWD inside a registered project** (`~/.plastic/projects.yml`), or the user names a
-  project by slug -> **project intent (tactical)**, `~/.plastic/projects/{slug}/store/`,
-  linked back to the project's governing intent (`projects.yml` `parent` field) via
-  `sources`, with `[[global:<parent_ID>]]` in `## Links` and a Folgezettel id scoped to
-  that store.
-- **No match** -> **global intent (strategic)**, `~/.plastic/store/`.
-- **Duplicate or predecessor check (QMD-first):** before allocating an id, run
-  `ruby ~/.plastic/scripts/qmd-sync search "<terms>"` (a no-op when QMD is absent, fall
-  back to INDEX.md) so a near-duplicate is reused and a true predecessor lands in
-  `--sources`.
-- **Branch vs root**, decided by meaning, not by "a parent in mind": branch
-  (`--parent <parent_id>`) when the intent only makes sense as part of the parent's work;
-  root with `--sources <ascendant_id>` when it was created from another intent's
-  lifecycle; root with no `--sources` when it is merely related (record that relation on
-  the PREDECESSOR's `chain` instead - topic similarity alone is never a `sources` edge).
-
-When a branch intent exists because a late ruling arrived AFTER its parent was already
-completed, the parent is restored to v1 via `scripts/restore-intent-v1`, never a hand-run
-`git checkout`/revert (see `plastic-conventions > references/maintenance-and-revisions.md`,
-WORK vs MAINTENANCE).
-
-`## Links` is a DERIVED view of `sources`/`chain`: never hand-write a `## Links` line, add
-the frontmatter edge and reproject. Links follow context influence (a `chain` edge needs
-the candidate's context to materially help deliver this intent), never shared files or a
-similarity score; `scripts/link-suggest` and `scripts/project-links` gather candidates.
-Read `../plastic-conventions/references/knowledge-graph.md` for the full linking doctrine:
-the tiers of influence, sources versus chain, and how `## Links` is derived.
-
-## Scaffold
-
-One call does the rest: id allocation, the directory, `actions/` and `resources/`, the
-born-complete intent file, sentinel placeholder lifecycle files (each marked
-`<!-- plastic:placeholder -->` so no stage detector reads them as reached), reciprocal
-`[[id]]` links, and self-validation. Do NOT hand-author any of these files.
-
-```bash
-ruby ~/.plastic/scripts/new-intent \
-  --store "<STORE>" --intent "<one-line>" --slug "<slug>" \
-  [--parent "<parent_id>"] [--author "<author>"] \
-  [--sources "id,id"] [--tags "project-<slug>,tag"]
-```
-
-It does NOT touch INDEX.md, git, or project creation (Finish, below). If it exits
-non-zero, read the stderr report, fix the inputs (slug, intent, sources), and retry;
-never work around a failed scaffold by hand-writing the files.
-
-`chain` carries what this intent spawns AND related-but-not-spawned successors it leads
-to; it starts empty and is populated later. See
-[`how-plastic-sources-and-chains-intents.md`](https://github.com/zalom/plastic/blob/main/docs/concepts/how-plastic-sources-and-chains-intents.md)
-for the full model.
-
-## Finish
-
-1. **Global intent:** add a line to `~/.plastic/INDEX.md` under `## Active` (or
-   `## Future`) and the right cluster. **Project intent:** no global INDEX.md change.
-2. When the user says "start building" or the plan calls for a new project, invoke
-   `plastic-project-creating`; it owns project directory creation, AGENTS.md population,
-   `projects.yml` registration, store provisioning, and the auto-commit of both stores.
-   Add `project-<slug>` to this intent's `tags` either before invoking it or as part of
-   that skill's handoff.
-3. Commit: `cd <store-root> && git add . && git commit -m "feat: create intent ID - [name]"`.
-4. Announce: "Created intent ID - [name]. Placed in: [Active|Future]. Store:
-   [global|project:<slug>]."
-
-## References
-
-- Read `references/lifecycle.md` for the full What->Why->How->Exec stage detail and the
-  filesystem-as-schema conventions.
-- Read `references/wikilinks.md` for the wikilink syntax table when hand-checking a
-  `## Links` projection.