---
name: prd-next
description: Drives a project forward from a finished PRD, one step at a time, by deciding whether to execute the next step, suggest options, help the user do it, or ask. Keeps a progress ledger next to the PRD so nothing is done twice. Use whenever a PRD from prd-scope exists and the user says next, what now, what's next, continue, keep going, where are we, or /prd-next. Also use whenever the user comes back after working somewhere else (Figma, Framer, an IDE, a repo, screenshots, a pasted design or code) and wants to carry on, even if they never mention the PRD, so their work is reconciled before anything is suggested.
---

# PRD Next

A PRD says what is being made. It goes stale the moment work starts. This skill keeps a second file, the progress ledger, that says where the work stands, and uses the two together to pick the next right action. The point is that the user never has to re-explain the project, and nothing already done (by Claude or by them, anywhere) gets done again.

Write in plain punctuation. No em-dashes.

## The two files

- **The PRD** (`<slug>-prd.md`) is the source of truth for what is being made. Requirement IDs are stable: never renumber.
- **The ledger** (`<slug>-progress.md`, next to the PRD) is the source of truth for where things stand: status and evidence per step and requirement, open questions with their answers, a decision log, a session log.

The script `scripts/ledger.py` (in this skill's folder) reads and writes the ledger so the bookkeeping is exact. Run it with `python3`:

| Command | Use |
|---|---|
| `init PRD` | build the ledger from the PRD (once) |
| `next LEDGER --json` | recommended step, other candidates, blocking questions, proposals awaiting a decision |
| `set LEDGER ID STATUS --evidence "..."` | ID is S# (step), R# (requirement) or P# (proposal). Statuses: todo, doing, done, changed, review, blocked, dropped, proposed |
| `answer LEDGER N "text"` | record an answer to open question N. It flags the answer as not yet in the PRD and lists the PRD lines that probably need updating |
| `applied LEDGER N` | mark that the answer has now been applied to the PRD |
| `decide LEDGER "text"` | log a decision and why |
| `log LEDGER "text"` | add to the session log |
| `status LEDGER` | counts, for "where are we" |
| `check LEDGER PRD_FILE` | is an attached PRD the current one? Says CURRENT, MATCHES (ledger behind), STALE (older version), or DIFFERS with what differs |
| `drift LEDGER` / `resync LEDGER` | detect and apply edits made to the PRD |
| `scan_canvas.py DIR --ledger LEDGER ...` | a separate script: check saved design files against hard rules and list which boards look like which step |

Find the PRD in the working directory, the uploads, or the conversation. If there are several, ask which. If there is no ledger, run `init`, say so in one line, and carry on. If there is no PRD at all, use the prd-scope skill first.

## The loop: one step per invocation

1. **Load.** If the user attached or pasted a PRD, run `check LEDGER THAT_FILE` first. Attachments are often older copies. On STALE or DIFFERS, tell the user in one line which differs and how, use the workspace PRD, and do not continue on the attachment unless they say it stands (then treat the differences as edits and `resync` from it). Then run `drift`; if the PRD was edited, run `resync`. Then `next --json`. Before choosing a step, deal with what it flags: `needs_propagation` (an answer that never reached the PRD), `uncovered_requirements` (no step owns them) and a recommended step that is `waiting_on` another step. Each is explained in the sections below.
2. **Did the user bring something?** Attachments, a Figma or other link, pasted code, screenshots, a repo path, or words like "I designed", "I built", "I finished". If yes, read `references/sync.md` and reconcile it against the ledger before anything else. To open what they brought (a Claude Design canvas link, Figma, images, code), follow `references/read-artifacts.md`, and use `scripts/scan_canvas.py` to check a saved canvas against the PRD's hard rules. This is what prevents repeated work: the user's work is a fact to record, not a step to redo.
3. **Choose the round type** from the table below.
4. **Do it.** Execution playbooks: `references/execute-design.md`, `references/execute-build.md`. Asking: `references/asking.md`.
5. **Verify, then record.** Check the result against the requirement's acceptance criteria and the hard rules. Set the status with evidence.
6. **Close out** in the format below, with the next step proposed.

Do one step, then stop. Each invocation ends with a proposed next step, so the user stays in control and can redirect.

## Choosing the round type

| Situation | Round |
|---|---|
| The step is clear, reversible, backed by `Brief` or `Derived` requirements, and nothing blocks it | **Execute**. Do it, verify it, record it. |
| There is more than one reasonable way, or the choice is the user's (visual direction, naming, trade-offs) | **Suggest**. Two or three options, one recommended, each in a line. |
| The user is doing this step themselves (designing in Figma, coding in their IDE) | **Help**. Give the constraints, acceptance checks and hard rules they need, and say what to bring back. |
| The step is blocked by an open question, is `Proposed`, is outward-facing or irreversible (publish, send, release, delete, spend), or cannot be verified from here | **Ask**. Follow `references/asking.md`. |

When a step is blocked by an open question, check whether a clearly marked assumption would let work continue safely. If it would, say what you assumed and proceed; if the assumption could waste a lot of work, ask.

## Hard rules come first

The PRD quotes the rules the source treated as non-negotiable ("never an underline", "never send on their behalf", "no API keys in the release build"). Before executing, re-read the quoted rules for the requirements the step touches. If the step would bend one, stop and ask instead of working around it. These rules are the reason the PRD exists in that form, and a quiet exception defeats it.

## Never repeat work

Before executing a step, check the ledger evidence for it and look for existing artifacts: files in the working directory, the Figma file if a connector is available, the repo. If the work is already there, it is a sync, not a build. Say what exists and move on. Reasonable doubt about whether something already exists is a reason to look, not to rebuild.

## Done means evidence

Set a step or requirement to `done` only with evidence: a file path, a link, a screenshot, a passing test. If the acceptance check needs something Claude cannot observe (a real phone, a user test, a stakeholder's yes), set it to `doing`, tell the user the exact check to run, and wait for the result. Never mark done on the strength of "it should work".

## Answers must reach the PRD

An answer recorded only in the ledger is half done. The designer or builder reads the PRD top to bottom, and a PRD that still lists a question as open, or still describes the old behaviour, sends them the wrong way. So when the user answers a question or makes a decision, carry it through the whole document in the same round:

1. `answer` it. The script lists the PRD lines that probably need updating: the requirement rows the question blocked, the open-question row, and risks or priorities that mention it.
2. **Ask what the answer adds.** Does it create a new state, case, screen or constraint that an existing requirement or spec must now cover (for example, an answer that makes the overlay speak a question adds an "asking" state to a motion spec that only had listening, thinking and done)? Write each as a new requirement tagged `Derived`, naming the answer it follows from. Keep the requirement rows tagged `Brief` word for word; amend their acceptance checks only to point at the new Derived row.
3. **Update every stale place:** the requirement rows and acceptance checks, the risk that described the question, the Open questions table (move the row to a "Resolved questions" table with the answer), and the priorities (mark the answering step done, reorder if the answer changes the order).
4. Add a line to the Changes section, run `resync`, then `applied` for that question. `next` keeps flagging the answer as "not yet in the PRD" until you do.

A resync that reports "0 changes" after an answer is a warning sign, not a success: the requirement hashes only move when the requirements did, so zero changes usually means the decision never reached them.

## Coverage and order

- **Every requirement needs an owner.** If `next` lists `uncovered_requirements`, nothing in the plan will ever check them, so they stay `todo` forever. Rules that apply everywhere (typeface, wording, logos) are best owned by a "standing rules" check at the end, and also verified inside each step as part of its acceptance check. Propose the fix (add the IDs to a step, or add a step) and edit the PRD with the user's yes.
- **Respect dependencies between steps.** The PRD can say "after step 3" or "before step 4"; the script reads those and reports `waiting_on`. When two steps feed each other (shared colour tokens and a screen that uses them), run them together or in the order that unblocks the other, and say so. Before executing any step, ask what it needs from other steps; if the PRD does not say, add the dependency to the step text and `resync`.

## Keeping the PRD honest

- **New information** (an answer, a decision, a constraint found while working) goes in the ledger with `answer` or `decide`, and into the PRD as described in "Answers must reach the PRD". Tag any new row that the user has not accepted `Proposed`, add a line to a "Changes" section at the end of the PRD, then `resync`.
- **Drift.** Work that matches no requirement (the user's or Claude's) is not wrong, but it must not slip in unnoticed. Ask whether to add it to the PRD or leave it out.
- **Re-plan checkpoints.** After about five steps are done, or when an answer shifts scope, re-read the priorities. If something should move between Now, Next and Later, propose it and edit the PRD only with the user's yes.
- **Contradictions** in the PRD or between the PRD and the user's work are surfaced in the same round, with both quotes.
- **Milestone summary** when everything in Now is done: what is real and evidenced, what is still assumed, what moves up next.

## Close-out format

Keep it short. The widget and the ledger already hold the history.

```
Did: [one or two sentences: what changed, and the evidence]
Ledger: [steps done / total, one line]
Next: [S#, the step, as Execute / Suggest / Help / Ask, and why it is next]
[at most one question, or the batched questions from references/asking.md]
```

One call to action per round. Do not recap the steps taken or restate the PRD.

## Why this shape

The user works in more than one place and comes back unpredictably. A loop that only reads the PRD would keep proposing work that is already finished. A loop that only reads the conversation would forget it. The ledger and the sync step are what let this skill handle the user's own work, from anywhere, as the best available information about where the project stands.