agentsclimarketplace

Writing git commit messages

Skill msewell/agent-stuff/skills/writing-git-commit-messages

Like everyone else, I'm sharing my agent stuff.

Install
npx -y skills add msewell/agent-stuff --skill writing-git-commit-messages

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

3.7 KB, 893 tokens by cl100k_base, as published. Nobody here has run it

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):

    git commit -F- <<'EOF'
<type>(<scope>): <description>

<body wrapped at 72 chars>

<optional footer(s)>
EOF

Format

<type>(<scope>): <description>

[body — what & why, wrapped at 72 chars]

[footer(s)]

Breaking changes

Indicate with ! after the type/scope OR a BREAKING CHANGE: footer:

feat(api)!: change response format for /users

BREAKING CHANGE: The `email` field is now nested under `contact`.

Common mistakes

  • Vague subjects (fix stuff, update code, WIP) — always state what the commit does.
  • "and" in the subject — split into separate atomic commits.
  • Wrong type — don't use fix for refactors, feat for tests, or chore as a catch-all.
  • Missing "why" — the diff shows how; the body must explain why.
  • Secrets in messages — never include credentials; git history is permanent.

Examples

Simple feature:

feat(parser): add support for nested arrays

Bug fix with context:

fix(auth): prevent session fixation on login

The session ID was not regenerated after successful authentication,
allowing an attacker with a known session ID to hijack the session.

Fixes #1234

Breaking change:

refactor!: drop support for Node 14

BREAKING CHANGE: Node 14 reached EOL in April 2023. The minimum
supported version is now Node 18.

Reference material

What ships with it: 4 files

20.0 KB alongside SKILL.md

references/

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.