neo-code-review

Code Review

Follow this read-only workflow. Report only actionable findings supported by evidence.

Trigger On

• The user requests a code, PR, diff, commit, security, performance, test, or maintainability review.
• The user asks whether code or logic is duplicated across files, or whether hard-coded values should be centralized.
• An AI Agent finishes modifying code, tests, configuration, or scripts before handoff.

Workflow

1. Define the review scope

   • Use the files or snippets supplied by the user as the primary scope.
   • If the user provides no scope and the current directory is a Git repository, run:

     uv run skills/neo-code-review/scripts/git-diff-reviewer.py --working-tree
     

   • Use --staged for staged-only changes and --commit <range> for a commit range.
   • Read surrounding code, related tests, and existing contracts. If no reviewable input exists, report it and stop.
   • For a working-tree review, include the helper's tracked diff and each non-ignored untracked file as separate inputs.

2. Load the review rules

   • Read review-checklist.md before evaluating code.
   • Identify the actual language, framework, and affected behavior from the change. Do not infer unverified rules from filenames.

3. Run the cross-file consistency scan

   • Build the comparison set from the review targets and relevant repository source and configuration files. Use rg --files and the repository's ignore rules. Exclude dependency, vendor, cache, generated, minified, build, and coverage output unless a file is explicitly in scope.
   • Inventory changed or reviewed functions, classes, validation and authorization rules, state transitions, request or query construction, error handling, and distinctive literals such as URLs, routes, timeouts, retry counts, thresholds, regexes, feature flags, and error messages.
   • Search the comparison set for exact and near-exact matches, then read each match in context. Ignore name and formatting differences when the behavior matches. Treat renamed or slightly rearranged copies as duplicates when their business rules, inputs, side effects, and failure behavior are materially the same.
   • Report only meaningful duplication: copied implementation, duplicated business or validation logic, divergent security or state logic, or repeated non-trivial hard-coded configuration. Do not report a match based only on a common keyword, normal one-time literal, test fixture, snapshot, generated file, or vendor code.
   • For every cross-file finding, cite both file paths and line numbers. Explain the concrete maintenance, divergence, security, or behavior risk and recommend a specific shared helper, constant, configuration source, or other single source of truth.
   • If the user supplied only a snippet or specific files without repository context, state in ## Validation that cross-file verification was unavailable. Never invent repository matches or line evidence.