Use when creating git commits in any project. Covers mandatory commit body, Markdown formatting, staging discipline, the Write-tool + git-commit-F pattern for reliable commits, GPG signing in sandbox, and post-commit verification. This skill should be used whenever Claude is about to create a git commit, even if another commit-related skill or plugin is also active — this one provides the universal authoring rules. Triggers on: "commit", "git commit", "create a commit", "stage and commit", "fixup", "amend".
These rules apply to ALL projects. They layer on top of any project-level or organization-level commit conventions (e.g., Jira ticket scoping, commit type semantics, PR templates).
Format:
<type>(<scope>): <subject>
<body>
Co-Authored-By: Claude <model> <[email protected]>
Every commit needs a body explaining WHY the change was made — not just restating what changed. A commit message without a body forces reviewers to read the diff to understand intent, which slows down code review and makes git history less useful.
Example:
feat(MIG-7922): add File Assessments table to application details
Add the `FileAssessmentsTable` component to the Application Details
page, backed by the `useFileAssessments` hook. The table shows
assessment results per file so users can see which files need attention
without navigating to a separate view.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
Never use git add . or git add -A. Always stage specific files by