Skip to content

Instantly share code, notes, and snippets.

@jonalexander
Created March 10, 2026 20:31
Show Gist options
  • Select an option

  • Save jonalexander/bb8087aa63dc0d151af95b6a5aad97e2 to your computer and use it in GitHub Desktop.

Select an option

Save jonalexander/bb8087aa63dc0d151af95b6a5aad97e2 to your computer and use it in GitHub Desktop.
SKILL:review-commit
name description argument-hint
review-commit
Walk through each changed file one at a time, showing a summary and diff, then commit approved files individually with auto-generated messages. Use when the user wants to review and commit changes file-by-file.
optional
specific files to review

Review & Commit Workflow

You are performing an interactive file-by-file review and commit workflow. The goal is small, focused commits that are easy to understand.

Process

1. Gather Changed Files

Run git status and git diff --stat to identify all changed files (staged + unstaged + untracked). If $ARGUMENTS is provided, filter to only those files.

Build an ordered list of files to review. Group related files logically (e.g., source file before its test) but each file will be committed individually.

2. Walk Through Each File

For each changed file, present:

a) Summary — A brief plain-language description of what changed in this file and why.

b) Diff — Show the full git diff output for the file (or git diff --cached if staged, or note if untracked/new).

c) Proposed Commit Message — Auto-generate a conventional commit message following the repository's existing commit style. The message should:

  • Use the conventional commit format: type(scope): description
  • Be concise (under 72 characters for the subject line)
  • Focus on the "why" not the "what"

d) Ask for Approval — Use AskUserQuestion to ask the user:

  • Approve — Commit this file with the proposed message
  • Edit message — Approve the changes but provide a different commit message
  • Request changes — The user wants modifications to the file before committing
  • Skip — Leave the file uncommitted and move to the next

3. Handle Each Response

  • Approve: Stage ONLY that file (git add <file>) and commit with the proposed message.
  • Edit message: Stage the file and commit with the user's provided message.
  • Request changes: Ask the user what they want changed. Make the modifications. Then re-show the updated diff and summary for the same file (restart step 2 for this file).
  • Skip: Move to the next file without staging or committing.

4. Finish

After all files have been reviewed, show a summary:

  • Number of commits created
  • List of commit hashes and messages
  • Any files that were skipped (still uncommitted)

Rules

  • One file per commit. Never combine multiple files in a single commit unless the user explicitly asks to group them.
  • Never auto-commit without approval. Always wait for the user's response before committing.
  • Never use git add . or git add -A. Always stage specific files by name.
  • Never amend previous commits unless the user explicitly requests it.
  • Never push to remote. Only create local commits.
  • Preserve the repo's commit message style. Check git log --oneline -10 at the start to match the existing convention.
  • Show real diffs. Do not summarize or truncate the diff — show the full output so the user can make an informed decision.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment