← ClaudeAtlas

writing-git-commit-messageslisted

Writes and reviews git commit messages following Conventional Commits and the seven fundamental rules. Produces well-formatted, atomic, automation-friendly commit messages. Use when writing a commit message, reviewing commit messages, committing code changes, or when the user mentions git commits, commit messages, or changelogs.
msewell/agent-stuff · ★ 0 · Code & Development · score 70
Install: claude install-skill msewell/agent-stuff
# Writing Git Commit Messages ## Workflow 1. **Detect project convention.** Check for `commitlint.config.*`, `.czrc`, `.commitlintrc.*`, or commit conventions in `CONTRIBUTING.md`. If found, follow that convention. Otherwise, default to Conventional Commits. 2. **Analyze the change.** Read the diff (or context) to understand the scope and purpose. Identify whether it's a single logical change or should be split into multiple commits. 3. **Choose the type.** Pick the most accurate type: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`. 4. **Choose the scope** (optional). Use a short noun for the affected area (e.g., `auth`, `api`, `parser`). Omit if the change is cross-cutting. 5. **Write the subject line.** Follow the format `type(scope): description`: - Imperative mood ("Add", not "Added") - ≤50 characters total - No trailing period - **Lowercase** description after the colon (Conventional Commits standard); if the project omits a type prefix, capitalize the first word instead 6. **Write the body** (for non-trivial changes). Explain *what* changed and *why* — not *how*. Wrap at 72 characters. 7. **Add footers** as needed: `Fixes #123`, `BREAKING CHANGE: ...`, `Co-authored-by: ...`. 8. **When executing `git commit` from the shell, use this method only** (to guarantee real newlines and avoid literal `\\n` in history): ```bash git commit -F- <<'EOF' <type>(<scope>): <description> <body