tasteful-commits: Claude Code skill for well-crafted git commits (52-57 char lines, templates, co-author credits)

tasteful-commits.md

tasteful-commits: Claude Code skill for well-crafted git commits (52-57 char lines, templates, co-author credits)

---

description: Generate tasteful, well-crafted git commits with proper formatting and collaboration credits.

Git commit messages are an opportunity to communicate semantic context, the changes themselves being in the diff. But sometimes, just a list what changed can also be appropriate. As a sophisticated software agent, your judgment matters and is worth developing. Here, you are creating a tasteful git commit. Follow these steps:

Step 0: Pre-staging

• Ensure tests and linting pass. If there is a CI pipeline defined, run everything in the pipeline locally. Fix anything related to the current change, raise pre-existing findings for discussion.

Step 1: Gather context

Run these in parallel:

• git diff --staged to see what's being committed
• git log --oneline -10 to see recent commit style
• git diff --staged --stat for a file-level summary

If nothing is staged, tell the user and stop.

Step 2: Craft the commit message

Summary line rules

• Target 52–57 characters (hard max: 72)
• Use imperative mood ("Add", "Fix", "Refactor", not "Added", "Fixes")
• No trailing period
• Be specific: say what changed, not that something changed

Body rules

• Wrap lines at 52–57 characters
• Separate from summary with one blank line
• Explain why, not what (the diff shows what)

Choose a body template

Pick the template that best fits the change:

Bug fix:

<summary>

The previous behavior was <X> because <root cause>.
This corrects it by <approach>.

New feature / addition:

<summary>

This introduces <what> to support <why/goal>.
<Optional: key design decisions or trade-offs.>

When multiple components or trade-offs are involved, a bulleted list may be clearer than prose. Use your judgement.

Refactor / cleanup:

<summary>

<Why this restructuring was needed.>
No functional change intended.

When the refactor touches multiple areas, prefer a bulleted list over dense prose:

<summary>

<Why this restructuring was needed.>

- <what moved or changed>
- <what moved or changed>

No functional change intended.

Cleanup:

When several small, unrelated changes are pending, use the following pattern:

<summary>

- <first_change>, what and why.
- <second_change>, what and why.
- ...

Chore / config / deps:

<summary>

<Brief rationale — why now, what prompted it.>

Docs:

<summary>

<What was missing, wrong, or out of date.>

If none of these fit well, write a concise free-form body that explains the motivation.

Collaboration credit

End the commit message with a blank line followed by:

Co-Authored-By: <model> (<tool>) <email address>

Where:

• <model> is the model you are running as (e.g., "Opus 4.6", "Sonnet 4.6")
• <tool> is the tool context if known (e.g., "Claude Code", "API", "Copilot", etc.)

Examples:

• Co-Authored-By: Claude Opus 4.6 (Claude Code) <noreply@anthropic.com>
• Co-Authored-By: GitHub Copilot GPT-5.3-Codex (VS Code) <noreply@github.com>

Step 3: Present and confirm

Show the user the full draft commit message in a code block. Ask if they'd like to adjust anything before committing.

Step 4: Commit

Once confirmed, create the commit using a HEREDOC:

git commit -m "$(cat <<'EOF'
<full message here>
EOF
)"

Then run git log -1 to confirm success and show the result.

Source

Canonical version: https://gist.github.com/doolin/32d0430388405765e508c150831c4ac8