ivyxivyx
← All skills
IVYXSTUDIO · SKILL
C

Code review

code-review · v1.1.0

ivyx

How to review a change for correctness, tests and risk without editing anything.

Who is asked

Risk low: it loads without asking anyone. Each tool it then calls still meets your policy.

Tools it may call

While this skill is active, a call to any other tool is refused. These still meet every policy rule; the list narrows, it approves nothing.

source-control.diffsource-control.graphsource-control.commitFilesfs.readFilefs.listsearch.query

What it tells the agent

The published SKILL.md, as written.

---
name: code-review
description: How to review a change for correctness, tests and risk without editing anything.
allowed-tools: source-control.diff source-control.graph source-control.commitFiles fs.readFile fs.list search.query
metadata:
  risk: low
---

Reviewing a change

You review; you do not fix. While this skill is active you can only read, so never offer to apply an edit yourself: describe it and let the person decide.

1. Find the change

  • Uncommitted work: source-control.diff with source: staged, then with source: worktree if nothing is staged.
  • A commit: source-control.diff with source: commit and its hash; source-control.commitFiles lists what it touched.
  • Read the whole of any file whose diff you cannot judge from the hunk alone (fs.readFile), and find the callers of a changed function with search.query before you say a change is safe.

2. Review it against the checklist

Read checklist.md (call this skill with { "file": "checklist.md" }) and go through it.

Go through every item. Skip one only when it cannot apply to this change, and say which you skipped.

3. Report

Start with a one-line verdict: looks good, needs changes or needs discussion. Then list findings, most serious first. Each finding is: where (path:line), what is wrong, why it matters, and the smallest change that fixes it. A finding you are unsure of says so and says what would settle it.

Do not pad the review: no praise list, no restating the diff, no style remarks a formatter would make. If there is nothing wrong, say so in one line and stop.

Files it reads

Loading the skill lists these to the agent. It reads one when the instructions send it there.

checklist.md
# Review checklist

1. **Does it do what it says?** Read the commit message or the request, then
   the code. A change that does something else as well is a finding.
2. **Edge cases.** Empty input, one item, very large input, missing or null
   fields, errors from every call it makes. Which of these does the code
   handle, and which does it silently get wrong?
3. **Callers.** Every caller of a changed signature or behaviour still works.
4. **Tests.** A behaviour change comes with a test that fails without it. A
   test that cannot fail is a finding.
5. **Failure.** When something goes wrong, does a person learn what and why,
   or does it fail quietly?
6. **Secrets and data.** No credential, token or personal data in the diff,
   in a log line or in an error message.
7. **Reversibility.** A migration, a deletion or a format change: can it be
   undone, and is that said?
8. **Size.** A change that would be easier to review as two is worth saying
   so, once.