opencode-config/skills/change-code-review/SKILL.md

---
name: change-code-review
description: Review only the last set of changes (staged + unstaged, else the most recent commit) for bugs, security issues, and guidance-doc (AGENTS.md/CLAUDE.md) compliance. Use when asked to review my changes, review the diff, or check staged/uncommitted work before committing.
---

# Change Code Review

Provide a rigorous, structured code review of the **last set of changes** only. Follow these steps precisely:

## 1. Resolve the change set
Use git via Bash to determine the last set of changes, in this priority order:
1. Staged and unstaged working-tree changes combined: `git status --porcelain`, `git diff`, `git diff --staged`.
2. If the working tree is clean, the most recent commit: `git show --stat HEAD` and `git diff HEAD~1 HEAD` (handle a root commit where `HEAD~1` does not exist).
3. If neither exists, report "No changes to review" and stop.

Record the diff, the changed files, and the changed line ranges. This is the only scope for the rest of the review.

## 2. Eligibility check
Skip (report "No review needed") if any apply: there is no change set (see step 1), or the change set is a no-op/trivial and obviously correct, or this exact change set was already reviewed in this session. Otherwise proceed.

## 3. Load guidance docs
Find and read the project's **guidance docs** — root `AGENTS.md`, `CLAUDE.md`, and any in the directories the changed files live in. Use Glob/Grep to locate them (e.g. `**/{AGENTS,CLAUDE}.md`). Treat these as explicit review criteria; cite them when an issue maps to a rule.

## 4. Summarize the change
Get a concise summary of what the change set does and why (use the diff, plus the commit subject when the commit fallback from step 1 was used), so reviewers share context before diving into the diff.

## 5. Parallel independent reviews
Launch parallel subagents via the `task` tool (they use whatever model this session was called with; the `explore` agent is read-only). Each subagent reviews one angle **of the changed lines only** and returns a list of issues plus the reason each was flagged (e.g. guidance-doc adherence, bug, historical git context, security):
- **Guidance-doc compliance:** audit the changed lines against AGENTS.md / CLAUDE.md. Guidance docs address the model as it writes code, so not all instructions apply during review.
- **Bug scan:** read the changed lines with only minimal surrounding context; do a shallow scan for obvious bugs and security issues introduced by the change. Focus on large bugs; avoid small issues and nitpicks; ignore likely false positives.
- **Historical context:** read the git blame and history of the changed lines (`git blame`, `git log`) to identify bugs in light of how that code evolved.
- **Comments/intent:** read code comments around the changed lines and ensure the change complies with the guidance in those comments.

## 6. Confidence scoring
For each issue found in step 5, launch a parallel subagent that takes the issue description and the guidance docs (from step 3) and scores its confidence on a scale from 0–100, using this rubric verbatim:
- **0** — Not confident at all. False positive that doesn't stand up to light scrutiny, or a pre-existing issue.
- **25** — Somewhat confident. Might be real but unverified; stylistic issues not explicitly called out in the guidance docs don't count here.
- **50** — Moderately confident. Verified as real but possibly a nitpick or rare in practice. Relative to the rest of the change set, it's not very important.
- **75** — Highly confident. Double-checked and very likely to matter in practice; directly impacts functionality, or is explicitly mentioned in the relevant guidance doc.
- **100** — Absolutely certain. Double-checked and confirmed real; happens frequently; evidence directly confirms it.

For issues flagged due to a guidance-doc rule, double-check that the guidance doc actually calls out that issue specifically.

## 7. Filter
Drop any issue scored <80. If none remain at >=80, report no blocking issues.

## 8. Re-check eligibility
Confirm the change set still warrants the review before writing up.

## 9. Report
Present findings concisely in chat. Cite each bug by file path and line range (changed lines only), with 1–2 lines of surrounding context; when an issue maps to a guidance-doc rule, quote the rule. Format:

```
### Code review

Found N issues:

1. <brief description of issue> (guidance doc path says "<...>")

path/to/file.ext:12-18

2. <brief description of issue> (bug due to <file and code snippet>)

path/to/file.ext:40-45
```

Or, if nothing met the threshold:

```
### Code review

No blocking issues found. Checked for bugs and AGENTS.md/CLAUDE.md compliance.
```

Examples of false positives (for steps 5 and 6):

- Pre-existing issues
- Something that looks like a bug but is not actually a bug
- Pedantic nitpicks that a senior engineer wouldn't call out
- Issues that a linter, typechecker, or compiler would catch (e.g. missing or incorrect imports, type errors, broken tests, formatting issues, pedantic style issues like newlines). No need to run these build steps yourself — it is safe to assume they will be run separately as part of CI.
- General code quality issues (e.g. lack of test coverage, general security issues, poor documentation), unless explicitly required in a guidance doc
- Issues that are called out in a guidance doc, but explicitly silenced in the code (e.g. due to a lint ignore comment)
- Changes in functionality that are likely intentional or are directly related to the broader change
- Real issues, but on lines outside the change set (unchanged lines)

Notes:

- Do not check build signal or attempt to build or typecheck the app. These will run separately, and are not relevant to your code review.
- Do not fetch anything from the web (no web search or fetch). Use git commands via Bash for history and context instead.
- You must cite each bug by file path and line range.
- Keep output brief.