---
name: prd-feedback
description: Turns a pile of comments, review notes, call notes or messages from a founder, developer, QA, client or user into a sorted list against the PRD, so each comment becomes a defect, a change request, an answer to an open question, a new question, a confirmation or no action. Use when the user pastes or attaches feedback, comments, review notes, a Slack or email thread, a call transcript, or says the client sent comments, here is the feedback, triage this, or what do I do with these notes, and a PRD from prd-scope exists. Also use when two people gave opposite feedback.
---

# PRD Feedback

Feedback arrives as one messy block: five opinions, two bugs, an answer buried in a sentence, praise, and a new idea. If it goes straight into the work, answers are missed, opinions become requirements, and two people's opposite comments quietly overwrite each other. This skill sorts the block against the PRD first, then hands each piece to the skill that owns it.

Write in plain punctuation. No em-dashes.

## Rules that do not change

1. **Keep who said it.** Every item carries the speaker and their role (founder, client, developer, QA, user, unknown). A comment from the person who decides is a decision. A comment from anyone else is input until the decider says yes.
2. **Split before sorting.** One comment can hold three things. Break it into single points, keeping the speaker's own words for each.
3. **Never turn a comment into a requirement silently.** Nothing enters the PRD from this skill without a yes. The output is a triage, not an edit.
4. **Opposite comments are shown, not settled.** If two people disagree, put both quotes side by side and name who decides. Do not pick.
5. **An answer is only an answer if it answers an open question.** Match it to the question, quote the words, and let prd-next record it. A comment that merely sounds like an answer stays a comment.
6. **A defect on finished work reopens it.** Say which step, and what evidence it relied on.
7. **Unclear is its own class.** If the point cannot be read two ways with confidence, it goes to `ask`, with the one question that settles it. Do not guess the intent.
8. **Praise and context are kept, not dropped.** Record them as `note` so the handoff can quote what was liked.

## Classes

See `references/classes.md` for each class, its test and where it goes next. In short:

| Class | Meaning | Goes to |
|---|---|---|
| `defect` | Finished or claimed work does not meet a stated requirement | prd-next: set the step to `review`, log |
| `change` | Asks for something different from the PRD (new, changed, removed, reversed) | prd-change |
| `answer` | Settles an open question | prd-next: `answer`, then update the PRD |
| `question` | The commenter asks something the PRD should answer, or exposes a gap | New open question, with an owner |
| `confirm` | Agrees with a decision or requirement already in the PRD | Log it, note who agreed |
| `conflict` | Disagrees with another comment or with a quoted Brief rule | Show both sides, name the decider |
| `note` | Praise, context, preference with no ask | Keep for handoff |
| `ask` | Cannot be read with confidence | One question back to the person |
| `out` | About something the PRD marks out of scope | Log, no action unless the decider widens scope |

## Workflow

1. **Find the files.** The PRD and its `*-progress.md`. Run prd-next's `check` if the user attached a PRD, and `drift` / `resync` if the PRD was edited. If there is no PRD, use prd-scope first. If the feedback is about work (a canvas, a build) that has not been read since the ledger was last updated, run prd-next's sync before judging defects.
2. **Get the speakers.** If the feedback does not say who wrote each part, ask once: who sent it and what is their role, and who decides. Do not guess authority.
3. **Split and match.** Save the feedback to a file and run `python3 scripts/triage.py split FILE --from NAME --role ROLE` to break it into single points, then `python3 scripts/triage.py match LEDGER ITEMS.json` to attach, for each point, the requirements, open questions, decisions and quoted rules it resembles, the step status, and signals (defect words, question marks, praise). The script suggests; it does not decide. Read every item yourself.
4. **Classify.** Write `<slug>-feedback.md` next to the PRD. For each item: ID (F1, F2...), speaker and role, the words, the class, the requirement or question it touches, the effect in one line, and the route. Then run `python3 scripts/triage.py lint FILE LEDGER` and fix what it lists.
5. **Show the triage, short.** Counts per class, then the items that need a decision, highest impact first (defects on finished work, conflicts, changes that touch a quoted rule). Use the format below. Ask for decisions on those only.
6. **Route after yes.** For each class, follow `references/routing.md`. Answers and defects go through prd-next. Changes go through prd-change, as a batch if there are several. New questions are added to the PRD and ledger with an owner. Log everything with the speaker.
7. **Close out** in the prd-next format: what was sorted, what changed in the ledger, the next step, at most one question.

## Output format in chat

```
Feedback from [who, role], [date]: [n] points
Defects: [n]   Changes: [n]   Answers: [n]   Questions: [n]   Conflicts: [n]   Notes: [n]   Unclear: [n]   Out of scope: [n]
Need your decision:
 - F3 (defect, Priya, QA): "..." breaks R5, reopens step 6
 - F7 vs F9 (conflict): Raj says "...", Meera says "...". Decider: [name]
Ready to apply on your yes: [list of answers and notes]
File: [slug]-feedback.md
Question: [one]
```

## Many people, one document

When feedback comes from several people, keep one block per person and mark who decides. If the decider has not spoken, say so and route their items as `ask` or `change` pending their yes. Never let the loudest or most recent comment win by default.

## Why this exists

Feedback is where a PRD is most likely to drift: answers are lost in threads, opinions are built as if they were requirements, and finished work is quietly broken. Sorting first makes every comment visible, owned and routed, and keeps the person who decides in the loop.