Review your own diff
self-reviewreviewquality
Checks the diff before pushing: unhappy paths, silent failures, duplication.
Was er tut
- Triggers before a pull request or when you ask whether the change is ready.
- Reads the whole diff against the base branch and looks at it as the person who'll be paged when it breaks.
- Works in order: does it do what was asked; what happens on an empty value or a failed call; does anything fail open when a key is missing; is there now a second place that must stay in sync.
- Looks specifically for breakage nobody sees on screen: social previews, scheduled jobs, emails.
Wozu er gut ist
The most expensive bug is the one that looks like a working feature. This forces a walk down the unhappy paths that normal diff-reading skips, because the eye follows the intent rather than the edges.
Wohin damit
- 1Legen Sie im Projekt den Ordner .claude/skills/self-review an
- 2Legen Sie dort eine SKILL.md mit dem Text unten ab
- 3Fertig. Claude Code lädt den Skill selbst, sobald eine Aufgabe zur Beschreibung passt
Damit der Skill in allen Projekten statt nur in einem funktioniert, legen Sie ihn in ~/.claude/skills statt in den Projektordner.
SKILL.md-Datei
--- name: self-review description: Review your own changes before pushing. Use when the user asks to review the diff, asks whether the change is ready, or before opening a pull request. --- # Reviewing your own diff Read the full diff against the base branch before saying anything: `git diff origin/main...HEAD`. Review it as if someone else wrote it and you are the one who will be paged when it breaks. ## What to look for, in order **1. Does it do what was asked?** Compare against the original request, not against your own plan. Scope that quietly grew is as much a defect as scope that was dropped. **2. What happens on the unhappy path?** For every new branch: what if the value is null, the list is empty, the network call fails, the user is not signed in? Name the specific line and the specific input that breaks it. **3. Does anything fail open?** A missing key, an empty allowlist, an unset environment variable — does the code then let everyone through, or no one? Letting everyone through silently is the worse default and the harder bug to notice. **4. Is anything now unreachable or duplicated?** New code that shadows old code, a second place that must be kept in sync with the first, an export nobody imports any more. **5. Would this be visible if it broke?** Changes that only fail somewhere the author never looks — a social preview, a scheduled job, an email — deserve a test or a log line. ## How to report Lead with the most serious finding. For each one give the file, the line, and a concrete failing input — not "this could be unsafe" but "if `code` is empty this returns every row". If nothing survives that bar, say the diff looks fine. Do not invent findings to look thorough.