PassbackAI Open PassbackAI →
Field Manual · April 2026 · 6 min read

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 is about the format that stops that from happening, and the one comparison that matters: the chat box you would otherwise be typing into.

TL;DR

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.

The format that does work

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. The browser tool that automates the highlighting and the export is right here.

VerdictThe only method that scales past three comments on a long LLM answer. The paired-passage pattern works by hand; a tool makes it one click.

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.

What changes when the format does the writing tax for you

Step out of the chat box for the feedback step, and the things that used to happen in your head stop happening.

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 you reading the answer and you 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.


The chat box is fine for one correction. For five, you can't — and the moment around the fourth, when you decide points four and five aren't worth typing, is the gap a paired-passage block fills. The format is the field manual.

Questions people actually ask

What is the best way to give an LLM feedback on a Markdown file it just wrote?

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 prefixed with "apply these edits; leave everything else unchanged." This gives the model an unambiguous mapping between your feedback and the exact passages — the kind of precision prose descriptions like "the second bullet under Architecture, not that one, the other one" cannot provide. The full walkthrough is in the guide; PassbackAI is the tool that automates the highlighting and the export.

Why is commenting on a Markdown file from an LLM different from commenting on any other Markdown file?

Because the reader is going to apply the edits, and the only place to send those edits is the chat box you got the answer from. The chat box is fine for one correction. For five, it isn't — by the fourth, the original answer has scrolled away and points four and five quietly get downgraded to "the model will probably catch those." Three of five make it through. The next answer comes back wrong on the other two. The format that scales is paired passages — each note attached to the verbatim quote it refers to, sent as one block. The full walkthrough is in the guide; PassbackAI is the browser tool that emits the format in one click.

Can I use HTML comments inside a Markdown code fence?

No. Inside a fenced code block, HTML comments render as literal text. They only work outside code blocks.

Do HTML comments pass through to rendered HTML?

Yes. They appear in the generated HTML output as HTML comments. Most browsers don't display them; most scrapers and feeds do see them. Don't put anything in a Markdown HTML comment that you'd mind appearing in an RSS feed.

Is there a native Markdown comment syntax?

No. CommonMark has no native comment syntax and no proposal has been adopted. There have been historical attempts (%% like this %%, reusing [//]: #), none accepted. The working assumption is that Markdown will not get one — tooling on top of Markdown is the path.