Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From xtras
Use when committing code — writing commit messages, staging, or reviewing commits before push.
npx claudepluginhub thatxliner/claude-plugins --plugin xtrasHow this skill is triggered — by the user, by Claude, or both
Slash command
/xtras:x-commitThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Commit msg = for person reading `git log` 6 months later. Tell **why** change exists — diff shows *what*/*how*.
Creates p5.js generative art with seeded randomness, noise fields, and interactive parameter exploration. Use for algorithmic art, flow fields, or particle systems.
Share bugs, ideas, or general feedback.
Commit msg = for person reading git log 6 months later. Tell why change exists — diff shows what/how.
git status + git diff first. Never git add -A / git add ..
git add files from current task. Leave other unstaged/untracked changes alone./commit): stage all, unless incomplete features (half-written code, TODO stubs, broken imports). Warn user, commit only complete stuff. If user insists, commit what they ask.git commit --no-verify.docs/superpowers/ etc.) — those are ephemeral agent guidance, not project docs.Try to split into as many atomic commits as possible. If there is a list of features (e.g. "Implemented X, Y, and Z types"), split each one into a separate commit.
IT IS ABSOLUTELY IMPERATIVE THAT IF YOU EVER SAY "+" OR "and" OR ANYTHING SIMILAR IN A COMMIT MESSAGE (or your description of it would include that), SPLIT IT INTO MULTIPLE COMMITS.
Split by motivation, not subsystem. Different whys = different commits. Same why = same commit. "Fix X, Fixed Y" = 2 commits. "Build X, needs A+B+C" = 1 commit if the code won't work without A+B+C; 3 commits if A, B, and C can exist independently. "Crash recovery + its error reporting" = 2 commits. "Fix typo + add feature" = 2 commits.
Don't merge by code proximity. Same function/file ≠ same commit if different problems. Interleaved changes → git add -p or commit one feature first, then other. Trap: "shared infrastructure / same loop" ≠ same why.
Single commit needs VERY good reason. ALWAYS prefer splitting the code hunks into as many commits as possible.
:gitmoji: type(scope): imperative description
GitHub shortcode + Conventional Commits. Prefer specific gitmojis (:passport_control: not :sparkles:, :rocket: not :wrench:).
| Gitmoji | Use |
|---|---|
| :sparkles: | New feature |
| :bug: | Bug fix |
| :ambulance: | Critical hotfix |
| :recycle: | Refactor |
| :fire: | Remove code/files |
| :zap: | Perf |
| :memo: | Docs |
| :white_check_mark: | Tests |
| :arrow_up: / :arrow_down: | Dep upgrade/downgrade |
| :lock: | Security |
| :boom: | Breaking change |
| :pencil2: | Typo |
| :lipstick: | UI/style |
| :art: | Code style |
| :wrench: | Config |
| :construction_worker: | CI/build |
| :truck: | Move/rename |
Niche gitmojis: https://gitmoji.dev/
Independent but related. Gitmoji can be more specific than type: :ambulance: fix(auth): — general fix type, specific :ambulance: emoji.
: — :bug: fix(auth): handle null user:pencil2: fix(docs): correct "recieve" → "receive")# BAD: says what
:bug: fix(auth): add null check before accessing user.email
# GOOD: says why
:bug: fix(auth): prevent crash when user session expires
# BAD: wrong gitmoji + type
:sparkles: feat(deps): upgrade React to 19.0
# GOOD
:arrow_up: build(deps): upgrade React to 19.0
Only when subject alone doesn't explain why. Use for: bugs, non-obvious decisions, breaking changes, wide blast radius. Skip for obvious changes.
:bug: fix(orders): prevent duplicate submissions on double-click
Users creating duplicate orders clicking Submit before first request
completed. Debouncing insufficient — slow network extended vulnerable window.
Disable button on first click, re-enable on error. Chose this over
request deduplication for immediate visual feedback.
Never heredocs (cat <<'EOF'). Bash quoting + heredocs = syntax errors + token waste. Use: git commit -m "subject\n\nbody".