OMGfixMD · how to give your LLM feedback
Guide · April 2026 · 7 min read

How to give Claude or ChatGPT feedback on 5 things at once (without it rewriting everything)

You asked Claude for a 1,800-word spec. It gave you one. It's 82% fine. The 18% that isn't is spread across six specific passages — the tone in the FAQ, the third bullet under Architecture, the paragraph on retention, and three other small crimes. You want the model to fix those six things. Precisely. Without rewriting the eighty-two other percent you liked.

And this, reader, is where the chat box quietly gives up.

TL;DR

Multi-point feedback fails in chat because prose descriptions force the model to guess which passage you mean. The pattern that reliably works is paired data: quote the exact passage, write your note beneath it, separate each block with ---, repeat. Prefix with "apply these edits; leave everything else alone." The model applies every edit in one round-trip. You can do this by hand in ten minutes. A dedicated tool (like, you know, OMGfixMD) does it in one.

Why the chat box is not your friend here

Every LLM user discovers this the same way, around the fifth comment. You've been working with the model. You've asked it for a Markdown draft. It came back with a document that is mostly right and specifically wrong in six places. You try to explain the six places. And the wheels come off.

There are four ways people try to explain those six places. All four fail at roughly the same moment, and the reason they fail is the same reason.

Failure mode 1

Typing your feedback as prose

You write something like: "Hey, the third bullet under the second heading is wrong, and also the tone in the FAQ is off, and also paragraph 4 of section 3 should say 'guests' not 'users.'" The model receives this, tokenizes it, and now has to locate three passages by description inside an 1,800-word document it just produced. On a short answer, this occasionally works. On a long answer, the model picks the wrong bullet on at least one of the three. You correct it. The turn count is now at four and climbing.

Failure mode 2

The numbered list the model is supposed to count

You escalate. You write a numbered list: "1. The bullet under Architecture. 2. The FAQ tone. 3. The paragraph about retention." The numbers feel like they help. They do not. Language models are not great at reliably counting references like "bullet three of section two" past the first two items — they can get close, but "close" is not a specification, and the paragraph you meant and the paragraph the model edited are, in fact, two different paragraphs. The list was for your benefit. The model has already moved on.

Failure mode 3

Multiple back-and-forth turns

You give up on batching. You feed the model one comment at a time. This works. It also takes five or six turns, each of which burns context window, introduces drift (the model's memory of the original file gets progressively fuzzier with every turn), and takes about ninety seconds each. You have now spent fifteen minutes doing what should have been one paste-and-go. Meanwhile the model has quietly rewritten a sentence you never mentioned, because on turn four it decided it could "improve" the transition between paragraphs. OMG.

Failure mode 4

Manual copy-paste quoting

You do the right thing, kind of. You copy a passage from the model's answer, paste it into the chat inside quotation marks, write your note beneath it, and send. This works — for one or two comments. At five it collapses, because now you're jockeying between two browser tabs, scrolling through a long answer to find each passage, and trying to keep the order of your comments matched to the order of the passages in the file. Around comment four you type "not that one, the other one" and realize you have become the problem.

The fix is not a better chat box. It's a better format.

Here is the reframe worth sitting with, because once you see it every other workaround suddenly makes sense as a symptom instead of a solution.

The chat box is a text area optimized for prose. Multi-point structured feedback about prose output is not prose. It is paired data — passage, annotation, passage, annotation — and it has to travel to the model through a channel the channel was not built for. You can force prose through the text area; you cannot force structure through it, because the text area erases the structure on the way in.

The gap isn't a missing feature in the chat. It's a mismatch between the shape of your feedback and the shape of the input field you're trying to put it through.

Once you see it this way, the fix is obvious: stop flattening your feedback into prose. Send it as paired data. Quote the exact passage, write the note beside it, use a separator the model can parse. Every pair self-contained. Every annotation anchored to its passage. No guessing.

The paired-passage-with-note format

Here's what it looks like. This is what the model actually sees:

# Apply these edits to your last answer. Leave everything else unchanged.
---

"the system can leverage a cross-functional synergy touchpoint"
[Rewrite] Too corporate. "this connects to X" is plenty.

---

"delight velocity"
[Delete] We do not measure this.

---

"The FAQ currently opens with three questions about pricing."
Move this paragraph below the product-overview section — it fits better there.

---

"moreover,"
[Delete] One use of "moreover" per page, maximum. This is the third.

---

Four comments, one message, paired data. Each block is a quoted passage followed by a note. Optional label in brackets (like [Rewrite] or [Delete]) signals intent without prose. Three dashes separate each block so the model can't bleed context between them.

When a frontier model receives this, it does not have to infer anything. It sees an instruction ("apply these edits"), four pairs, and the boundaries between them. It finds each quoted passage in its last answer via exact-text matching — which is a thing language models are excellent at — and applies the note to that specific region. It does not rewrite the paragraphs around your quoted passages, because you didn't quote them.

On the next turn, you can diff the model's reply against your list. The edits it applied will be visible at the exact quoted regions. The ones it skipped are almost always the ones where your quote had a typo or a whitespace discrepancy that prevented exact matching. Fix the quote, resend the missing block, done.

The manual recipe (works without any tool)

You do not need OMGfixMD to do this. You need ten minutes and a plain-text scratch buffer.

  1. Copy the model's full answer into a second browser tab or a plain-text editor where you can scroll and select cleanly.
  2. For each passage that needs work, copy the exact text — punctuation and line breaks included — and paste it into a scratch block in quotation marks. Write your note directly beneath the quote. Add --- to separate it from the next block.
  3. Order the blocks by document position. If your first comment is about the opening paragraph and your last is about the conclusion, the blocks should appear in that same order. This matters more than it looks — the model applies edits in a single pass, and out-of-order edits make it work harder.
  4. Prefix the whole thing with a single clear instruction: "Apply the following edits to your last answer. Leave everything else unchanged." Without this prefix, the model will sometimes rewrite surrounding passages "for consistency." With it, it almost never will.
  5. Paste the block into the chat as one message. Send.
  6. Diff the reply. The model should have applied every edit in one turn. The ones it skipped are quote mismatches; fix and resend those specifically.

This works on Claude, ChatGPT, Cursor, Gemini, and any local model large enough to hold the original answer in its context window. It is not a prompt-engineering trick. It is just a format a language model can parse without prose interpretation.

Or: use a tool that does the quoting and separators for you

We built OMGfixMD because the manual recipe, while it works, takes ten minutes and some amount of tab-juggling. The tool replaces step 2 entirely: paste the model's answer, highlight every passage that needs work, attach a note per highlight, click Copy. The tool emits the paired-passage block in the format above, pre-ordered, with separators and labels. You paste it back into the chat.

Full disclosure: we built it in an understandable fit of frustration. It's browser-only; your document never leaves your browser. Use it or don't — the recipe above works either way. But if you are reading this piece because you have spent forty-seven minutes this week typing "not that one, the other one" into a chat window, the tool is what we built for the version of you who is having that week.

The mechanism, for anyone who wants to understand why this works

This is the short version. If you write prompts for a living, the long version won't surprise you; if you don't, this is useful to have in your head the next time you're arguing with Claude about the word "moreover."

Language models parse their input as a sequence of tokens, and every token is weighted by local context — what comes immediately before and after it. When you feed a model a list of prose instructions ("fix X, also Y, also Z") alongside an 1,800-word document, each instruction token is competing for attention against every token in the document, and the document wins. The document is where the model's currently-active context lives. The prose instructions get triaged: the model addresses the one closest to whatever passage is currently most salient in its reading of the document, and then it has to re-orient for the next instruction, and the next.

When you feed the model paired data instead — quoted passage, then note — each pair is self-contained. The passage anchors the instruction to a specific region of the document. The separator prevents bleed between pairs. The model doesn't have to triage. It processes each pair as an atomic unit: locate this passage, apply this note, move on.

This is not a prompt-engineering trick. It's a consequence of how attention works on structured input. Any model capable of writing decent Markdown is capable of benefiting from structured feedback on it. The pattern has worked for every frontier model since early 2024 and it will keep working until somebody ships a purpose-built multi-edit interface natively in one of the chat apps — which, the cruel twist of course, is almost certainly coming, probably inside of a year.

Until then: paired passages, separators, one round-trip.


If you want the argument for why this should exist as a primitive in every LLM chat interface, read the manifesto. If you want the honest comparison against the other tools people reach for, read the alternatives page. If you want to try it, the tool is right there.

Questions people actually ask

Why does Claude keep rewriting the wrong paragraph when I ask it to fix something?

Because prose descriptions of a passage ("the third bullet under Architecture") force the model to infer which passage you mean, and on a long answer it usually infers wrong. The fix is to quote the exact passage alongside your note, so the mapping is unambiguous. This turns feedback from prose-the-model-interprets into paired-data-the-model-applies.

What is the best way to give ChatGPT feedback on multiple parts of its answer?

The pattern that reliably scales past three or four comments is to quote each passage verbatim, write your note directly beneath the quote, separate each block with three dashes, and send the whole set in one message with an instruction to apply the edits and leave everything else unchanged. Prose descriptions, numbered lists, and multiple back-and-forth turns all fail at five or more comments. Paired passages with notes do not.

Does this work with Claude, ChatGPT, Cursor, or Gemini?

Yes, any frontier model that accepts Markdown input. The paired-passage pattern is about how language models parse structured input — it is not specific to one vendor. It works identically in Claude, ChatGPT, Cursor's chat mode, Gemini, and any local model large enough to hold the original answer in context.

What if I have 30 comments on a long document?

The pattern scales as long as your feedback block fits inside the model's context window alongside the original answer. For 30 comments on a 5,000-word document, you're well within every frontier model's window. The practical limit is not the model — it's how long it takes you to highlight and write 30 comments. A dedicated tool like OMGfixMD brings that down to a few minutes; by hand it's closer to half an hour.

Does the model actually apply all the edits, or does it skip some?

With the paired-passage format, most frontier models apply every edit on the first turn. Skipped comments are almost always caused by a mismatch between the quoted passage and the actual text in the model's last answer — a typo in your quote, a whitespace difference, or a subtle auto-correction your editor made. Verbatim quoting is the reliability trick. If a block gets skipped, check the quote against the source first.