https://crit.md - a CLI tool for reviewing AI coding agent output like a GitHub PR.

I got frustrated with Claude Code and Cursor producing plausible-but-wrong changes with no easy way to annotate and push back, without making a full PR. crit makes the review stage fun again!

Works on both plans as well as code itself. It’s been very rewarding hearing from folks who use it, everyone has been very kind! My most successful side project already :)

GitHub: https://github.com/tomasz-tomczyk/crit

This is cool. Feels like Codex already offers this in their desktop app.

excellent work. I have been using a vscode extension for this for an year.

Thanks! What extension were you using?

https://crit.md - a CLI tool for reviewing AI coding agent output like a GitHub PR.

I got frustrated with Claude Code and Cursor producing plausible-but-wrong changes with no easy way to annotate and push back, without making a full PR. crit makes the review stage fun again!

Works on both plans as well as code itself. It’s been very rewarding hearing from folks who use it, everyone has been very kind! My most successful side project already :)

GitHub: https://github.com/tomasz-tomczyk/crit

That's a really smart idea -- I'd love to try it!

https://crit.md - a CLI tool for reviewing AI coding agent output like a GitHub PR.

I got frustrated with Claude Code and Cursor producing plausible-but-wrong changes with no easy way to annotate and push back, without making a full PR. crit makes the review stage fun again!

Works on both plans as well as code itself. It’s been very rewarding hearing from folks who use it, everyone has been very kind! My most successful side project already :)

GitHub: https://github.com/tomasz-tomczyk/crit

I've been doing a lot of parallel work and it can be draining. It feels exciting to have 6 agents spinning on things, but unless you have very well scoped plans, you need to still check in frequently.

If you have the tokens for it, having a team of agents checking and improving on the work does help a lot and reduces the slop.

I'd love for all these tools to standardise on the structure of plugins / skills / commands / hooks etc., so I can swap between them to compare without feeling handicapped!

I like it but it's one conversation at a time, no ability to manually compact the chat... I guess it's an early version still.

I don't see this said anywhere - maybe I missed it. Why is it only one conversation at a time?

Couldn't you have multiple sessions using different plugins or whatever?

Well, it's one conversation per bot. I set it up, connected the channel. DM'd it (only way to converse with it - wish I could have a Discord channel per project, different CWDs etc...) and asked what happens when I start 2 claude sessions connected to the channel and it said it'll just work with one.

Suppose you could have multiple bots, but it looks like it only supports one bot token anyway.

This is an API designed to build connectors, there's absolutely nothing preventing you from building one that connects to Discord and listens to a different channel for each instance.

I think they gave two sample implementations to demonstrate it.

I'm guessing their expecting the community to run with it

Just when I increased my subscription with CC for more Opus 4.6 usage :)

I'm using obra superpowers plugin in CC and the plans it produces are very code-heavy, which is great for reviewing - I catch issues early. It's quite verbose however and if your codebase moves quickly, the code might have bad/stale examples.

Those very detailed specs then let agents run for a long time without supervision so nice for multi tasking :)

Yes, reviewing things make things slower. Not reviewing them produces horrible results. There's a balance to be found and it depends on the team/org.

I hope we shift engineers closer to users than ever before. Get them to understand user's needs and the actual product more - they'll write better plans and prompts. Review the plans.

Code review becomes less of a thing when the team's on the same page, so regularly align on what the goals are.

Accept post-merge code reviews. Things slip, normalise coming back and saying "actually, we should have done this differently". It's not a bad thing, you're learning!

Not sure this works very well. I got 10/21 with 3 quick wins:

- Start recording major architecture and workflow decisions in ADRs.

I'm not sure all decisions need to be in ADRs. I think AGENTS.md can summarise a lot of this and as long as you keep it up to date, it sounds more efficient than keeping every record? Some is fair though to show how you make decisions

- Add at least one linter and formatter with explicit repo-level commands.

I have it with go, not detected

- Group repo docs under `docs/` or add an index that links the important pages.

What happened to comments in code? :)

Thanks for running it and the feedback!

For the ADR vs AGENTS: CLIs usually load the AGENTS.md with a tag saying: "this context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant to your task." That's claude code for instance. So ADR is rather something agents would not question.

Go linting: That's weird, ill take a look

Docs vs comments: great point but i think they serve two purposes. one is global (specs, design docs, etc.) and one is local (how a method works, or reason for a specific workaround)