agentkitcoagentkitco/agentkit-dev-skills/skills/review-my-diff/SKILL.md

review-my-diff

Skill0 starsChanged 14 days agoMITView on GitHub

Self-review uncommitted or branch changes before a PR, with findings ranked by severity and backed by file and line evidence. Use when asked to review my changes or check my diff.

In this repository12 other files it gives its agents.
- agents-md-auditSkill
- brag-doc-from-gitSkill
- dependency-upgradeSkill
- explain-codebaseSkill
- pr-descriptionSkill
- prove-it-ranSkill
- repro-first-debuggingSkill
- safe-refactorSkill
- security-quick-reviewSkill
- session-handoffSkill
- write-agents-mdSkill
- write-subagentSkill

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
Get the change: Run git status --short, then git diff (unstaged) and git diff --staged.
line 16
Distinctive:
Every finding names a file and line, and says what breaks.
line 52
Distinctive:
If you find nothing in a category, say "nothing found" rather than inventing a nit.
line 53
Distinctive:
Never approve. End with a recommendation (ready, ready after fixes, or needs rework) and the reason.
line 55

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Review my diff before a human does

Goal: catch the problems a reviewer would catch, in order of how much they matter. You are reviewing, not rewriting: do not edit files unless asked.

Steps

Get the change. Run git status --short, then git diff (unstaged) and git diff --staged. For a branch, find the base (git merge-base HEAD origin/main or the default branch) and run git diff <base>...HEAD. If the diff is huge, review it by directory and say so.
State the intent in one sentence, inferred from commit messages, branch name or the user's request. If you cannot tell, ask once.
Read the whole diff, then the code around risky hunks (callers, tests, config). A diff hides what it did not touch.
Check in this order:
1. Correctness: wrong conditions, off-by-one, null/empty cases, error paths, concurrency, resource cleanup.
2. Safety: input validation, auth checks, secrets, injection, destructive operations, migrations that lock or lose data.
3. Tests: does a test fail without this change? Are the new branches covered? Any test that asserts nothing?
4. Compatibility: public API, config, database, file formats, callers outside this repo.
5. Maintainability: dead code, copy-paste, unclear names, debug leftovers (console.log, print, TODO, commented code).
6. Scope: unrelated edits that should be a separate PR.
Run what exists: the project's tests, lint and type check, if they are quick. Report the exact commands and results. If you did not run something, say so.

Output format

Intent: <one sentence>
Checks run: <commands and results, or "none">

BLOCKER (fix before merging)
- <file>:<line> <problem>. Why it matters: <consequence>. Suggested fix: <short>

SHOULD FIX
- <file>:<line> ...

NITS (optional)
- ...

Looks good
- <specific things that are right, so the author knows what to keep>

Questions for the author
- <things you could not determine from the code>

Rules

Every finding names a file and line, and says what breaks. No "consider improving readability" without a specific line.
If you find nothing in a category, say "nothing found" rather than inventing a nit.
Distinguish "I verified this" from "this looks suspicious". Do not claim a bug you did not trace.
Never approve. End with a recommendation (ready, ready after fixes, or needs rework) and the reason.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free