pull-request-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# Review the change, not the style guide

A useful review finds the defect that would have shipped and explains it so the
author can fix it in one pass.

## Establish scope

1. Get the diff (`git_diff` for the working tree, `git_diff_range` against the
   base branch). Read the whole diff before commenting on any part.
2. Read the linked issue, PR description, or commit messages. Write one line
   stating what the change claims to do.
3. Open the files around the diff; a change is only correct in context.

## Check in this order

1. **Does it do what it says**: every requirement from the issue is met, no
   silent scope changes, no leftover debug code or TODOs.
2. **Correctness**: edge cases, error paths, concurrency, ordering, off-by-one,
   null and empty inputs, resource cleanup, timeouts.
3. **Security**: injection, path traversal, secrets, permission checks,
   unsafe deserialization, shell execution with user input.
4. **Compatibility**: public API, config, storage formats, migrations, feature
   flags, older callers.
5. **Tests**: a test fails before and passes after for each fix; new behavior
   has coverage including edge cases; flaky patterns (sleeps, real network).
6. **Maintainability**: naming, duplication, module boundaries, comments only
   where logic is non-obvious.

Run the tests and lint yourself when the environment allows; a review with
evidence beats one with opinions.

## Deliver

- Verdict first: approve, approve with nits, or request changes, in one line.
- Findings ordered by severity. Each: file:line, what is wrong, why it matters,
  a concrete fix. Mark confidence when you could not verify.
- Separate blocking from optional. Keep nits short or drop them.
- Say what you did not review.

From autohandai/code-cli, Apache-2.0.

More from autohandai/code-cli