---
name: prd-change
description: Handles a new ask, a changed mind or a reversed decision after a PRD already exists, by showing what it touches before anything is edited, then updating the PRD and the progress ledger together. Use when the founder, client or user says actually, can we also, change X to Y, drop X, we decided, the client wants, new requirement, scope change, or reverses an earlier answer, and a PRD from prd-scope exists. Also use when feedback or a new brief contradicts finished work.
---

# PRD Change

A PRD is only useful while it matches what people now want. When the ask changes, the usual failure is quiet: the new thing gets built or designed, the PRD and ledger still describe the old thing, and finished work that the change invalidated is still marked done. This skill makes a change visible first, then updates the PRD and the ledger in one pass.

Write in plain punctuation. No em-dashes.

## Rules that do not change

1. **Show the impact before editing anything.** Never change the PRD on the strength of a sentence in chat. First list what the change touches, then get a decision.
2. **Keep the words of the change.** Record who asked, when, and the exact wording. A paraphrase hides what was actually said.
3. **Finished work is never silently invalidated.** If a change breaks something already done, that step or requirement goes to `review` and the user is told, with the evidence it relied on.
4. **A change to a quoted hard rule is a rule change, not an edit.** Quote the old rule and the new wording side by side, and ask for a yes before changing it.
5. **Do not widen the change.** Add only what was asked. Anything extra Claude thinks of is `Proposed`, separate.
6. **Requirement IDs never move.** A removed requirement is marked dropped with the reason, not deleted and not renumbered.

## Workflow

1. **Find the files and check they are current.** The PRD and its `*-progress.md`. Run `drift` and `resync` from the prd-next skill (`scripts/ledger.py`) if the PRD was edited. If there is no PRD, use prd-scope first.
2. **Capture the change.** In one or two lines: who asked, the exact words, and which of these it is (see `references/change-types.md`): new requirement, changed requirement, removed requirement, reversed decision or answer, priority or deadline change, scope change, or a clarification that changes nothing. If it is a clarification, say so, add it as a note, and stop.
3. **Measure the impact.** Run `python3 scripts/impact.py impact LEDGER --reqs R# --text "<the change words>"` (this skill's folder). Use `--reqs` when the user names the requirements, and `--text` to find requirements that look similar, which catches duplicates and conflicts. Read the result: earlier decisions the change may reverse (name them in the impact block), requirements in play, quoted Brief rules touched, steps that own them, finished work that must reopen, steps waiting on those, and open questions that touch them.
4. **Check the change against the Brief's hard rules and against itself.** Does it contradict a quoted rule? Does it contradict another requirement or an earlier answer? Name both sides with quotes. Do not resolve the contradiction yourself.
5. **Present the impact in one short block**, then ask for the decision. Format:

   ```
   Change: [who, the words]
   Touches: [requirements and steps]
   Reopens: [finished work, or "nothing finished is affected"]
   Conflicts: [quoted rule or earlier answer, or "none"]
   Effort: [what has to be redone, in steps, not hours]
   Options: [Apply now / Move to Later / Decline / Ask the founder first]. Recommended: [one], because [reason].
   ```

   Keep to one question. If the founder is the one who must decide and the user is only relaying, offer to draft the question to send (a short message with the default).
6. **Apply, in one pass, once decided.** See `references/applying.md` for the exact edits. In short: PRD requirement rows and acceptance checks, priorities, risks, open questions, a dated line in the Changes section; then `resync`; then `set` affected items to `review` or `todo`, `decide` with the reason, `log`.
7. **Close out** in the prd-next format: what changed, ledger line, the next step, at most one question.

## When the change comes from the user's own work

If the user changed the design or code themselves and it differs from the PRD, that is a sync, not a request. Use prd-next's `references/sync.md`. If the user says "update the PRD to match what I made", treat it as a change of type "changed requirement" with their work as the source.

## When the change comes in several at once

A list of feedback is many changes. Handle them as a batch: run the impact for each, group by the step they touch, and present one table with a recommendation per row. Ask for decisions on the high-impact rows only, and apply the low-impact ones together after one yes.

## Why this exists

Changes after sign-off are where scope creeps, work is repeated and nobody can say what the current brief is. A fast, honest impact check lets the user say yes to a change knowing its cost, and keeps the PRD true.