← ClaudeAtlas

gitmoji-commitlisted

Plan and draft git commits in the Gitmoji + Conventional Commits style — a leading emoji (✨, 🐛, ♻️ …) plus a conventional type, like "✨ feat: add avatar upload". Splits a working tree into a clean sequence of reviewable, logically-grouped commits, isolates lockfiles into their own final commit, and hands back signed, copy-paste git commands. Use whenever the user wants help committing changes, writing/improving a commit message, asks "how should I commit this", wants to break work into reviewable commits, or mentions gitmoji/git-emoji/emoji commits. The user runs git themselves — this skill produces messages and commands, it does not commit.
colachg/skills · ★ 0 · Code & Development · score 62
Install: claude install-skill colachg/skills
# Gitmoji Commit Help the user turn a pile of working changes into a clean sequence of commits, each in the **Gitmoji + Conventional Commits** style: a leading emoji that signals the *kind* of change, then a conventional type and an imperative subject. ``` ✨ feat: add avatar upload to the profile page ``` The user runs `git` themselves. Your job is to **plan the commits and produce the messages + commands** they can copy — not to run `git add` or `git commit`. ## The workflow 1. **Survey everything that changed.** Don't assume the right things are staged. Inspect the whole working tree (all read-only and safe): - `git status` — staged, unstaged, and untracked files at a glance - `git diff --staged` and `git diff` — the actual content of staged and unstaged edits - For untracked files, look at the new files themselves Read the substance, not just filenames: a change under `tests/` that backs a new feature is part of that feature's story; a `.md` file might be user docs or just a code comment. 2. **Group changes into reviewable commits.** This is the heart of it. Aim for **atomic commits** — each commit is one coherent concern that a reviewer can understand on its own. The point is reviewability: someone reading the history should be able to follow your reasoning commit by commit. - Keep *related* edits together (a feature + its tests + its doc note can be one commit if they tell one story). - Split *unrelated* edits apart (a bug fix and an unrelated con