How to Turn AI Feedback Into a Revision Checklist
AI review comes back as six scattered notes — some vague, some contradictory, one that would wreck the part you liked. Here's how to triage it into a prioritized revision checklist: accept, reject, or defer each note, protect what must stay, and set the order before you edit.
Lock the Checklist Into a Fixed TableWhen the feedback comes back as a to-do list you can't actually do
You paste a landing-page hero into the chat and ask, "what would you improve?" Back comes a tidy list: make it more exciting, add a stronger benefit, mention saving ten hours a week, add urgency, explain how it works, make it shorter. It reads like a to-do list. So you start doing it — and three items in, the draft is worse. "Shorter" and "explain how it works" fight each other. "Ten hours a week" is a number nobody verified. "More exciting" isn't a change you can make; it's a mood. And somewhere in the reshuffle, the four things that were already working quietly went missing.
That's the problem this guide solves. AI feedback arrives flat — every note weighted the same, none tied to a specific line, some of them tastes rather than fixes, and a few that contradict each other or push the piece past what you can back up. Handing that straight to "now revise it" is how a good draft turns into a generic one. The fix is to put a step in between: turn the feedback into an AI revision checklist before you change a word. The model can produce the feedback, and it can even draft the checklist for you — but which notes are right for this draft, which would cost you something you meant to keep, and what order to make the changes in are decisions you make. NewPrompt gives you the structure to sort the notes into; it doesn't sort them for you, and it doesn't touch the draft.
Why AI feedback isn't a revision plan yet
A model asked to critique will critique generously. It has no stake in your draft, no sense of which lines you fought for, and no cost for suggesting one more change — so it returns everything it notices, presented as a flat, equal list. That list looks actionable because it's formatted like actions, but it's missing everything that makes feedback a plan:
- No priority. A wrong fact that could get you in trouble sits in the same bullet style as "consider a punchier verb." Nothing tells you which one matters.
- No target. "Tighten the intro" doesn't say which sentence — so applying it means guessing, and the guess often rewrites more than the intro.
- Suggestions dressed as requirements. Most feedback is a proposal you're free to decline; a flat list makes every proposal look mandatory.
- Unresolved conflicts. "Make it shorter" and "explain the mechanism" can both be reasonable and still can't both happen in one hero line.
- Silent scope creep. Six small suggestions, each fine alone, add up to a different, longer, blander draft than the one you started with.
- No memory of what's good. The critique names problems; it never names the parts you need to survive the edit, so nothing is protected.
Step 1: Separate the feedback from the instruction
Before anything gets prioritized, read each note and label what kind of note it is. A workable set of types: factual (a claim that's wrong or unsupported), clarity (hard to follow), tone (off-voice), structure (order or format), audience (written for the wrong reader), missing information (a gap), risk-sensitive (a promise, legal line, or commitment), preference (a taste with no concrete change), and out-of-scope (a suggestion for a different piece). The point of typing each item is that a factual problem and a stylistic preference are not the same weight of thing, and a flat list hides that. Naming the type is the first move that turns "feedback" back into "a decision you're about to make."
This is also where feedback stops being an instruction. A suggestion is a proposal, not a command — "add urgency" is the model's idea, not a requirement you inherited, and you're allowed to decline it. Typing the note as a preference rather than a fix is how you give yourself permission to say no to it later without feeling like you skipped a step. Nothing here needs a tool yet; it's a read-through with a label on each line, and it's the read-through that keeps the next four steps honest.
Step 2: Turn each note into a checklist row
Now give every note a row with the columns a real revision decision needs: the feedback item, the exact section it touches, its type, why it matters, a priority, what it must not break, and a verdict — accept, reject, or defer. That last column is the whole point: a checklist isn't a list of edits to make, it's a list of decisions you've made about which edits to make. "Reword the CTA — accept — high — keep the button verb" is a row you can act on; "improve the CTA" is not.
A checklist earns its keep by coming back in the same shape every time, so it stays comparable from one revision round to the next. The Markdown Output Builder is where you lock that shape: build a prompt that forces the answer into a fixed table — one row per feedback item, a priority column, a decision column — with its Required Tables rule so the model can't collapse the checklist back into prose and its Strict setting so the columns and headings don't drift between runs. Be exact about the division of labor: the builder pins the table's structure; the triage judgment lives in the prompt text you write and in your own AI's answer, which you then read. It contracts the format, not the content — it doesn't decide a single verdict. If you'll run this on critique after critique, the Prompt Template Builder holds the same prompt as a reusable template with a `{{feedback}}` slot and a `{{draft}}` slot, so each new review runs through the same triage instead of one you rebuild by hand. Both tools assemble and format prompts in your browser; the checklist itself is produced when you run the prompt in your own assistant.
Step 3: Write down what the revision must preserve
The most common way a revision goes wrong is that it fixes a real problem and loses something that was never up for discussion. So before you accept anything, write the preserve list: the parts that must survive no matter what the feedback says. For a hero that might be the core promise, the approved facts, the brand voice, the length, and a hard "add no claim we can't back." Here "preserve" is a filter on the feedback, not an editing trick — any note that can only be satisfied by breaking a preserve item gets rejected or reshaped on the spot, before it ever becomes an accepted row.
The preserve list also gives your rejections a backbone. A "reject" is a decision you should be able to defend, and "it breaks a thing I decided to keep" is a defensible reason. The Convert a Feedback Thread to a Prompt resource is a good model of making those calls stick: it takes a critique thread and carries each rejection forward as an explicit avoid-rule with its reason attached verbatim, alongside the accepted direction as a requirement — so the walked-back suggestion can't quietly return the next time you generate. It's built to distill a resolved thread into a reusable prompt rather than to triage one draft's feedback, but the shape transfers: an accept is a requirement, a reject is an avoid-rule with a reason, and both are worth recording so the decision holds.
Step 4: Prioritize, and resolve the conflicts on purpose
With every note typed and filtered, set priority — and be honest that priority is your judgment, not a fact the model computed. A rough scale that holds up: critical for anything factual, risk-sensitive, or aimed at the wrong audience; medium for clarity and structure; low for polish and pure preference. The scale isn't the answer, it's a forcing function — it makes you say out loud that the unsupported claim outranks the punchier verb, which is the call a flat list let you skip.
Priority is also how you resolve conflicts instead of averaging them. When "make it shorter" and "explain how it works" both land on the same hero line, you can't do both, so the checklist has to pick one and mark the other rejected or deferred — not quietly attempt a compromise that does neither well. "Defer" is worth its own column here: some feedback is right but belongs somewhere else (the mechanism explanation is a job for the section below the hero, not the hero), and deferring it is a real decision, not a dodge. What you're producing at the end of this step is an ordered set of accepted changes, a list of rejects with reasons, and a defer pile — a plan, not a pile.
Step 5: Apply the accepted rows, then check what actually moved
Only now do you touch the draft, and you touch it one accepted row at a time rather than handing the model the whole checklist and asking for a new version — that's how the good parts get re-rolled. Applying a single decided change without disturbing the rest is its own discipline, and the Repair AI Output with a Repair Prompt resource is the shape for it: it restates the requirement, names the specific fix, and tells the model to change only that and keep everything already correct unchanged. It's built for format violations, but the pattern is the same for an accepted revision — one change, nothing else. This guide's job ends at deciding the change set; executing each change safely is where a repair prompt takes over.
Then confirm the revision did what the checklist said and nothing more. Paste the before and after into a diff — the Compare Two AI Outputs resource shows what that looks like: a mechanical, word-level view of exactly what changed, with an added clause or a reworded line surfaced next to the edit you meant to make. Read it for one thing: did anything move that wasn't on the accepted list? A diff is deliberately neutral, though — it shows that the text changed, never whether the change improved the piece. Accepting a row didn't make the edit correct; it made it intended. Whether the revised draft is actually better, and whether it still holds every preserve item, is the read you do yourself once the diff tells you where to look.
Common mistakes
The ways a revision goes sideways before it even starts:
- Applying the feedback in order. The model's list has no priority in it; working top to bottom treats a typo fix and a strategic rewrite as equals.
- Treating every suggestion as required. Most notes are proposals you can decline; if you can't reject anything, you're not triaging, you're transcribing.
- No preserve list. If you never write down what has to stay, every good line is fair game for a "better" one that isn't.
- Averaging a conflict. When two notes contradict, picking a mushy middle satisfies neither; the checklist should choose one and mark the other.
- Handing the whole checklist to the model at once. Batch-applying invites a full rewrite; accepted changes go in one at a time so you can see each one.
- Reading a clean diff as a good revision. A diff shows what moved, not whether it should have — a small, tidy change can still be the wrong one.
- Rejecting silently. A dropped note with no reason recorded is a decision you can't defend later and might accidentally reopen; write down why.
A worked example: six notes on a hero line
Take the landing-page hero from the top, run its feedback through the checklist, and watch a flat list become an ordered decision. The draft is the kind of thing the Landing Page Hero Copy Prompt produces — hero copy that marks any claim it can't back as [needs evidence] instead of inventing one — which is exactly the instinct the checklist applies when it rejects the unverified "ten hours a week" line rather than letting it into the revision.
Six flat suggestions become an accept / reject / defer checklist, a preserve list, and a revision you can checkDRAFT (needs work, not a rewrite):
"AI meeting notes for remote teams. Get summaries, action items,
and searchable decisions after every call."
THE AI FEEDBACK (asked: what would you improve?):
- Make it more exciting.
- Add a stronger benefit.
- Mention saving 10 hours per week.
- Add urgency.
- Explain how it works.
- Make it shorter.
WHY YOU CAN'T JUST APPLY IT:
- "save 10 hours per week" is a number nobody verified -> unsupported claim.
- "shorter" and "explain how it works" pull in opposite directions.
- "more exciting" is a taste, not a change you can make.
- "add urgency" may clash with a calm product's voice.
THE REVISION CHECKLIST (feedback triaged, draft untouched):
feedback item type priority decision note
stronger benefit clarity high accept name the outcome, no new claim
save 10 hours/week factual/risk high reject no evidence; do not invent proof
explain how it works structure medium defer belongs below the hero, not in it
make it shorter structure medium accept wins the clash with "explain"
more exciting preference low reject vague; no concrete change to make
add urgency tone low reject off-brand for a calm product
preserve (must survive): remote teams, summaries, action items,
searchable decisions, no unverified claims.
SAFER REVISION (accepted rows only, facts intact):
"Turn every remote meeting into clear summaries, action items, and
searchable decisions, with no notes to write by hand."
REVIEW (before -> after):
- diff shows: length held, four core facts kept, no "10 hours" line added.
- your read: the benefit is sharper, with no manufactured urgency.
- still your call: does "no notes to write by hand" overreach? you decide.Where this fits in NewPrompt
NewPrompt has no button that reads a critique and hands back a revision — and that gap is deliberate. What the site gives you is the scaffolding for the decision, not the decision: the Markdown Output Builder builds a prompt that forces the checklist back into the same fixed table shape every round, so your accept, reject, and defer columns stay comparable; the Prompt Template Builder saves that prompt with a `{{feedback}}` slot so the next critique runs through the same triage; and the Convert a Feedback Thread to a Prompt resource keeps the reason behind each rejection attached, so a note you dropped can't quietly reappear. Each of them shapes the plan; none of them decides which row is an accept — that call is yours on every line.
It helps to know when this isn't the job you have. If your feedback is a volume of comments from many people — reviews, survey responses, a stack of support tickets — that's aggregate analysis, and the AI Customer Feedback Analysis Workflow is the fit: it turns a pile of raw comments into ranked themes for a product or support lead, a different job from triaging one reviewer's critique of one draft. And once your checklist has decided a specific change, applying it without breaking the good parts is its own separate discipline, which is why the last step hands off to a repair prompt rather than re-teaching surgical editing here.
What you hold when the triage is done isn't a better draft yet — it's a record of decisions: this note accepted and why, this one refused and on what grounds, this one parked for the section below the hero. That record is the real output of the work, and it belongs to you. A critique can name a dozen problems and a table can line them up in tidy rows, but ranking them, refusing the ones that would break what you set out to protect, and sequencing the rest is editorial judgment — and on your own draft, nobody else is holding the pen. Feedback is a proposal; the checklist is where you answer it, one decision at a time.