refactor(to-plan,to-issues): prune no-ops in vertical-slice framing

Fold the redundant 'thin vertical slice cuts through all layers, NOT
horizontal' intro sentence into vertical-slice-rules bullet 1 (it was
duplicating the bullet), and cut to-plan's 'no parallelism / top-to-bottom'
restatement — 'sequential' is already anchored as the leading word. Keeps
the shared core identical across the two sibling skills.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.changeset/to-plan-skill.md

@@ -0,0 +1,5 @@
+---
+"mattpocock-skills": minor
+---
+
+Add a new user-invoked **`to-plan`** skill to the `engineering/` bucket — the sequential, HITL sibling of **`to-issues`**. Both slice work into tracer-bullet vertical slices, but where `to-issues` produces independently-grabbable issues for parallel agents, `to-plan` produces one ordered sequence you drive by hand, one phase per fresh context. It publishes to the tracker `/setup-matt-pocock-skills` configured, shaped to it: a single sequential `plan.md` for a local tracker, or a parent issue with ordered sub-issues (native sub-issues where the platform supports them) for a real one. The `to-*` fork in `ask-matt`'s main flow now offers both, and there's a human-facing docs page at `docs/engineering/to-plan.md`.

.changeset/wayfinding-rename.md

@@ -1,9 +0,0 @@
----
-"mattpocock-skills": minor
----
-
-Rename the **`decision-mapping`** skill to **`wayfinder`**, invoked as `/wayfinder`.
-
-"Decision map" was jargony and inaccurate — only one of the skill's four ticket types (Grilling) is actually a decision. The reframe charts a route through a foggy problem, resolving investigation tickets one at a time until the way to the goal is clear. This makes one coherent leading-word frame (fog of war / frontier / the map) instead of mixing an invented term on top of it.
-
-Also a pruning pass: unified `node`→`ticket`, bound "the frontier" to the unblocked tickets, dropped the duplicated "one question at a time" (owned by `/grilling`), and trimmed intro no-ops.

.claude-plugin/plugin.json

@@ -9,6 +9,7 @@
     "./skills/engineering/setup-matt-pocock-skills",
     "./skills/engineering/tdd",
     "./skills/engineering/to-issues",
+    "./skills/engineering/to-plan",
     "./skills/engineering/to-prd",
     "./skills/engineering/implement",
     "./skills/engineering/prototype",

README.md

@@ -155,6 +155,7 @@ Skills I use daily for code work.
 - **[improve-codebase-architecture](./skills/engineering/improve-codebase-architecture/SKILL.md)** — Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
 - **[setup-matt-pocock-skills](./skills/engineering/setup-matt-pocock-skills/SKILL.md)** — Configure this repo for the engineering skills (issue tracker, triage labels, domain doc layout). Run once per repo before using the other engineering skills.
 - **[to-issues](./skills/engineering/to-issues/SKILL.md)** — Break any plan, spec, or PRD into independently-grabbable issues using vertical slices.
+- **[to-plan](./skills/engineering/to-plan/SKILL.md)** — Turn any plan, spec, or PRD into a sequential set of tracer-bullet phases worked one at a time — a single ordered file for a local tracker, or parent-and-sub-issues for a real one.
 - **[to-prd](./skills/engineering/to-prd/SKILL.md)** — Turn the current conversation into a PRD and publish it to the issue tracker. No interview — just synthesizes what you've already discussed.
 
 **Model-invoked**

docs/engineering/to-plan.md

@@ -0,0 +1,53 @@
+Quickstart:
+
+```bash
+npx skills add mattpocock/skills --skill=to-plan
+```
+
+```bash
+npx skills update to-plan
+```
+
+[Source](https://github.com/mattpocock/skills/tree/main/skills/engineering/to-plan)
+
+## What it does
+
+`to-plan` turns a PRD, spec, or the current conversation into a **sequential** plan — an ordered list of phases you work through one at a time, in a fresh context per phase.
+
+Every phase is a **tracer bullet** — a thin *vertical* slice that cuts through all integration layers end-to-end (schema, API, UI, tests), never a horizontal slice of one layer. A completed slice is demoable or verifiable on its own, and is sized to fit a single fresh context window.
+
+## When to reach for it
+
+You invoke this by typing `/to-plan` — the agent won't reach for it on its own.
+
+Reach for it once you have an agreed plan or a written spec and you want it turned into a sequence of phases you'll build **by hand, one at a time**. Point it at the conversation, or pass a PRD or issue reference and it reads that first. If the change hasn't been written up as a spec yet, produce one first — for that, use [to-prd](https://aihero.dev/skills-to-prd).
+
+## Sequential, not parallel
+
+`to-plan` is the sequential, HITL sibling of [to-issues](https://aihero.dev/skills-to-issues). Both slice work into tracer bullets, but they're for different workflows:
+
+- **`to-issues`** produces *independently-grabbable* issues, so parallel agents can pick them up at once (it applies the ready-for-agent label).
+- **`to-plan`** produces one *ordered sequence* you drive yourself, phase by phase, staying in the loop — no ready-for-agent label.
+
+## Publishes to your configured tracker
+
+Like the other skills, `to-plan` publishes through the tracker [setup-matt-pocock-skills](https://aihero.dev/skills-setup-matt-pocock-skills) configured, and it adapts the shape to that tracker:
+
+- **Local files** → a single sequential `plan.md` in the repo root, all phases in order.
+- **A real issue tracker (GitHub, Linear)** → a parent issue for the whole plan, with one sub-issue per phase, in order — using the platform's native sub-issue relationship where it has one, otherwise sequential issues each blocked by the previous.
+
+## Vertical slices, not horizontal ones
+
+The whole skill turns on one distinction. A **horizontal** slice ships one layer of the change — all the schema, or all the API — and nothing works until every layer lands. A **vertical** slice, the tracer bullet, ships one narrow path through *every* layer at once, so it can be demoed the moment it's done.
+
+Before slicing, `to-plan` looks for prefactoring — "make the change easy, then make the easy change" — and orders that work first. It then quizzes you on the breakdown (granularity, ordering, what to merge or split) before publishing anything.
+
+## Where it fits
+
+`to-plan` is the sequential branch of the main build chain:
+
+```txt
+grill-with-docs → to-prd → to-plan → implement → code-review
+```
+
+It sits between [to-prd](https://aihero.dev/skills-to-prd), which hands it a settled spec to slice against, and [implement](https://aihero.dev/skills-implement), which builds each phase, driving [tdd](https://aihero.dev/skills-tdd) internally to write the tests test-first, before its [code-review](https://aihero.dev/skills-code-review) pass. Work one phase per fresh context, clearing between them. When you're unsure which skill or flow fits, [ask-matt](https://aihero.dev/skills-ask-matt) routes you.

skills/engineering/README.md

@@ -12,6 +12,7 @@ Reachable only when you type them (`disable-model-invocation: true`).
 - **[improve-codebase-architecture](./improve-codebase-architecture/SKILL.md)** — Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
 - **[setup-matt-pocock-skills](./setup-matt-pocock-skills/SKILL.md)** — Configure this repo for the engineering skills (issue tracker, triage labels, domain doc layout). Run once per repo.
 - **[to-issues](./to-issues/SKILL.md)** — Break any plan, spec, or PRD into independently-grabbable issues using vertical slices.
+- **[to-plan](./to-plan/SKILL.md)** — Turn any plan, spec, or PRD into a sequential set of tracer-bullet phases worked one at a time — a single ordered file for a local tracker, or parent-and-sub-issues for a real one.
 - **[to-prd](./to-prd/SKILL.md)** — Turn the current conversation into a PRD and publish it to the issue tracker.
 
 ## Model-invoked

skills/engineering/ask-matt/SKILL.md

@@ -20,7 +20,9 @@ The route most work travels. You have an idea and want it built.
    - **`/prototype`** to answer the question with throwaway code,
    - **`/handoff`** back what you learned, and reference it from the original idea thread.
 3. **Branch — is this a multi-session build?**
-   - **Yes** → **`/to-prd`** (turn the thread into a PRD) → **`/to-issues`** (split the PRD into independently-grabbable issues). Because the issues are independent, **clear context between each one**: start a fresh session per issue and kick off **`/implement`** by passing it the PRD and the single issue to work on.
+   - **Yes** → **`/to-prd`** (turn the thread into a PRD), then split it into tracer-bullet slices one of two ways:
+     - **`/to-issues`** — independently-grabbable issues on your tracker, for **parallel/AFK** agents. Because the issues are independent, **clear context between each one** and kick off **`/implement`** per issue.
+     - **`/to-plan`** — a **sequential** plan you drive **by hand**, staying in the loop. Publishes to the same tracker, shaped to it: a single ordered `plan.md` for a local tracker, or a parent issue with ordered sub-issues for a real one. Work one phase per fresh context, clearing between them, with **`/implement`**.
    - **No** → **`/implement`** right here, in the same context window.
 
    Either way, **`/implement`** builds each issue by driving **`/tdd`** internally — one red-green slice at a time — then closes out by running **`/code-review`**, a two-axis review (Standards + Spec) of the diff, before committing. Reach for **`/tdd`** on its own when you just want to build a concrete behaviour test-first without a full spec, and **`/code-review`** on its own whenever you want to review a branch or PR against a fixed point.

skills/engineering/to-issues/SKILL.md

@@ -24,11 +24,11 @@ Look for opportunities to prefactor the code to make the implementation easier.
 
 ### 3. Draft vertical slices
 
-Break the plan into **tracer bullet** issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
+Break the plan into **tracer bullet** issues.
 
 <vertical-slice-rules>
 
-- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
+- Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests) — vertical, NOT a horizontal slice of one layer
 - A completed slice is demoable or verifiable on its own
 - Any prefactoring should be done first
 

skills/engineering/to-plan/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: to-plan
+description: Turn a PRD, spec, or the current conversation into a sequential plan of tracer-bullet vertical slices, published to the configured tracker — one ordered file for local, or parent-and-sub-issues for a real tracker.
+disable-model-invocation: true
+---
+
+# To Plan
+
+Turn a plan, spec, or PRD into a **sequential** plan of vertical slices (tracer bullets) — an ordered list of phases you work through one at a time, in a fresh context per phase.
+
+This is the sequential, HITL sibling of `/to-issues`. Where `to-issues` produces independently-grabbable issues for parallel agents, `to-plan` produces one ordered sequence you drive by hand, top to bottom.
+
+The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
+
+## Process
+
+### 1. Gather context
+
+Work from whatever is already in the conversation context. If the user passes a reference (a PRD path, an issue number or URL) as an argument, fetch it and read its full body.
+
+### 2. Explore the codebase (optional)
+
+If you have not already explored the codebase, do so to understand the current state of the code. Phase titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
+
+Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy, then make the easy change."
+
+### 3. Draft vertical slices
+
+Break the work into **tracer bullet** phases.
+
+<vertical-slice-rules>
+
+- Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests) — vertical, NOT a horizontal slice of one layer
+- A completed slice is demoable or verifiable on its own
+- Each slice is sized to fit in a single fresh context window
+- Any prefactoring should be done first
+
+</vertical-slice-rules>
+
+Order the phases in dependency order — each builds on the ones before it.
+
+### 4. Quiz the user
+
+Present the proposed breakdown as a numbered list. For each phase, show:
+
+- **Title**: short descriptive name
+- **What it delivers**: the end-to-end behaviour this phase makes work
+
+Ask the user:
+
+- Does the granularity feel right? (too coarse / too fine)
+- Is the ordering correct — does each phase build on the ones before it?
+- Should any phases be merged or split further?
+
+Iterate until the user approves the breakdown.
+
+### 5. Publish the plan to the configured tracker
+
+Publish the approved phases in order. **How** depends on the tracker `/setup-matt-pocock-skills` configured:
+
+- **Local files** → write one sequential `plan.md` in the repo root, all phases in order, using the file template below.
+- **A real issue tracker (GitHub, Linear, …)** → create **one parent issue** for the whole plan, then **one sub-issue per phase, in order**. Use the platform's native sub-issue / child-issue relationship if it supports one; otherwise create sequential issues and set each phase's "Blocked by" to the previous phase. Use the issue template below for the parent and each phase.
+
+These are worked **sequentially by hand**, not handed to parallel agents, so do NOT apply the ready-for-agent triage label.
+
+<plan-file-template>
+
+# Plan: <short name of the work>
+
+A one-line summary of what this plan builds. Reference the source PRD or spec if there is one.
+
+## Phases
+
+Each phase is one tracer bullet — a vertical slice worked in a fresh context, top to bottom.
+
+### 1. <Phase title>
+
+**Delivers:** the end-to-end behaviour this phase makes work, from the user's perspective — not a layer-by-layer implementation list.
+
+- [ ] Acceptance criterion 1
+- [ ] Acceptance criterion 2
+
+### 2. <Phase title>
+
+...
+
+</plan-file-template>
+
+<issue-template>
+
+**Parent issue** — title: the plan's short name. Body: the one-line summary, a reference to the source PRD/spec, and the ordered list of phase titles.
+
+**Each phase sub-issue:**
+
+## What to build
+
+The end-to-end behaviour this phase makes work, from the user's perspective — not layer-by-layer implementation.
+
+## Acceptance criteria
+
+- [ ] Criterion 1
+- [ ] Criterion 2
+
+## Blocked by
+
+The previous phase (omit for the first phase).
+
+</issue-template>
+
+In either form, avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
+
+Work the plan one phase at a time with `/implement`, clearing context between phases.

skills/in-progress/README.md

@@ -2,7 +2,7 @@
 
 Skills that are still being developed. They're not ready to ship — expect rough edges, breaking changes, and abandoned experiments. They're excluded from the plugin and the top-level README until they graduate to a stable bucket.
 
-- **[wayfinder](./wayfinder/SKILL.md)** — Chart a route through a foggy problem — turn a loose idea into a map of investigation tickets and resolve them one at a time until the way to the goal is clear. User-invoked.
+- **[decision-mapping](./decision-mapping/SKILL.md)** — Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time. User-invoked.
 - **[loop-me](./loop-me/SKILL.md)** — Grill yourself into implementable workflow specs over multiple sessions, using the current directory as a stateful workspace. User-invoked.
 - **[wizard](./wizard/SKILL.md)** — Generate an interactive bash wizard that walks a human through a manual procedure (setup, a one-off migration, a state transition) — opening URLs, capturing values, writing `.env` and GitHub Actions secrets. User-invoked.
 - **[writing-beats](./writing-beats/SKILL.md)** — Shape an article as a journey of beats, choose-your-own-adventure style. Pick a starting beat, write only that beat, then pivot to the next, until the article reaches a natural end.

skills/in-progress/decision-mapping/SKILL.md

@@ -1,14 +1,14 @@
 ---
-name: wayfinder
-description: Chart a route through a foggy problem — turn a loose idea into a map of investigation tickets and resolve them one at a time until the way to the goal is clear.
+name: decision-mapping
+description: Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time.
 disable-model-invocation: true
 ---
 
-A loose idea has arrived — too big for one agent session, and wrapped in fog: the route from here to a plan isn't visible yet. This skill charts it: stand up a map, then work its tickets one at a time until the way to the goal is clear. The map is domain-agnostic — engineering work, course content, whatever fits the shape.
+This skill is invoked when a loose idea requires more than one agent session to turn into a plan. It creates a stateful decision map in a markdown file, and drives the user through a sequence of tickets to resolve the open questions - which may require either prototyping, research or grilling. The map is domain-agnostic: it plans engineering work, course content, or anything else that fits the same shape.
 
-## The Map
+## The Decision Map
 
-The map is a single compact Markdown file, one per wayfinding effort, git-tracked alongside the project. It is the canonical artifact — the **whole map is loaded as context into every session**, so it must stay compact.
+The decision map is a single compact Markdown file, one per planning effort, git-tracked alongside the project. It is the canonical artifact — the **whole map is loaded as context into every session**, so it must stay compact.
 
 Assets created during tickets should be linked to from the map, not duplicated within it.
 
@@ -53,19 +53,19 @@ There are four types of tickets:
 
 ## Fog of war
 
-The map is _deliberately_ incomplete beyond the frontier — don't chart what you can't yet see. The frontier is the unblocked tickets at the edge of the known; resolve them to push it forward. Push back the fog of war one ticket at a time, until the way to the goal is clear and no tickets remain.
+The map is _deliberately_ incomplete beyond the frontier. Your job is to investigate the frontier, and to resolve tickets in order to push the frontier forward. Push back the fog of war, one node at a time — until the path to the finish line is clear and no tickets remain.
 
 ## Invocation
 
 Two branches. Either way, **every session ends with a [Handoff](#handoff)** — never resolve more than one ticket per session.
 
-### Chart the map
+### Create the map
 
 User invokes with a loose idea.
 
-1. Run a `/grilling` and `/domain-modeling` session to surface the open decisions.
-2. Write a new map — mostly fog, frontier identified, trivially-decidable entries resolved inline.
-3. Handoff. Charting the map is one session's work; do not also resolve tickets.
+1. Run a `/grilling` and `/domain-modeling` session to surface the open decisions. Ask one question at a time.
+2. Write a new decision map — mostly fog, frontier identified, trivially-decidable entries resolved inline.
+3. Handoff. Map-building is one session's work; do not also resolve tickets.
 
 ### Work through the map
 
@@ -75,7 +75,7 @@ User invokes with a path to an existing map. A ticket slug is **optional** — w
 2. Choose the ticket. If the user named one, use it. Otherwise pick the first `open` ticket in document order that is [unblocked](#structure). [Claim it](#structure): set `Status: in-progress` and save before any work.
 3. Resolve it, invoking skills as needed — including any the `## Notes` block names. If in doubt, use `/grilling` and `/domain-modeling`.
 4. Record the answer in the ticket's body and set `Status: resolved`.
-5. Add newly-discovered tickets with correct `Blocked by` edges. If the decisions made invalidate other parts of the map, update or delete those tickets.
+5. Add newly-discovered tickets with correct `Blocked by` edges. If the decisions made invalidate other parts of the map, update or delete those nodes.
 6. Handoff.
 
 The user may run unblocked tickets in parallel, so expect other agents to be editing the map in their own sessions.
@@ -91,18 +91,18 @@ End every session by clearing the context and opening one or more fresh sessions
 >
 > **One session** — resolves the next unblocked ticket:
 > ```
-> Invoke /wayfinder with the map at <path>.
+> Invoke /decision-mapping with the map at <path>.
 > ```
 >
 > **Parallel** — paste one line per window, up to all 3:
 > ```
-> Invoke /wayfinder with the map at <path>, ticket auth-strategy.
-> Invoke /wayfinder with the map at <path>, ticket cache-layer.
-> Invoke /wayfinder with the map at <path>, ticket rate-limits.
+> Invoke /decision-mapping with the map at <path>, ticket auth-strategy.
+> Invoke /decision-mapping with the map at <path>, ticket cache-layer.
+> Invoke /decision-mapping with the map at <path>, ticket rate-limits.
 > ```
 
-**No open tickets remain.** The fog is pushed back far enough that the way to the goal is clear — the map is done. (The initial grilling may also surface no fog at all, in which case there was never a map to chart.) Recommend implementing directly, or using `/to-prd` to schedule a multi-session implementation.
+**No open tickets remain.** The fog is pushed back far enough that the path to the finish line is clear — the map is done. (The initial grilling may also surface no fog at all, in which case there was never a map to build.) Recommend implementing directly, or using `/to-prd` to schedule a multi-session implementation.
 
 ## Notes
 
-An optional block declaring the **domain**, any skills every session should `consult`, and freeform standing preferences for this effort.
+An optional block declaring the **domain**, any skills every session should `consult`, and freeform standing preferences the planning surfaces.