wherefore: add the slate skill and wire the sibling skills to it

AGENTS.md

@@ -12,7 +12,7 @@ wherefore/
   topics.md         controlled tag vocabulary: Areas and Topics
   log/YYYY-MM-DD-short-slug.md    one decision per file
   questions/Q-NNN-short-slug.md   one question per file (ID prefix + scannable slug)
-  plan/short-slug.md              forward-looking plans and roadmaps, one per file
+  plan/P-NNN-short-slug.md        forward-looking plan items, one per file
 ```
 
 If `wherefore/` does not exist, create it plus `log/`, `questions/`, a starter
@@ -127,6 +127,48 @@ To resolve: set the Q-file `status: resolved`, fill `resolution` (one sentence)
 `resolution_slug` (source slug, or blank if standalone). The frontmatter is the only
 place the status lives.
 
+## Plan items
+
+Forward-looking work items live in `wherefore/plan/P-NNN-short-slug.md`, one per file, a
+separate collection from decisions. A plan item is a committed intention; a decision is a
+resolved ruling. Do not create plan items for work a decision merely implies unless a human
+asks; commitments nobody chose are noise.
+
+Next P-ID = (highest `id:` across `wherefore/plan/P-*.md`) + 1; IDs are sequential and never
+reused, including numbers freed by dropped items. The `id:` field is authoritative; the
+filename slug is only for human scanning. Use this frontmatter:
+
+```markdown
+---
+id: P-NNN
+title: Short human title
+status: todo            # todo | doing | done | dropped
+created: YYYY-MM-DD
+updated:                # YYYY-MM-DD, set on ANY write: status change or body edit, including a checkbox toggle
+area:                   # single area from topics.md, or omit
+topics: []              # cross-cutting topics from topics.md, or omit
+milestone:              # M1, defined in wherefore/ROADMAP.md, or omit
+decision_ref:           # one or more YYYY-MM-DD decision slugs, comma-separated, no .md; or omit
+question_ref:           # a single Q-NNN this item is blocked on, or omit
+answers:                # a single Q-NNN this item is the work of answering (a spike), or omit
+dropped_reason:         # short why, used when status: dropped
+---
+```
+
+Body: break the work into `- [ ]` checkboxes concrete enough to check off; prose is valid too.
+
+- Status flow is `todo -> doing -> done`; any move to `dropped` is abandonment and requires a
+  `dropped_reason` or a `decision_ref`. Dropped items are kept, never deleted; the dropped item
+  plus its reason IS the plan-change record.
+- `blocked` is never written. It is derived: an item is blocked while it carries a
+  `question_ref` to an open question. At most one blocking question per item.
+- `answers` is a single `Q-NNN` a spike is the work of answering. It is the opposite of
+  `question_ref` (blocked by) and does not make the item blocked. Never point `answers` and
+  `question_ref` at the same `Q-NNN`.
+- Plan status is a separate state machine from decision status. Never put
+  `active`/`superseded`/`obsolete` on a plan item, or `todo`/`doing`/`done`/`dropped` on a
+  decision. Retiring or replacing a decision is a supersession on the decision, not a plan edit.
+
 ## Conventions
 
 - All frontmatter keys use underscore style (superseded_by, superseded_date,

CLAUDE.md

@@ -6,7 +6,7 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 
 ## What this repo is
 
-A Claude Code plugin marketplace. It hosts the `wherefore` plugin, which ships four skills and a command for capturing technical decisions into a repo-committed wherefore log, querying them later, closing out open questions, and retiring superseded or obsolete decisions. The marketplace itself has no build system, tests, or runtime -- the only "code" is JSON manifests, Markdown skill/command definitions, and a GitHub Actions CI workflow.
+A Claude Code plugin marketplace. It hosts the `wherefore` plugin, which ships five skills and a command for capturing technical decisions into a repo-committed wherefore log, querying them later, closing out open questions, retiring superseded or obsolete decisions, and tracking forward-looking plan items. The marketplace itself has no build system, tests, or runtime -- the only "code" is JSON manifests, Markdown skill/command definitions, and a GitHub Actions CI workflow.
 
 ## Validation
 
@@ -61,6 +61,10 @@ plugins/wherefore/
   skills/supersede/
     SKILL.md                          # marks an entry superseded (with pointer to
                                       # replacement) or obsolete via its frontmatter
+  skills/slate/
+    SKILL.md                          # manages wherefore/plan/ items (open, advance,
+                                      # drop, read): one verb, four intents; never
+                                      # writes log/ or questions/, hands off instead
 ```
 
 The `wherefore/` directory itself is **not** in this repo -- it lives in each consuming project's repo, created by the skills on first use.
@@ -71,6 +75,7 @@ The `wherefore/` directory itself is **not** in this repo -- it lives in each co
 - **Command `.md`** front matter: `description`, `argument-hint`, `allowed-tools`.
 - All skills use a two-facet tag system: **areas** (feature slices: WHAT) and **topics** (cross-cutting concerns: HOW), drawn from the consuming project's `wherefore/topics.md`. Keep this separation consistent if extending the skills.
 - Entry and question frontmatter is the single source of truth: `ask` derives its shortlist by reading only the leading frontmatter block of each file. Derive on read; do not add a generated index.
-- `capture` is write-heavy (creates/edits files); a single discussion may produce multiple entry files when it covers independently-queryable threads. `ask` is read-only. `resolve` edits only the `questions/Q-NNN-short-slug.md` file (and optionally the source entry). `supersede` edits an existing entry file's frontmatter and adds a banner. `seed` is read-first, write-only-after-confirmation -- preserve this ask-before-write pattern for any new commands.
+- `capture` is write-heavy (creates/edits files); a single discussion may produce multiple entry files when it covers independently-queryable threads. `ask` is read-only. `resolve` edits only the `questions/Q-NNN-short-slug.md` file (and optionally the source entry). `supersede` edits an existing entry file's frontmatter and adds a banner. `slate` is the only writer of `wherefore/plan/`: it opens, advances, drops, and reads plan items and never writes `log/` or `questions/` (it hands off to `capture` and `ask` instead). `capture` never creates plan items; when a decision resolves or implies work it hands off to `slate`. `seed` is read-first, write-only-after-confirmation -- preserve this ask-before-write pattern for any new commands.
 - Entry filenames: `YYYY-MM-DD-short-slug.md`; the entry frontmatter (`date`, `title`, `areas`, `topics`, `stories`, `status`, `supersedes`, `superseded_by`, `superseded_date`) is what readers shortlist on.
 - Question files: `questions/Q-NNN-short-slug.md` (the `Q-NNN` prefix is the zero-padded ID; the slug is a short, lowercase, hyphenated summary of the question, same style as a log slug and only for human scanning). One per question, with `id`, `question`, `status`, `areas`, `asked_date`, `asked_slug`, `resolution`, `resolution_slug` frontmatter. The `id:` field is the authoritative ID (the dashboard keys off it, not the filename). IDs are sequential and never reused; the next ID is (highest existing `id:`) + 1.
+- Plan items: `plan/P-NNN-short-slug.md` (the `P-NNN` prefix is the zero-padded ID; the `id:` field is authoritative, and the loader globs `plan/P-*.md` so `plan/README.md` is never collected). Frontmatter: `id`, `title`, `status` (todo|doing|done|dropped), `created`, `updated` (bumped on any write, including a checkbox toggle), plus optional `area` (single, not the plural `areas` decisions use), `topics`, `milestone`, `decision_ref`, `question_ref`, `answers` (a single `Q-NNN` a spike is the work of answering, the opposite of `question_ref` and not a blocker), `dropped_reason`. Plan status is a separate state machine from decision status: `capture` never creates or mutates plan items, and plan transitions never touch a decision's status (that stays with `supersede`). `blocked` is derived from an open `question_ref` (at most one per item), never written. IDs are sequential and never reused; the next ID is (highest existing `id:`) + 1.

README.md

@@ -46,8 +46,8 @@ just files in your repo, any tool or any person can read it.
 There are a few ways to work with it:
 
 - **A Claude Code plugin** (the richest experience): skills that capture, query,
-  resolve, and supersede decisions, with Claude handling the tagging and bookkeeping
-  so the log actually gets maintained.
+  resolve, and supersede decisions and track forward-looking plan items, with Claude
+  handling the tagging and bookkeeping so the log actually gets maintained.
 - **The `wherefore` CLI** ([`wherefore`](https://www.npmjs.com/package/wherefore) on
   npm): `npx wherefore init` scaffolds the log and an `AGENTS.md`, and
   `npx wherefore dashboard` launches the dashboard. It can also install the skills for
@@ -88,6 +88,13 @@ maintained.
   replacement) or obsolete, without requiring a new discussion to be captured.
   Updates the entry file and adds a visible banner so both the `ask` skill and
   human readers see it is retired.
+- **`slate`** -- tracks forward-looking work items in `wherefore/plan/`, one file per
+  item (`P-NNN-short-slug.md`). One verb, four intents detected from your request:
+  open a new item (broken into concrete checkboxes), advance one along
+  `todo -> doing -> done`, drop one you've abandoned (with a reason, never deleted),
+  or read back what's on the plan. It owns `plan/` and hands off to `capture` and
+  `ask` rather than writing decisions or questions itself, so the plan never fills
+  with commitments nobody made.
 - **`/wherefore:seed`** -- inspects the codebase and proposes a starter set of areas
   and topics for `wherefore/topics.md`, with a short justification for each tag.
   Confirm or edit its proposal and it writes (or merges into) the file.
@@ -100,9 +107,10 @@ consuming project's repo, version-controlled and PR-reviewable next to the code.
 ## Other coding agents
 
 The `wherefore/` log is plain markdown, so it is not tied to any one tool. An
-`AGENTS.md` at the repo root describes the format and the capture, supersede, and
-question workflows, so coding agents that read AGENTS.md (Codex, GitHub Copilot,
-Cursor, Gemini, and others) can read and maintain the log by following the spec.
+`AGENTS.md` at the repo root describes the format and the capture, supersede,
+question, and plan workflows, so coding agents that read AGENTS.md (Codex, GitHub
+Copilot, Cursor, Gemini, and others) can read and maintain the log by following the
+spec.
 
 The Claude Code plugin remains the richest experience: it handles tagging,
 supersession detection, multi-thread splitting, and the question lifecycle for you.
@@ -232,6 +240,10 @@ file and annotates the source entry so the audit trail is complete.
 `supersede` retires entries after the fact, `ask` follows chains to the active
 answer.
 
+**Plan lifecycle:** `slate` opens forward-looking items, advances them
+`todo -> doing -> done`, and drops the ones you abandon; `capture` hands off to it
+when a decision implies committed work, rather than inventing plan items itself.
+
 ## Repo layout
 
 ```
@@ -261,8 +273,10 @@ wherefore/
 │           │   └── SKILL.md           # query skill
 │           ├── resolve/
 │           │   └── SKILL.md           # close out open questions
-│           └── supersede/
-│               └── SKILL.md           # retire decisions (superseded or obsolete)
+│           ├── supersede/
+│           │   └── SKILL.md           # retire decisions (superseded or obsolete)
+│           └── slate/
+│               └── SKILL.md           # track forward-looking plan items
 └── README.md
 ```
 
@@ -272,10 +286,12 @@ Each consuming project's log lives in its own repo, not here:
 <your-project>/
 └── wherefore/
     ├── topics.md         # controlled tag vocabulary (areas + topics)
+    ├── log/
+    │   └── YYYY-MM-DD-short-slug.md   # one file per independently-queryable thread
     ├── questions/
     │   └── Q-NNN-short-slug.md    # one file per question (ID prefix + scannable slug)
-    └── log/
-        └── YYYY-MM-DD-short-slug.md   # one file per independently-queryable thread
+    └── plan/
+        └── P-NNN-short-slug.md    # one file per forward-looking plan item
 ```
 
 Entry and question frontmatter is the single source of truth, and the skills

plugins/wherefore/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "wherefore",
   "description": "Distill technical discussions into compact, tagged decision entries with a live registry of open questions, all version-controlled in your repo and queryable by Claude.",
-  "version": "0.1.3",
+  "version": "0.2.0",
   "author": {
     "name": "Dustin VanKrimpen"
   },

plugins/wherefore/commands/seed.md

@@ -58,9 +58,101 @@ approval; wait for their reply before writing anything.
 
 - If `wherefore/topics.md` does NOT exist: create the `wherefore/` directory and
   write the confirmed vocabulary as `wherefore/topics.md` in the two-section format
-  above. The `capture` skill scaffolds the rest of the directory on first use.
+  above. The `capture` skill scaffolds `log/`, `questions/`, and the top-level
+  `README.md` on first use.
 - If it DOES exist: treat the existing file as the source of truth and MERGE:
   append only the new, confirmed tags under the correct section, and never remove
   or rename anything already there. Report exactly which tags you added.
+- When creating `wherefore/` fresh (or when `wherefore/` exists but `wherefore/plan/`
+  does not), scaffold the `plan/` collection: create `wherefore/plan/` and write
+  `wherefore/plan/README.md` with exactly the content below. The loader globs
+  `plan/P-*.md`, so this `README.md` is never collected as an item. Do NOT write any
+  P-item; opening items is the `slate` skill's job.
+
+  ````markdown
+  # Plan collection (`wherefore/plan/`)
+
+  Plan items are a first-class collection under `wherefore/`, parallel to `questions/`.
+  They track forward-looking work and its state (todo / doing / done / dropped) and
+  preserve plan-change history by keeping dropped items rather than deleting them. This
+  collection is durable and retire-don't-delete, the same as the rest of `wherefore/`.
+
+  Plan status is a separate state machine from decision status. Do not reuse active /
+  superseded / obsolete here, and do not put todo / doing / done / dropped on decisions.
+
+  ## Files
+
+  - Path: `wherefore/plan/P-NNN-slug.md`. The slug is browsability sugar.
+  - The `id` field in frontmatter is authoritative and drives the item's identity,
+    exactly like `Q-NNN`. Filename casing cannot cause collisions.
+  - The loader globs `plan/P-*.md`, so only plan-item files are collected. This
+    `README.md` is ignored.
+  - Next ID = (highest `id:` across the P-*.md files) + 1. IDs are sequential and never
+    reused, including numbers freed by dropped items.
+
+  ## Frontmatter
+
+  | key             | req | type              | notes                                                       |
+  |-----------------|-----|-------------------|-------------------------------------------------------------|
+  | `id`            | yes | `P-NNN`           | authoritative, drives the item id                           |
+  | `title`         | yes | string            | short human title                                           |
+  | `status`        | yes | enum              | `todo` / `doing` / `done` / `dropped`                       |
+  | `created`       | yes | `YYYY-MM-DD`      | creation date                                               |
+  | `updated`       | no  | `YYYY-MM-DD`      | set on any write (status change or body edit, including a checkbox toggle); this IS the plan-change timestamp |
+  | `area`          | no  | string            | single area, reuse existing area vocabulary                 |
+  | `topics`        | no  | list              | reuse existing cross-cutting topics                         |
+  | `milestone`     | no  | `M1`              | milestone this item serves, defined in `wherefore/ROADMAP.md`|
+  | `decision_ref`  | no  | slug or slug list | originating or superseding decision(s), `supersedes` format |
+  | `question_ref`  | no  | `Q-NNN`           | a single open question this item is blocked on              |
+  | `answers`       | no  | `Q-NNN`           | a single question this item is the work of answering (spike)|
+  | `dropped_reason`| no  | string            | lightweight why, used when `status: dropped`                |
+
+  Body: freeform. The `slate` skill breaks the work into `- [ ]` checkboxes by default
+  (steps concrete enough to check off); prose stays valid, and older items may be
+  prose-only.
+
+  ## Status vocabulary
+
+  `todo` -> `doing` -> `done` is the normal flow. Any transition to `dropped` is
+  abandonment. `dropped` is terminal but kept: a dropped item, with `updated` marking
+  when and `dropped_reason` or `decision_ref` marking why, IS the plan-change record.
+
+  `blocked` is derived, not a status. An item is blocked if it carries a `question_ref`
+  to an open question. It never lives in frontmatter. An item carrying `answers` (a spike
+  investigating a question) is not blocked; `answers` is the opposite relationship.
+
+  ## Linking conventions
+
+  - `milestone`: a single milestone ID (`M1`) defined in `wherefore/ROADMAP.md`. One-way:
+    the item points up at the milestone.
+  - `decision_ref`: one or more decision log slugs in `YYYY-MM-DD-slug` form (no `.md`),
+    comma-separated for multiple, mirroring the `supersedes` convention.
+  - `question_ref`: a single `Q-NNN` the item waits on. By deliberate choice an item is
+    blocked by at most one question.
+  - `answers`: a single `Q-NNN` this item investigates (a spike). The opposite of
+    `question_ref`: an item that `answers` a question is not blocked by it. An item may
+    carry both (rare but legal); never point them at the same `Q-NNN`.
+
+  ## Key casing
+
+  Single-word keys are bare (`id`, `title`, `status`, `created`, `updated`, `area`,
+  `topics`, `milestone`, `answers`). Compound keys use underscore (`decision_ref`,
+  `question_ref`, `dropped_reason`). A hyphen in a compound key parses silently and drops
+  the link.
+
+  ## Boundaries
+
+  - The `slate` skill writes only `wherefore/plan/*`. Never `log/`, never `questions/`,
+    never `ROADMAP.md`.
+  - Durable why belongs in the decision layer: when a plan item's rationale is really a
+    decision, that is a `capture`; when a direction changes for a reason worth keeping,
+    that is a `supersede` on the decision, and the plan item flips to `dropped` carrying
+    `decision_ref` to it.
+  - `capture` never creates plan items and never writes plan status directly; it may hand
+    off to the `slate` skill. The `slate` skill records that something changed; the decision
+    layer owns the durable why.
+
+  Maintained by the [wherefore](https://github.com/DustinVK/wherefore) slate skill.
+  ````
 
 Finish with a one-line summary of what was written and where.