git-diff-summariser

---
name: "git-diff-summariser"
description: "Summarise a git diff into a short change description, risk assessment, and suggested commit message. Use when the user asks to review changes, draft a commit message from a diff, or wants a high-level overview of what was edited."
license: "MIT"
---

# Git diff summariser

## When to use
The user pastes or points at a git diff and wants a summary rather than reading it line-by-line.

Examples:
- "Summarise this diff"
- "Draft a commit message for these changes"
- "What changed in this PR?"

## Steps

1. **Get the diff content.** Either the user pasted it, or they point at a file — use `fs_read` on a `.diff` / `.patch` file. If you have sandbox access and a git repo cloned in `/workspace`, the shell script below can regenerate the diff.

2. **Run the bundled counter** (optional quick-stats pass). This gives accurate line/file counts without the model having to count manually:
   ```
   run_skill_script({
     name: "git-diff-summariser",
     path: "scripts/count.sh",
     stdin: <the diff content>
   })
   ```
   Returns stdout like:
   ```
   files_changed: 7
   insertions: 142
   deletions: 38
   binary_files: 1
   ```

3. **Read the diff yourself.** The stats tell you the shape; now actually read the diff to understand what changed. Group changes by file or by logical theme (not by commit).

4. **Produce four sections.**
   - **Summary** — one paragraph: what was the goal of these changes?
   - **Changes** — bullet list grouped by theme, each with the file(s) affected
   - **Risk** — anything that could break? (migrations, auth, public API, env vars, cron schedules)
   - **Commit message** — a single-line subject + optional body, conventional-commits style (`feat(module): …`, `fix(module): …`, `refactor(module): …`)

5. **Offer next steps.** `offer_choices`:
   - "Write this as a PR description"
   - "Generate a test plan for these changes"
   - "Flag any missing tests"

## Style

- For the commit subject line, imperative mood, ≤72 chars.
- Risk section should be honest — if there's no risk, say "Low — isolated changes to X".
- Don't restate what the stats already show; the reader has them.
- Reference files by relative path — `src/foo.ts` not `a/src/foo.ts`.

## What not to do

- Don't invent file names. If you're unsure, re-read the diff headers.
- Don't mark changes as "probably safe" without having read them.
- Don't produce a 20-bullet change list for a 50-line diff. Be proportional.