commit

name	commit
description	Format and create git commits. ALWAYS use this skill when making git commits. TRIGGER: Any time you are about to run `git commit`.
allowed-tools	["Bash","Read","Grep","Glob"]

Commit: Format and Create Git Commits

Commit Message Format

<type>[(scope)]: <concise summary in imperative mood>

<optional body explaining context and rationale>

Types: feat, fix, refactor, test, docs, perf, chore Scope (optional): package or module name, e.g., feat(core):, fix(ingest):

What to Include

Capture context aggressively from the conversation. The commit message is the permanent record of why this change exists. Review the full chat history and distill anything a future reader would need to understand the decision — don't let institutional knowledge vanish when the conversation ends.

Focus on WHY, not WHAT:

• Rationale and design decisions — why this approach over alternatives
• Alternatives considered and why they were rejected
• Non-obvious implications of the change
• Links to every resource that informed the work: docs, Stack Overflow answers, GitHub issues, blog posts, API references, tutorials. These are especially easy to lose — if a URL appeared in the conversation, it probably belongs in the commit.
• Key findings from debugging or research — what was learned, not just the final fix
• Gotchas and surprises discovered along the way (non-obvious library behavior, subtle bugs, etc.)
• Constraints or requirements that drove the decision (user goals, deadlines, upstream dependencies)
• Decisions explicitly deferred, with reasoning (so future readers know it was intentional)

Err on the side of too much context rather than too little. A commit body that says "switched from library X to library Y" is far less useful than one that explains X doesn't support streaming (link to issue), Y's API is similar enough that migration was straightforward, and only the auth setup differs.

Avoid:

• Describing what changed (the diff shows this)
• Obvious implementation details
• Information better suited for inline code comments

Commit Command Format

Never use HEREDOCs for commit messages. The $(cat <<'EOF' ... EOF) pattern involves nested shell operators (command substitution + here-document) which the Bash tool flags for manual approval every time. Instead, pass a single multi-line string to -m. The Bash tool's command parameter is a JSON string, so newlines are fine — this is a simple command with no nested operators:

git commit -m "type(scope): summary

Optional body with context.

Co-Authored-By: Claude Opus 4.6 <[e-mail]>"

Attribution

If using AI/agentic tools to generate commits, attribute appropriately:

Co-Authored-By: <Tool Name> <email-or-identifier>