How to comment on a Markdown file the LLM will actually read
Claude returned 1,800 words. It's 82% fine. The 18% that isn't is spread across five specific passages — a wrong assumption in section two, a missing edge case, a tone problem in the third bullet, a hallucinated dependency, a step that's out of order. You want to fix those five, not rewrite the whole thing. So you start typing.
You type the first correction. Forty-five seconds. You re-read it; you're proud. Four to go.
By the third one, the original answer has scrolled out of view. You stop describing the location and just paraphrase the fix: "and somewhere there's a paragraph on retention that needs to say it more directly." You know, as you type it, that the model is going to pick the wrong paragraph. You send it anyway. By the fourth, you decide — audibly, in the voice of a person who has given up — the model will probably catch those on its own. It will not. Three of five make it into the message. The next answer comes back wrong on the other two.
That is what "commenting on a Markdown file" looks like in 2026 when the reader is the language model that wrote it. It looks like quietly losing two corrections per round to the writing tax of the chat box. This post ranks every way you might comment on a Markdown file by the one test that actually matters — does the feedback make it back to the model intact — and then shows the format that passes it.
Markdown has no native comment syntax, but the case that matters in 2026 isn't a syntax question — it's that you're trying to send five corrections back to a language model through a one-line chat field. By the fourth correction, the original has scrolled away and you give up on points four and five. The format that works is paired passages: each note attached to the verbatim quote it refers to, separated by ---, sent in one message. Do it by hand in a scratch buffer, or use PassbackAI to highlight passages in a browser tab and export the block in one click. The full walkthrough is in the guide; the argument for why the chat box can't carry five corrections is in the manifesto.
Why the chat box can't carry five corrections
There is exactly one place the feedback has to land: back in the chat with the model that wrote the answer. Anywhere else is a detour, because anywhere else the model can't read it. Comment on the file in a doc you keep on your hard drive and the model never sees it. Annotate it inside the rendered Markdown in your editor and the model never sees it. The chat is the workspace because the chat is the only surface that returns. So the real question — the only one — is the one you actually face every time: why not just type it into the chat.
And for one correction, you can. For five, you can't — not because the chat box is broken, but because writing each correction in prose, with the original answer scrolled out of view, is hard enough work that the last two get silently downgraded. The gap isn't in the chat box's plumbing; the gap is in you, by the fourth correction, deciding that points four and five aren't worth typing. (The full argument is in the manifesto; this post is the field manual that demonstrates it.)
What you need is a format that does the writing tax for you — that lets you raise five points as comfortably as you raised the first one, and lands all five back in the chat anchored to the exact passages they refer to, so the model can't pick the wrong target on the next turn.
Every way to comment on Markdown, ranked by whether the model acts on it
There is no shortage of ways to leave a comment on a Markdown file. Almost none of them are built for the one job that matters when the reader is the model that wrote the draft: getting five specific corrections back into the chat, each still attached to the passage it's about. Ranked from worst to best for exactly that:
| Method | Where it shines | Getting five fixes back to the model |
|---|---|---|
| Slack message / screenshot | A fast "hey, look at this" to a human standing nearby. | Sends a picture of a document, not a document. Comments lose their anchors and nothing lands in a form the model can read. Dead end for the round-trip. |
| Google Docs comments | Threaded review with colleagues who already live in Docs. | The comments tear off their anchors the moment you paste the text back into chat. You end up retyping every note into the box — the exact tax this post is about. |
| Notion comments | Keeping feedback beside a doc in your team's workspace. | Another surface the model never sees. Export flattens the mapping between note and passage, and you rebuild it by hand before the model can use it. |
| GitHub PR review comments | Line-anchored review of a code diff, with teammates. | Ideal for humans reviewing a diff; invisible to the chat model. The comments live in the PR, not in anything you can hand the model as input. |
| HTML comments in the .md | Private notes-to-self inside a file you'll edit later. | Read by the model as literal text, not as annotations — and you still describe the location in prose. Bonus hazard: they pass through to rendered HTML and your RSS feed. |
| Native Markdown comment syntax | Nothing — it doesn't exist. | CommonMark has no comment syntax and never adopted a proposal. There is simply nothing to reach for. |
| Paired passages (by hand, or via PassbackAI) | Exactly this job: five corrections on a long answer, headed back to the model. | Each note rides its verbatim quote; the whole set exports as one block the model applies in a single round-trip. The one method that survives the trip back to the chat. |
Every row above one is a good tool doing a different job — reviewing with a person. The bottom row is the only one built for reviewing with the model. That's the method the rest of this post is about.
The format that wins: paired passages
It's not a tool. It's a shape. Each comment is a verbatim quote from the model's answer followed by your note, separated by ---, sent back in one message with one instruction at the top: apply these edits; leave everything else unchanged. The model maps every note to its exact passage and applies the whole set in a single round-trip. The export block looks like this:
# Apply these edits to your last answer. Leave everything else unchanged.
---
"the system can leverage a cross-functional synergy touchpoint"
[Off tone] too corporate. "this connects to X" is plenty.
---
"delight velocity"
[Delete] we do not measure this.
---
"moreover,"
[Delete] One use of "moreover" per page, maximum.
---
The full walkthrough — why this works, the manual recipe you can do in any plain-text editor, and the mechanism for anyone who wants to understand why structured input beats prose — is in the guide. PassbackAI, the review-and-passback tool for AI drafts, automates the highlighting and the export.
The footnote: HTML comments inside the file
One related question gets asked enough that it earns a section: "can't I just leave HTML comments in the Markdown itself?" In a .md file you own and never hand off, yes:
## Introduction
Welcome to the product. <!-- @tom — too corporate? -->
Works as a personal sticky note. Won't help you with the chat-box case above, because an HTML comment inside a chat message is read by the model as text, not as a review annotation — and even if the model does read it, you've still typed the location in prose ("the comment after the Introduction heading") which is the exact problem we just solved. HTML comments answer a different question: leaving notes to yourself inside a file you will edit later. They are not the format that returns five corrections to a chat.
One catch worth knowing: HTML comments pass through to rendered HTML. The first time a reviewer forgets to delete one before publishing, they learn that <!-- --> is very much visible in your RSS feed and your search index.
None of this requires a smarter model. The model that wrote your 1,800-word answer already applies five clearly-anchored corrections in one paste when it gets them. The bottleneck was never the model — it was the four minutes between reading the answer and giving up on points four and five. Move the writing out of the chat box, and the bottleneck goes with it. That's the whole field manual; the rest is taste.