Markdown, read properly
Why Annotate exists
A file lands in your lap
Someone on your team sends you spec.md. Claude wrote it, or Codex did. It is longer than anything a person would have typed by hand, and it is waiting on you.
You open it. You get a raw blob with hash marks and pipe characters, or a preview built for rendering a README, not for reading at length.
You read it anyway. You find the three things that are wrong.
Then you have to say them out loud
This is where it breaks.
You know the paragraph under Data model is wrong. The agent does not. So you type: "in section 2, third paragraph, the part about the cache — change that." Then you paste the whole document back so it has something to match your sentence against.
You just spent tokens re-sending a document the agent wrote, to describe a location you could have pointed at.
Every reviewer of agent output does this several times a day. It is the most repetitive thing in the workflow and nobody built for it.
The tools we tried first
Notion, Confluence, Google Docs. Comment threads exist. Getting the file in does not. Import, convert, repair the code blocks, share, chase a permission dialog. The document leaves the repo, gets edited, and has no way home. Every round trip is manual.
Obsidian. A good reader. The review does not sync. The person on the other end needs the same vault, the same plugins, the same setup. You are now supporting an install before you can leave a note.
GitHub. Code belongs there. A first pass on a concept does not. Leaving a comment means a branch, a pull request, and CI firing on a document that changes no code. That is configuration in front of a review, and it is why the review ends up in Slack instead, where it is unfindable a week later.
None of these is bad software. They are all built for a document that has already been agreed on. Agent output has not been agreed on yet. That is the whole point of sending it to you.
What we wanted instead
Drop the file. Read it. Mark the line. Say the thing. Send it back.
No import step. No account on the other side. No pull request until there is something worth merging.
What Annotate does
You drop a .md file on the page. It renders in the browser instantly.
You read it in a column capped at 68ch, in a serif that ships with your OS, at a contrast ratio of roughly 16:1 in light and 14:1 in dark. No web font blocks first paint. No network round trip renders your text.
You select a sentence and leave a highlight, or a highlight and a note. The highlight is painted onto the DOM by character offset, so it holds its position through re-renders instead of drifting.
You copy an unlisted link and send it. The other person reads and comments without signing in.
When the review is done, you send the notes back to the agent — each one already attached to the text it refers to — or you open a pull request against the repo the file came from. The PR is the last step, not the first.
What we build by
- The file is the unit. Not a page, not a workspace, not a doc ID. A
.mdfile you already have. - Reading is the product. Measure, line rhythm, heading hierarchy, and a scroll-spied outline. A document you are about to critique deserves to be legible first.
- A comment carries its own location. The offset travels with the note, so nobody has to describe where they meant.
- No account to read. Sign-in is for sync and sharing, not for opening a file someone sent you.
- Fewer tokens than re-pasting. Targeted notes cost less than the document plus a paragraph explaining which part of it you meant.
- The pull request comes last. Collaborate first, commit when it is settled.
Where this goes
Agents will keep producing more Markdown than any of us planned to read. Specs, PRDs, migration plans, transcripts, postmortems. The bottleneck is not writing them anymore. It is a person reading one carefully and returning something precise.
Annotate is a reading surface for people and a feedback format for the tool that wrote the file. That is the whole idea.
Drop a Markdown file to read.
It renders in the browser instantly.