# Review your changes before you commit

Have Claude Code review uncommitted changes against their intent and flag risks by severity, asking before any check that could change files.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
Review my uncommitted changes and flag anything that looks risky before I commit.

The change is meant to: {{intent}}
{{#focus}}
Look especially closely at: {{focus}}
{{/focus}}
Review: {{scope}}.

This is a review only. Do not edit, stage, commit, stash or discard anything.

1. Use git to see what changed. Where the diff alone does not show enough, open the surrounding code, and check the callers of anything whose behavior changed.
2. Flag:
- bugs, and behavior that does not match the intent above
- missing or weakened tests, and edge cases the change does not handle
- secrets, credentials, debug output, commented-out code or stray files
- risky operations: migrations, deletions, changes to config, permissions or public APIs
- changes unrelated to the intent that belong in a separate commit
3. Before running any test, lint or build command, read what it does. Run only checks that leave files and external state unchanged, and report their results. For a check that may write files, update snapshots, change build output or reach external systems, show me the command and ask before running it.

Report each finding with file and line, why it matters and a suggested fix, sorted into: must fix before commit, should fix, optional. Keep what you confirmed separate from what you suspect. If you cannot tell whether something is intended, ask. If nothing looks risky, say so plainly instead of padding the list.
```

## Fields

- `{{intent}}` (required): What the change is meant to do.
- `{{focus}}`: Look especially closely at. Optional. Parts you are least sure about.
- `{{scope}}`: Changes to review. Choose one:
  - all staged and unstaged changes, plus new files git does not track yet (default)
  - only the changes I have staged

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

## When to use this template

- You have finished a change in a git repository and want a second look before it becomes a commit, while fixes are still cheap and private.
- The change touches something sensitive, such as a migration, a permission check or a public API, and you want those parts called out on their own.
- You want the review measured against what the change was supposed to do, so unrelated edits and scope creep show up as findings.

## When not to use it

- You only want a quick correctness pass without describing the intent. Claude Code has a bundled `/code-review` skill that reviews the current diff in a fresh subagent.
- The changes are already pushed and open as a pull request. Review the pull request instead, so comments land where the rest of the team will see them.
- The project is not in a git repository. Without version control there is no uncommitted diff to review; point Claude at the files and use the general code review template.

## Why this structure

- The intent field gives the review something to measure against. Without it, Claude can only judge whether the code looks reasonable, not whether it does what you meant.
- The review-only rule is explicit because the working tree holds your unfinished work. Claude reports findings; you decide what to change and when to commit.
- The scope setting decides whether new untracked files are included. A new file is easy to forget in a review, and it is often where stray debug output or secrets end up.
- The flag list in step 2 names the kinds of problem that are hard to undo once committed or pushed, such as secrets and migrations, so they are on the list for every review.
- Step 3 has Claude read each check before running it. Checks that leave files and external state unchanged run directly and add evidence to the findings; checks that may write snapshots, build output or anything outside the project wait for your approval, which keeps the review read-only.
- Sorting findings by severity, and asking for a plain "nothing risky" when that is true, puts the findings that matter for this commit at the top instead of in a long list of minor preferences.

## Example input (fictional)

What the change is meant to do:

```
Add retry with exponential backoff to the payment client, up to three attempts. Nothing else should change.
```

Look especially closely at:

```
error handling when all retries fail
```

Changes to review:

```
all staged and unstaged changes, plus new files git does not track yet
```

## Follow-ups to send Claude

- Fix the must-fix findings only, then show me the new diff. Do not commit.
- Split the unrelated changes you found into a separate list of files and lines, so I can commit them on their own.
- Write a commit message for these changes that states what changed and why, in under 72 characters for the first line.

## Common mistakes

- Leaving the intent vague, such as "some fixes". The review then cannot tell an intended change from an accidental one.
- Asking Claude to review and fix in the same step. Read the findings first; some will be intended, and fixing them would undo your work.
- Treating every finding as a must-fix. A reviewer asked to find problems will usually find some, so decide which ones matter for this commit.

## Related templates

- [Code review prompt](https://awesomeclaudeprompts.com/prompts/code-review/): Ask Claude to review a diff for supported issues, ordered by severity, with a location, impact and suggested fix for each finding.
- [Write tests, run them, fix failures](https://awesomeclaudeprompts.com/prompts/write-and-run-tests/): Ask Claude Code to write tests for a file, run them and work through the failures in one go, without weakening a test just to make it pass.
- [Draft release notes from git history](https://awesomeclaudeprompts.com/prompts/release-notes-from-git/): Have Claude Code compare two git tags or branches and draft release notes grouped into breaking changes, features and improvements for your readers.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code best practices: Add an adversarial review step](https://code.claude.com/docs/en/best-practices#add-an-adversarial-review-step) (Anthropic documentation)
- [Claude Code docs: Desktop app, review your code](https://code.claude.com/docs/en/desktop#review-your-code) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.