Justy: If you’ve ever lost track of feedback because it lived in chat, a doc comment, and a copied snippet, this one feels pretty timely.
Cody: Yeah, especially now that more of the work starts in markdown before it ever becomes code. Specs, prompts, design docs, all of that is turning into the thing the agent actually edits.
Justy: Welcome to Exploring Next, episode 315. Today we’re looking at md-redline, which tries to make review feel native to the file instead of bolted on.
Cody: That part matters because the usual loop is clunky. You highlight a sentence, copy it somewhere else, paste it into a chat, then hope the model keeps enough context to respond well. md-redline cuts that down.
Justy: And that’s the user story I kept thinking about. Not enterprise process. More like a product manager, a designer, or a solo builder writing a spec at 11 p.m. and wanting a tight back-and-forth without leaving the doc.
Cody: Right, and the clever bit is that the comments stay inside the markdown file as invisible HTML markers. So the file is still the source of truth, and both humans and agents can read the same thing.
Justy: Which is appealing, but I can also see the adoption barrier. People already have docs in Notion, Google Docs, random chat threads, and GitHub issues. Asking them to move review into a local file tool is a real switch.
Cody: Totally. Though if your workflow already starts in a repo, that barrier drops a lot. You run `npx md-redline /path/to/spec.md`, it opens locally in the browser, and you’re reviewing the actual file, not a shadow copy.
Justy: And if you want the more permanent setup, there’s `npm install -g md-redline`, then `mdr /path/to/spec.md` or even `mdr /path/to/dir`. That makes it feel like a small utility, not a whole platform.
Cody: The architecture is pretty lean. No sidecar file, no database, no external service. That’s a strength because it keeps the state portable. But it also means the markdown file gets a little more encoded, which some teams will love and some will hate.
Justy: I think that’s the tension. Product-wise, invisible markers are elegant until someone opens the file in the wrong editor and gets nervous. Then again, if the workflow is local and file-based, maybe that’s acceptable.
Cody: Yeah, and the MCP server is the part that makes it feel less like a comment tool and more like a workflow tool. The agent can request a review mid-task, pause, and wait until you click Send review. That’s a real handoff.
Justy: That pause is a big deal. It creates a human checkpoint without forcing a whole meeting or a separate review app. For teams shipping specs fast, that could save a bunch of friction.
Cody: I also like that it works with Claude Code, Claude Desktop, Codex CLI, Gemini CLI, and any other MCP client that speaks stdio. So it’s not locked to one ecosystem.
Justy: The setup looks pretty direct too. `mdr mcp install` for Claude Code or Claude Desktop, `codex mcp add md-redline -- mdr mcp`, and for Gemini CLI they call out `--scope user`, which is the kind of detail that saves you a half hour.
Cody: That Gemini note is exactly the sort of thing that tells me this was built by someone who actually tried the integrations. I appreciate that. And the resolve mode is interesting too, because it adds explicit open and resolved states for human review.
Justy: Do you think this is mostly for individual builders, or does it have a shot with small teams too?
Cody: Small teams, maybe. I wouldn’t pitch it as a collaboration suite. The tool itself says it’s not a multi-user editor and not a replacement for GitHub PR reviews. That honesty helps.
Justy: That’s fair. I could see it becoming the pre-PR layer though. Write the spec, get inline feedback from the agent, tighten it up, then push it to git once it’s cleaner.
Cody: Exactly. If I were trying it this week, I’d start with one repo and one markdown spec. Install it, open the file, leave a few comments, and see whether the invisible markers feel elegant or annoying in practice.
Justy: And for a solo builder, the weekend project is obvious: take an existing prompt or design doc, wire in `mdr mcp`, and test whether your agent can pause, accept notes, and continue without losing context.
Cody: Yeah, and maybe try the plain file workflow too, without MCP, just to see the fallback. If that still feels smooth, that’s a good sign the core idea is solid.
Justy: I like that it treats review as part of the document, not a separate ceremony. That seems to fit where a lot of AI-assisted work is heading, even if the setup is a little niche today.
Cody: Yeah, niche but practical. And honestly, I’d rather use a narrow tool that respects the file than a broad one that invents another place for feedback to disappear.
Justy: If we were trying this over a weekend, I’d start with `npx md-redline` on a single spec, keep the comments short, and see whether the handoff feels as calm as it sounds. That’s enough for me for now.