diff --git a/.changeset/to-plan-skill.md b/.changeset/to-plan-skill.md new file mode 100644 index 0000000..5fc5609 --- /dev/null +++ b/.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`. diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index 1255e60..8ec7f2c 100644 --- a/.claude-plugin/plugin.json +++ b/.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", diff --git a/README.md b/README.md index fe6a0ec..0caeecb 100644 --- a/README.md +++ b/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** diff --git a/docs/engineering/to-plan.md b/docs/engineering/to-plan.md new file mode 100644 index 0000000..b797426 --- /dev/null +++ b/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. diff --git a/skills/engineering/README.md b/skills/engineering/README.md index 2c123f4..706478b 100644 --- a/skills/engineering/README.md +++ b/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 diff --git a/skills/engineering/ask-matt/SKILL.md b/skills/engineering/ask-matt/SKILL.md index f19a17c..bb3a514 100644 --- a/skills/engineering/ask-matt/SKILL.md +++ b/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. diff --git a/skills/engineering/to-plan/SKILL.md b/skills/engineering/to-plan/SKILL.md new file mode 100644 index 0000000..d1baf0a --- /dev/null +++ b/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. Each phase is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer. + + + +- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests) +- 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 + + + +Order the phases **sequentially**, in dependency order — each phase builds on the ones before it. There is no parallelism: a plain top-to-bottom sequence. + +### 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: + +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. + +**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. + +... + + + + + +**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). + + + +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.