agentleFS
Sign inStart free
LucasCooperBeyLucasCooperBey/claude-skills/skills/review-changes/SKILL.md

review-changes

Skill1 starsChanged 5 months agoMITView on GitHub

Analyze uncommitted changes before committing. Quick pre-commit review of what you're about to ship.

  • Reads credentials

We split this skill into the rules it gives an agent

7 rules. 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 30 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before git commit — quick sanity check

    line 11
  2. Very specific:

    Before /ship — preview what's going out

    line 12
  3. Distinctive:

    When you've been coding for a while and lost track of changes

    line 13
  4. Distinctive:

    Before creating a PR

    line 14
  5. Very specific:

    When the user invokes /review-changes:

    line 18
  6. Distinctive:

    If no changes found: "Working directory is clean.

    line 35
  7. Distinctive:

    If everything looks good (or after fixes):

    line 89

“Common” is measured: kept by at least 6 in 10 of the 30 edited versions of this file we could read. “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 Changes (/review-changes)

Analyze all uncommitted changes in the working directory before committing.

When to Use

  • Before git commit — quick sanity check
  • Before /ship — preview what's going out
  • When you've been coding for a while and lost track of changes
  • Before creating a PR

Instructions

When the user invokes /review-changes:

Step 1: Gather Changes

# Staged changes
git diff --cached --stat
git diff --cached

# Unstaged changes
git diff --stat
git diff

# Untracked files
git status --short | grep "^??"

If no changes found: "Working directory is clean. Nothing to review."

Step 2: Summarize

Produce a structured summary:

## Changes Overview

**Staged (ready to commit):**
- `src/auth.ts` — +42 -12 (added token refresh logic)
- `test/auth.test.ts` — +28 -0 (new tests for refresh)

**Unstaged:**
- `src/utils.ts` — +3 -1 (minor fix, probably should stage)

**Untracked:**
- `src/new-feature.ts` — New file (should this be committed?)

**Total: N files changed, +X -Y lines**

Step 3: Quick Analysis

For each changed file, check:

  1. Accidental changes — Debug logs, console.log, commented code left in
  2. Missing files — New imports that reference untracked files
  3. Secrets check — Any .env values, API keys, tokens in the diff
  4. Convention compliance — Quick check against CLAUDE.md rules
  5. Test coverage — Did source files change without corresponding test changes?
  6. Proof of thoughtfulness — Were decisions intentional or just model defaults? Flag any architectural choice that looks like it was accepted without review (e.g., new abstractions, dependency additions, structural patterns that don't match existing conventions).
  7. Cut check — Flag any addition without a linked issue, user request, or explicit decision. If it can't be explained in one sentence to a beta user, it doesn't ship in V1.

Step 4: Report Issues

## Issues Found

### Must Fix
- `src/auth.ts:15` — `console.log("debug")` left in
- `src/config.ts:8` — Hardcoded API key (NEVER commit this)

### Should Fix
- `src/utils.ts` — Changed but no test updates
- `src/new-feature.ts` — Not staged, but imported by staged files

### Looks Good
- Token refresh logic is clean
- Tests cover the happy path and error cases

Step 5: Suggest Commit

If everything looks good (or after fixes):

## Suggested Commit

**Message:** `add token refresh with automatic retry`

**Stage these:**
```bash
git add src/auth.ts test/auth.test.ts src/utils.ts

Don't stage:

  • src/scratch.ts — Looks like scratch work

Proceed with commit? Or fix issues first?


## Arguments

| Arg | Effect |
|-----|--------|
| `--staged-only` | Only review staged changes |
| `--quick` | Skip analysis, just show summary |
| `--fix` | Auto-fix issues found (remove debug logs, etc.) |

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