diff --git a/README.md b/README.md
index 88bed7f..eb1fc4c 100644
--- a/README.md
+++ b/README.md
@@ -12,12 +12,6 @@ These skills help you think through problems before writing code.
npx skills@latest add mattpocock/skills/write-a-prd
```
-- **prd-to-plan** — Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices.
-
- ```
- npx skills@latest add mattpocock/skills/prd-to-plan
- ```
-
- **prd-to-issues** — Break a PRD into independently-grabbable GitHub issues using vertical slices.
```
diff --git a/prd-to-plan/SKILL.md b/prd-to-plan/SKILL.md
deleted file mode 100644
index a5da1c2..0000000
--- a/prd-to-plan/SKILL.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-name: prd-to-plan
-description: Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices, saved as a local Markdown file in ./plans/. Use when user wants to break down a PRD, create an implementation plan, plan phases from a PRD, or mentions "tracer bullets".
----
-
-# PRD to Plan
-
-Break a PRD into a phased implementation plan using vertical slices (tracer bullets). Output is a Markdown file in `./plans/`.
-
-## Process
-
-### 1. Confirm the PRD is in context
-
-The PRD should already be in the conversation. If it isn't, ask the user to paste it or point you to the file.
-
-### 2. Explore the codebase
-
-If you have not already explored the codebase, do so to understand the current architecture, existing patterns, and integration layers.
-
-### 3. Identify durable architectural decisions
-
-Before slicing, identify high-level decisions that are unlikely to change throughout implementation:
-
-- Route structures / URL patterns
-- Database schema shape
-- Key data models
-- Authentication / authorization approach
-- Third-party service boundaries
-
-These go in the plan header so every phase can reference them.
-
-### 4. Draft vertical slices
-
-Break the PRD 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
-- Prefer many thin slices over few thick ones
-- Do NOT include specific file names, function names, or implementation details that are likely to change as later phases are built
-- DO include durable decisions: route paths, schema shapes, data model names
-
-
-### 5. Quiz the user
-
-Present the proposed breakdown as a numbered list. For each phase show:
-
-- **Title**: short descriptive name
-- **User stories covered**: which user stories from the PRD this addresses
-
-Ask the user:
-
-- Does the granularity feel right? (too coarse / too fine)
-- Should any phases be merged or split further?
-
-Iterate until the user approves the breakdown.
-
-### 6. Write the plan file
-
-Create `./plans/` if it doesn't exist. Write the plan as a Markdown file named after the feature (e.g. `./plans/user-onboarding.md`). Use the template below.
-
-
-# Plan:
-
-> Source PRD:
-
-## Architectural decisions
-
-Durable decisions that apply across all phases:
-
-- **Routes**: ...
-- **Schema**: ...
-- **Key models**: ...
-- (add/remove sections as appropriate)
-
----
-
-## Phase 1:
-
-**User stories**:
-
-### What to build
-
-A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
-
-### Acceptance criteria
-
-- [ ] Criterion 1
-- [ ] Criterion 2
-- [ ] Criterion 3
-
----
-
-## Phase 2:
-
-**User stories**:
-
-### What to build
-
-...
-
-### Acceptance criteria
-
-- [ ] ...
-
-
-