after-changes

name	after-changes
description	Post-change checklist to run after any set of code edits. Runs three steps in sequence: (1) code review via /simplify, (2) README consistency check and update, (3) git commit. Trigger on phrases like "review and commit", "after-changes", "wrap up changes", "commit my changes", or when the user says to remember to do this after every change.

After-Changes Checklist

Run these three steps in sequence after every set of code changes.

Step 1 — Code Review

Run the /simplify skill. Wait for it to complete and apply all fixes before moving on.

Step 2 — README Check

1. Run git diff HEAD (or git diff HEAD~1 if already staged/committed) to get the full list of changed files and what changed.
2. Read README.md.
3. For each changed file, check: does the README make a claim about this file, its API, its behaviour, or its config that is now stale?
4. Common staleness patterns:
   • New env vars / config keys not in the config table
   • API endpoints added, removed, or renamed
   • New UI tabs, features, or workflows not described
   • Architecture claims that no longer match the code
   • "Cannot do X" statements that are now wrong
5. If anything is stale or missing, update README.md in-place. Keep changes minimal — add what's missing, fix what's wrong, remove nothing that's still true.
6. If README is already accurate, say so and skip.

Step 3 — Commit

1. Run git status and git diff HEAD to review everything that will be committed.

2. Stage all relevant changed files (be explicit — avoid git add -A).

3. Write a commit message following this format:

   <type>(<scope>): <short summary under 72 chars>
   
   - bullet for each logical change
   - explain WHY for non-obvious changes
   
   Co-Authored-By: Claude Sonnet 4.6 <[e-mail]>
   

   Types: feat, fix, refactor, docs, chore, test

4. Confirm the commit hash and summary.

Notes

• If Step 1 (simplify) finds and fixes issues, re-check README in Step 2 for any new staleness those fixes introduced.
• If there is nothing to commit (working tree clean), say so and stop.
• Do not push — only commit locally unless the user explicitly asks to push.