reviewkitlisted

# 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