If target files are missing, report the error — there is nothing to review

If a review focus is specified, prioritize that area but still evaluate all categories

If acceptance criteria are provided, check whether the code satisfies them

Use read_file to load each target file

If a file does not exist or cannot be read, flag it immediately as a finding

Note the language, framework, and overall structure of each file

Use glob to search for build and configuration files in the relevant packages:

Read relevant config files to understand the project structure, dependencies, and any linting or formatting tools configured

Use glob and grep to find source files in the target packages

Use read_file to examine 2–3 representative source files (other than the target files) to learn:

Broaden the search to sibling packages or the project root

If still nothing is found, note this in the review — convention conformance will be assessed against general best practices for the language only

Off-by-one errors in loops, slices, or indexing

Incorrect boolean logic (wrong operator, inverted condition, missing case)

Unreachable code or dead branches that suggest a logic mistake

Race conditions or incorrect ordering of operations

Integer overflow, underflow, or truncation

Null/None/nil dereferences or missing null checks where the type system does not prevent them

Unhandled error cases (swallowed errors, empty catch blocks, bare unwrap() in Rust, unchecked exceptions)

Error messages that leak internal details or provide no useful information

Missing validation of inputs, return values, or external data

Resource leaks (unclosed files, connections, or handles)

Inconsistent error handling strategy within the same module

Does the code do what its name, comments, and API contract suggest?

Are there edge cases that would produce incorrect results (empty input, boundary values, large input, concurrent access)?

Are type conversions safe, or could they lose precision or fail silently?

SQL injection (string concatenation in queries instead of parameterized queries)

Command injection (unsanitized input passed to shell commands)

Path traversal (unsanitized file paths from user input)

Cross-site scripting (XSS) if the code generates HTML or handles web content

Template injection or format-string vulnerabilities

Hardcoded secrets, API keys, tokens, or passwords

Secrets logged to stdout, stderr, or log files

Secrets passed as command-line arguments (visible in process listings)

Sensitive data in error messages or stack traces

Missing input validation or sanitization

Trusting user-supplied data for authorization decisions

Deserialization of untrusted data without validation

Buffer overflows or unbounded allocations from external input

Use of weak or deprecated cryptographic algorithms

Custom cryptography implementations instead of well-audited libraries

Missing authentication or authorization checks

Insecure default configurations

Are names descriptive and consistent with the codebase conventions discovered in Step 3?

Do function names describe what they do? Do variable names describe what they hold?

Are abbreviations avoided unless they are well-established in the codebase?

Do boolean variables and functions read as predicates?

Are functions or methods excessively long or doing too many things?

Are there deeply nested conditionals or loops that could be flattened?

Are there complex boolean expressions that should be extracted into named variables or helper functions?

Are there functions with too many parameters?

Is there repeated code that could be extracted into a shared function or method?

Are there copy-pasted blocks with minor variations that could be parameterized?

Is there duplication across the target files that suggests a missing abstraction?

Is the code understandable without extensive context?

Is the control flow clear and easy to follow?

Are magic numbers or cryptic constants explained with named constants or comments?

Are comments accurate and helpful, or are they stale, misleading, or restating the obvious?

Does the code follow the naming, formatting, import, and structural conventions discovered in Step 3?

Does error handling follow the codebase's established pattern?

Does the code use the codebase's preferred idioms?

Are responsibilities clearly separated?

Does each function, method, or class have a single, well-defined purpose?

Could the code be tested, reused, or replaced independently?

Is the code tightly coupled to external systems, global state, or implementation details of other modules?

Are dependencies explicit (via parameters or constructors) or hidden (via global access or side effects)?

Would changing one part of the code require changes in many other places?

Can the code be unit-tested without elaborate setup?

Are dependencies injectable or mockable?

Are side effects isolated from business logic?

Is there logic that is difficult to test because it is buried inside a large function or tightly coupled to I/O?

Are public interfaces clear, minimal, and hard to misuse?

Are parameters and return types appropriate? Would callers need to do unnecessary work?

Are optional or configuration parameters handled cleanly (builder pattern, options struct, default values)?

Are error types informative and actionable for callers?

For each criterion, assess whether the code satisfies it

Flag criteria that appear unsatisfied or only partially satisfied

Include a coverage matrix in the report

Correctness — bugs, logic errors, unhandled error paths, edge-case failures

Security — injection, credential exposure, unsafe input handling, cryptographic issues

Quality and style — naming, complexity, duplication, readability, convention violations

Maintainability — modularity, coupling, testability, API design issues

Indicate severity as High, Medium, or Low

Describe the issue precisely, referencing the specific file, function, and line range

Explain why it matters

High: Bugs that would produce incorrect results, security vulnerabilities exploitable by an attacker, crashes or data loss, completely missing error handling for critical paths

Medium: Logic that works but is fragile or likely to break under edge cases, security issues that require specific conditions to exploit, significant convention violations, high complexity that materially hinders understanding, poor API design that makes misuse easy

Low: Style inconsistencies, minor naming improvements, small duplication, opportunities to simplify, documentation gaps, minor readability improvements

Partial code or code snippets: Review what is provided. Note any limitations caused by missing context (e.g., cannot assess error handling without seeing the caller, cannot assess security without seeing how input arrives). Do not refuse to review — provide the best assessment possible with available information.

Multi-file reviews: Review each file against the same package's conventions. Produce a single unified report covering all files. Note cross-file issues such as duplicated patterns, inconsistent styles between files, or coupling between the reviewed files.

Code without tests: Do not penalize the code for lacking tests in the correctness or quality findings — that is a testability observation under maintainability. Focus on the code itself. Note in the maintainability section whether the code's structure would make it easy or hard to test.

Generated code: If the code appears to be generated (e.g., by a code generator, ORM, or protocol buffer compiler), note this and limit the review to correctness and security. Style, naming, and structural critiques are usually not actionable for generated code since the generator, not the code, should be changed.

Performance-sensitive code: If code has comments indicating performance sensitivity (benchmarks, hot paths, optimization notes) or if the review focus includes performance, be conservative about recommending changes that could affect performance (e.g., adding function call overhead, changing data structures). Note performance concerns separately when the current code sacrifices readability for speed.

Very large files: Focus on the highest-impact findings. Summarize patterns (e.g., "the same missing-null-check pattern appears in 12 functions") rather than listing every instance individually. Prioritize findings that affect correctness and security over style observations.

Code in unfamiliar languages: If the language is not well-known, focus on universal concerns (logic errors, security, naming clarity, structural complexity) and note that language-specific idiom assessment may be limited.

Review focus specified: When a specific focus is provided, give that area extra depth but still scan all categories. A security-focused review should still flag an obvious bug; a quality-focused review should still flag an obvious vulnerability.

Acceptance criteria provided but code is incomplete: Flag unmet criteria as findings but distinguish between "the code does not implement this" and "the code implements this incorrectly."

No convention baseline discoverable: If no surrounding code exists to establish conventions, evaluate against general best practices for the language and note the limitation. Do not invent conventions that may not apply.