Launched this week
Co-Review
Read the whole repository with the agent that built it
96 followers
Read the whole repository with the agent that built it
96 followers
Agent-built code works but stops feeling like yours. Co-Review opens the whole repository as a review: comment on a line, file or folder, ask why, and the agent answers from the code. Also reviews diffs, PRs and designs. Free, open source, no telemetry.
Free
Launch Team / Built With
CourseSmithAI course videos, shorts and product videos from any source
Promoted
Hi Product Hunt, I'm Sarath, maker of Co-Review.
I build with a coding agent most days. Each diff looked fine. Six months in, the codebase worked, but I couldn't tell you where things lived or why they were built that way. It had stopped being mine.
So I built the tool I wanted: open the entire repository as a review, the way you'd read a pull request, with the agent that wrote it sitting in the thread. Comment on a line, a function, a file or a whole folder and ask why. The agent answers from the code, not from memory of a chat.
What it does:
It's a review tool with IDE features, built on Eclipse Theia, so navigation, search, Git and language servers are the real thing and everything unrelated to reviewing is gone.
Made for Claude Code (one plugin install). Native packages for Pi and Oh My Pi. Any MCP agent works: Codex, Cursor, Gemini CLI, Zed, OpenCode, Goose.
Free and MIT licensed. No account, no telemetry. Reviews live on your machine; your code goes only to the agent you chose.
Two-minute walkthrough:
Install:
curl -fsSL https://sdsvn.github.io/co-revie... | bash
I'd love to hear what you'd want to ask your own codebase. I'll be here all day.
Does coverage reset when the agent rewrites a file you already read?
@leoheo A file changed since it was marked counts as not viewed; if you mark a file as don't care while review then that will not change
@sarath_sp good, thats the behavior id want there
Last week we moved all the old stuff in our repo into an archive folder so our agents are told never to read it. My question is when Co-Review writes the map of a repo, can I tell it to leave a folder like that out?
This hits close to home — I build with a coding agent most days too, and "the codebase stopped feeling like mine" is exactly the drift I notice after a few months in. The whole-repo audit is the part I'd reach for first, before a refactor, rather than another diff-by-diff review. Curious where it starts to strain: on a big repo, does the guide stay sharp enough to be useful, or is there a size where it gets too shallow? Love that it's free, MIT, and no telemetry — that makes it an easy try for a solo dev.
Congrats Sarath! "It had stopped being mine" is exactly the feeling. I built my Mac app largely with a coding agent, and reviewing diff by diff never gave me the map. Does the audit guide live in the repo as a file I can keep up to date, or inside Co-Review?
@mr_pft The guide lives inside Co-Review, not in your repo: it’s the review’s overview, kept under ~/.co-review/workspaces/<hash>/ as the review’s JSON (with the page rendered as Markdown next to it). That was deliberate. I didn’t want to drop a file into a repo that nobody intentionally added as code.
@sarath_sp Makes sense, thanks Sarath. Not dropping files into a repo nobody chose to add is a respectful default, and keeping a Markdown copy beside the JSON means I can still read it anywhere. Good luck today!
does the agent keep its answer tied to the current commit, or can it drift if the code changes after you ask?
@neerajnathany Depends on the review.
PR review: tied to the PR. Co-Review checks it out in its own worktree, so the agent reads that snapshot. New commits refresh the review and re-anchor comments onto the new lines.
Repo audit: the guide is pinned (its first line names the commit, and the facts behind it are cached per sha), but answers in threads are live and read the code as it is when you ask. A file edited after you read it drops back to unviewed, so you can see what moved. If the guide is wrong, say so and the agent rewrites it against the current commit.
Either way, comments stay anchored to the lines they were about through later edits.
Same thing I was wondering. Coverage already flips a file back to unread once it changes, which I like. Would be nice if answers did the same, even just showing which commit they were written against, so I know when to ask again.
@0x47xavier That is a good idea, and I agree it is the gap.
Today a thread already knows when its code moved: comments are anchored to lines and re-based through later edits, so the thread follows the code. What it does not do is stamp the answer with the commit it was read against, or flag it when the code under it changes afterwards. Doing for answers what coverage does for files is the right fix.