reviewkit
reviewkit
Review code an AI agent just wrote, for the failure modes that are specific to AI-generated changes. A generic "find bugs" pass misses the three things agents get wrong most: writing code that is correct in a vacuum but wrong for this repo, padding a change with plausible-looking cruft nobody asked for, and quietly leaving part of the job undone. reviewkit runs those checks first, then a correctness pass, and reports findings ranked by severity. It does not fix anything. Fixing is the human's call, or a handoff to an implement-style skill.
This is a reviewer, not an editor. It reads the change and judges it; it never edits source. Its one optional artifact is a review report the user can save to feed a PR description.
Review with fresh eyes
The reviewer should not be the agent that wrote the change. reviewkit usually fires in the same session that just produced the code, which means the reviewer arrives carrying every rationalization it made while writing: the shortcut it already justified, the edge case it already decided didn't matter. That is the single biggest way this review turns into a rubber stamp.
So when you have a subagent tool, delegate the passes to a fresh subagent: hand it the diff, the stated intent, and the passes below, and let it report back with no memory of the implementation session. Review its findings, then present them. When no subagent tool is available, run the passes yourself but say plainly in the report that this was a self-review, because the user needs to know how much weight the verdict carries. Never quietly self-review a change you just wrote.
The one thing that survives either mode: judge the code that is actually on disk, not the code you remember intending to write.
When this fires
After an agent (or the user) finishes a chunk of work and wants it judged before it ships: "review this", "review my changes", "review the diff", "check this code", "self-review before I commit", "/reviewkit", or a bare "does this look right" after a coding session. It reviews uncommitted work or a branch's diff, not a line-by-line audit of the whole codebase.
It is distinct from a generic correctness linter: reviewkit leads with convention-fit and agent-slop passes that a bug-focused review skips. If the user only wants correctness bugs, say so and run just that pass; don't pad the report with the other two.