// This skill should be used when the user says "commit my changes", "commit this", "create a commit", "git commit", "save my work", or mentions committing code.
Use for any image creation or editing request — logo, sticker, product mockup, nano banana, t2i, i2i, multi-reference compositing via generate.py. Not for HTML/CSS mockups, diagrams, or coded UI.
This skill should be used when the user says "get PR comments", "show PR feedback", "what comments on my PR", "PR review comments", "show me the review", "what did reviewers say", or asks about feedback on a pull request. Not for creating PRs or responding to comments.
Recall, search, continue, or analyze past conversations. Triggers on recall phrases ("what did we discuss", "continue where we left off", "we decided"), retrospective phrases ("do a retro", "post-mortem", "what went well", "lessons learned", "find antipatterns"), and implicit signals (past-tense references, possessives without context, assumptive questions like "do you remember").
Extracts first and/or last frames of every shot from a video using adaptive scene detection. Use this skill when the user says "extract frames", "get shot frames", "pull frames", "shot breakdown", "scene detect", "first frame of each shot", "last frame of each shot", "extract shots from video", or wants to extract key frames at shot cut points from a video file.
This skill should be used when the user asks to "convert this video", "change format to mp4", "trim from X to Y", "cut the first X seconds", "speed up this video", "slow motion", "timelapse", "resize video", "scale down", "rotate video", "flip video", "remux", or any general FFmpeg video manipulation not covered by compress-video, make-gif, share-social, extract-audio, or extract-frames.
This skill should be used when the user says "update CLAUDE.md", "refresh CLAUDE.md", "sync CLAUDE.md with the codebase", "reorganize CLAUDE.md", "optimize project instructions", or when CLAUDE.md is stale, verbose, or out of sync.
| name | commit |
| description | This skill should be used when the user says "commit my changes", "commit this", "create a commit", "git commit", "save my work", or mentions committing code. |
| argument-hint | [push] |
| allowed-tools | ["Bash(git:*)","Bash(python3:*)","AskUserQuestion"] |
Analyze uncommitted changes and create well-organized commits using conventional commit format.
Current repo state (injected at invocation — no tool calls needed):
git status --porcelaingit diff --statAbort before staging if any apply:
git add -A would stage conflict markers as content. Check $(git rev-parse --git-dir) for MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD, rebase-merge/, or rebase-apply/. If any present, report the in-progress operation and stop.git symbolic-ref -q HEAD is empty. Commit would land on an unreferenced commit and be lost on branch switch. Report and stop.Run git add -A to stage all changes.
Exclude generated or ephemeral files that should never be version-controlled: scratch.*, temp.*, debug.*, playground.*, *.log, dist/, build/, target/, node_modules/, __pycache__/.
If such files detected:
git reset HEAD <file>Proceed when all intended files are staged and ephemeral files are excluded.
For each changed file, write a one-line PURPOSE description (not file location).
Group by PURPOSE, not directory:
Each commit should represent one logical change because atomic commits enable git bisect and git revert without side-effects.
Signs of separate concerns:
fix: and test: commits so the fix can be reverted without losing the testsIf multiple concerns: use git reset HEAD then git add <specific-files> for each group. Commit foundational changes first.
Handle renames (R status): When splitting, add BOTH old and new paths. Git detects renames by similarity scoring across the old/new pair — staging only the new path causes git to log a delete + add, losing rename history.
Proceed when every changed file is assigned to exactly one commit group.
Run the validation script after staging:
python3 ${CLAUDE_PLUGIN_ROOT}/skills/commit/scripts/validate.py . --output json
Interpret the result:
output field, report the error to the user, and stopoutput field names the reason.Check recent commit style:
git log --no-merges --oneline -10
Use conventional commit format:
<type>(<scope>): <description>
Types: feat, fix, docs, refactor, test, chore, perf
git log and break downstream tooling that greps commit metadataIf git commit fails due to a pre-commit hook: the commit did NOT land. Check git status — the hook may have auto-fixed files (e.g. auto-version.py syncing plugin.json) and left them modified. Re-stage (git add -A) and retry the same git commit command with the same message. Do NOT use --amend (amends the PREVIOUS commit, not the failed one). Do NOT use --no-verify (skips the hook entirely, defeating its guard).
Proceed when the commit message is drafted and matches the repo's existing style.
If user mentions "push" or arguments contain "push", run git push. If push fails, report the error and stop — do not retry or force-push.
One line per commit (hash + message). If temporary files were excluded, list them as bullets below.