Evidence-based code review skills for Codex and Claude Code
Catalog skill by akkie76: Evidence-based code review skills for Codex and Claude Code Install into Cursor, Claude, Codex, or VS Code from this page or review the source for code-review-skills.
Ads
git clone https://github.com/akkie76/code-review-skills
Install guides: Cursor skills, Claude Code skills, Codex skills, or VS Code Copilot skills.
Review the requested code change with the shared workflow below. Use the repository's available file, search, diff, and test tools to gather evidence. Do not modify the reviewed code unless the user separately asks for changes.
Use this workflow to review a proposed code change. The objective is to find actionable defects introduced by the change, not to produce the largest possible list of comments.
Before judging the change:
references/technologies/, read the relevant files before reviewing.Repository-specific requirements take precedence over this general workflow. If two authoritative instructions conflict, report the conflict rather than inventing a resolution.
Technology guidance is optional and supplied by the user or project. When it is absent, use repository configuration, dependency versions, surrounding code, and verified tool behavior as evidence. Do not assume a framework guarantee or report a technology-specific defect when the applicable behavior cannot be established.
Inspect the complete diff before reviewing individual lines. Summarize for yourself:
Partition the diff into distinct, independently reviewable concerns before starting the detailed review. A concern is one coherent behavior, invariant, refactor, fix, migration, or operational change; it may span files, and one file may contain several concerns. Record which files or hunks belong to each concern and any interactions between concerns.
Review every identified concern through the tracing, risk, validation, and false-positive steps below at sufficient depth, then examine relevant interactions between concerns. Depth spent on one feature or refactor does not substitute for reviewing an unrelated fix bundled into the same diff. Use the concern map as a coverage check before producing the final response. Do not manufacture findings for a large but coherent single-concern change.
If the reviewing environment supports delegation and the concern map indicates that one pass is unlikely to give every concern sufficient attention, consider using multi-agent decomposition. It is optional; a final integration pass is required whenever it is used.
Separate observed facts from assumptions. Use commit or pull-request context as supporting evidence, but let the code and authoritative project documentation determine actual behavior.
Do not limit investigation to modified lines. For each identified concern and relevant interaction:
Do not claim that caller or consumer coverage is exhaustive when dynamic dispatch, generated code, external consumers, or repository boundaries prevent complete enumeration. State the limitation and review the discoverable usages that carry the greatest impact.
Do not manufacture a cross-caller or cross-variant finding merely because a shared path exists. Report one only when the change demonstrably alters an existing usage or variant guarantee.
Use the smallest amount of surrounding code needed to establish whether a candidate issue is real. Avoid unrelated repository-wide critique.
Apply the checks in the review criteria according to the change's risk profile. Spend more effort on paths that can lose data, expose sensitive information, authorize actions, charge money, corrupt persistent state, or prevent recovery.
Not every category applies to every change. Explain a category only when it produces an actionable finding or when the user explicitly requests a checklist report.
Before reporting an issue, answer all of the following:
Validate every factual claim in the proposed finding, not only the minimum claim needed to prove the defect. If the finding cites an existing precedent, nearby pattern, unchanged behavior, caller count, contract, or specific location as supporting evidence, read that exact source and confirm that it states or implements what the finding attributes to it. Do not infer a cited fact from a similar pattern elsewhere. Remove unverified supporting detail even when the core conclusion remains correct.
Investigate uncertain claims. When a candidate's trigger can be checked safely, within the requested scope, and with available trusted tools, prefer the smallest focused test or static check that exercises the suspected risky input or path rather than only a convenient safe variant. Do not execute untrusted project code or commands without authorization, and avoid checks whose side effects cannot be isolated. If a claim remains speculative, omit it or explicitly present it as a question outside the formal findings. Do not use a lower action level as a substitute for validation; assign the level after the problem is established, based on its demonstrated impact.
Do not report:
Follow the output contract for action level, viewpoint, comment content, language selection, and final response structure. Apply the communication checks in the communication guidelines before returning the review.