# Prompt: review AI-written changes before you commit Use this after an AI agent has changed your code and before you commit or deploy. It works best in a fresh chat or a second agent session, so the reviewer does not just defend the changes it made. Paste the diff, or let an agent with repository access run the git commands itself. --- Act as a strict but fair senior code reviewer. An AI coding agent made the changes below. Review them before I commit. Do not change any code yet; just review. ## What the change was supposed to do [ONE OR TWO SENTENCES: THE TASK YOU GAVE THE AGENT] ## The changes [PASTE THE OUTPUT OF `git diff` OR `git diff --staged` HERE, OR SAY: "Run `git diff` yourself and read the changed files in full."] ## Review checklist Go through each point and report only real findings, with the file and line: 1. Scope: Did the change do what was asked, and only that? List unrelated edits, renamed things, deleted code or reformatted files that I did not ask for. 2. Correctness: Logic errors, off-by-one errors, unhandled empty or null values, wrong conditions, missing `await`, race conditions, broken error handling. 3. Invented code: Calls to functions, library methods, config options or environment variables that do not exist in this project or in the installed library versions. Check the code and the dependency versions instead of trusting your memory. 4. Security: Hard-coded secrets, keys exposed to the browser, missing input validation, injection risks (SQL, shell, HTML), missing permission checks, unsafe file paths. 5. Data: Schema or migration changes, anything that could delete or corrupt existing user data, and changes to data formats that other code depends on. 6. Dependencies: New or upgraded packages. Is each one necessary? Is there an existing dependency or built-in API that does the same job? 7. Tests: Are there tests for the new behavior? Do existing tests still make sense, or were they weakened, skipped or deleted to make them pass? 8. Leftovers: Debug logs, commented-out code, TODOs, placeholder text, duplicated functions, dead code. 9. Readability: Names, function length and structure that will confuse the next person (or the next AI session). ## Output format - Verdict: one of "Safe to commit", "Commit after small fixes", or "Do not commit". - Findings: a table with Severity (blocker / should fix / nit), File and line, Problem, Suggested fix. - Questions: anything you could not verify from the code you saw. - Commands: the exact commands I should run to check the change (tests, type check, lint, build, a manual test). Keep the review focused. Do not list style preferences as blockers.