MRDown 2026: Verify AI Redrafts Before You Republish

September 5, 2026 · ThreadGrab

The most common way a repurposed X thread goes wrong is not the thread. It is the rewrite. You grab a public thread as Markdown, hand it to an AI to restyle into an X Article or a LinkedIn post, and the model quietly changes a number, drops a caveat, or splits one claim into a stronger one. The output reads perfectly. It is simply no longer what the original author said.

MRDown is a macOS-native Markdown viewer and editor, MIT-licensed and free, that grew out of one developer's annoyance with the .md files Claude Code keeps generating. Its showpiece is a capability almost no Markdown app ships: it reads you the diff of what your AI just rewrote. Version 1.14.0 landed September 2, 2026. For anyone who repurposes grabbled threads with AI help, MRDown is best understood not as another editor but as the meaning-drift check between an AI redraft and a public republish.

Why the rewrite is where repurposing breaks

ThreadGrab turns a public thread into Markdown so you can edit, repackage, or republish it elsewhere. The moment you paste that Markdown into an AI composer and ask for a "more engaging" version, you lose the ability to see what actually changed. Models do not tell you which sentence they reworded and which they strengthened. Without a diff, every repurposed thread ships on faith.

The failure is rarely dramatic. An original that says "roughly half of the beta testers reported faster load times" becomes "most beta users saw drastically faster load times." The meaning did not reverse — it drifted. For archived, attributed content, drift is worse than deletion: the wrong version now carries the original author's name.

What MRDown actually does

MRDown started (the author's own words) as a two-hour project to preview .md files without opening a heavy editor. It became a full viewer-and-editor with one differentiator. The features that matter for a repurposing workflow:

• Version history with diffs. Every save — and every rewrite from outside the app — quietly keeps a timestamped version. The History panel puts any two versions side by side; only the words that differ are marked, and unchanged passages fold away.
• Three-column conflict rescue. If something changes the file on disk while you hold unsaved edits, MRDown shows three columns — last save, what is on disk, your edits — and flags only the lines both you and the other writer changed. Nothing is silently overwritten or lost.
• Git HEAD joins the list. In a Git repository, your committed version appears in the same history, so the diff against what you last committed is one click away. Git is entirely optional.
• Compare any two files. ⌘⇧D diffs two documents side by side in the same view — including two .docx files that MRDown opens as Markdown.

For a tool that people reach for when an agent is editing their files, that last point matters: MRDown does not know which application wrote a change (macOS does not record it), but it records that something changed the file on disk while you were not looking, which is exactly the failure most editors hide.

The grab → verify pipeline

Here is the workflow MRDown fits into. It assumes you already captured the thread as Markdown.

1. Grab. Capture the public thread as Markdown with the ThreadGrab API or a tool in your archive stack. Save it to a local folder, ideally inside a Git repo.
2. Rewrite with an AI. Point your AI composer at the Markdown file and ask for the repurposed draft. Tell the model to edit in place or save to a new draft file.
3. Diff the redraft in MRDown. Open the History panel (clock icon) and compare the pre-AI save against the post-AI save, or compare the two draft files with ⌘⇧D. Only the changed words light up, so a substituted number or a dropped "not" is visible in seconds.
4. Confirm or reject each change. Restore any version in one click, non-destructively — nothing is written until you save. Mark the claim boundaries you are not willing to hand to an AI.
5. Republish. Export the verified Markdown to HTML (⌘⇧E) or copy it into your X Article / LinkedIn / newsletter composer with confidence.

The step most people skip is the third. Adding a diff check between the AI redraft and the source turns a blind republish into a reviewed one — without reading two long documents line by line.

Side-by-side version check in code

If you would rather verify inside the terminal, the same logic is a single diff command. This is the byte-identical command pair used in both places:

# works on Linux and macOS; USERNAME is the X handle to archive
curl -s https://threadgrab.com/api/profile/USERNAME \
  | jq -r '.[] | "# \(.author)\n\n\(.text)\n---"' > original.md

# after the AI writes a repurposed draft, spot every drifted line
diff -u original.md repurposed.md

MRDown gives you the same signal in a visual form — and, unlike a terminal diff, it knows that a cosmetic wording change and a meaning-altering one are both just "changed lines," so it becomes your judgment to read each highlighted word.

Where MRDown sits versus the rest of the stack

MRDown does not grab threads and it does not publish them. It owns the narrow, easy-to-skip step in between: proving that what you are about to publish still says what the original said.

The authoring side that made it

MRDown is open-core: the repository is the whole app, MIT, and stays MIT. The author has stated the paid features to come — AI explaining a diff, project-wide search, authenticated remotes — will live in a separate paid repository. For the repurposer, the verified facts you can rely on today: in-place editing swaps the reading view into an editor, the file on disk is never rewritten by the app itself (which keeps the diff honest), and it renders tables, code, Mermaid, KaTeX math, and task lists. It is signed and notarized with an Apple Developer ID, and runs on macOS 10.15 and later.

Limitations worth knowing

• macOS-only binaries. It is built with Tauri and could run on Windows in principle, but no Windows build is distributed and there is no Windows code-signing certificate.
• It does not know which app changed the file. macOS records no such thing. MRDown knows a change happened on disk, not that Claude did it — which is why a dedicated diff step matters for attribution-heavy repurposing.
• The diff is your judgment. MRDown marks changed words; it does not judge whether a change flips meaning. For a factual claim you are attaching an author's name to, read each highlighted word yourself.
• Early-stage project. The rapid release cadence (six versions through August to v1.14 on September 2) means features move fast; verify current behavior in the app before you bet a weekly pipeline on it.

Keep the provenance with the content

The threadgrab habit pairs naturally with MRDown. Grab once, keep the original Markdown as your source of truth, and never let an AI rewrite be the only version in the folder. When you store original.md and repurposed.md together, the diff is always reproducible — which is exactly what you want if a republished thread is ever challenged on attribution.

# keep both versions in one folder so the diff stays reproducible
mkdir -p ./thread-2026-09-05 && cd ./thread-2026-09-05
mv ~/original.md ./original.md
# hash both; store the hashes with the files
sha256sum original.md repurposed.md > checksums.txt

Archive the original. Diff the rewrite. Then publish with the source beside the version that carries your name.

FAQ

Last verified: September 5, 2026 · Sources: MRDown GitHub repository (README, v1.14.0 release, September 2, 2026), MRDown project homepage.