mcpField
G
git-commit-convention

git-commit-convention

github.com/edramDevelopment052 installsUpdated 6w ago
Repository

About git-commit-convention

git-commit-convention guides agents through planning and validating commits in the Conventional Commits 1.0.0 format. It covers commit boundaries, message structure, version implications, and AI attribution.

Key features

  1. 01Plans commit boundaries from the change set
  2. 02Validates messages against staged changes
  3. 03Explains format, types, and version implications
  4. 04Covers breaking changes and footer syntax
  5. 05Requires AI co-author attribution when applicable

Use cases

  1. 01Splitting a large change set into coherent commits
  2. 02Checking a message against its staged diff
  3. 03Recording breaking changes and issue references
  4. 04Attributing agent contributions in commits

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/edram/skills --skill git-commit-convention

After installing, type/git-commit-conventionin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
core-format.md
core-planning.md
core-types.md
features-ai-attribution.md
features-breaking.md
features-footers.md

Details

From the project README

Conventional Commits 1.0.0 defines a human-readable and machine-parseable commit message format. Before writing a message, plan the commit boundary from the complete change set; a multi-round conversation may produce several coherent commits rather than one catch-all commit. In the spec, feat implies MINOR, fix implies PATCH, and breaking changes imply MAJOR; other type-to-version mappings are project conventions.

  • Only type and description are required; everything else is optional
  • Scope narrows the affected area: feat(auth):, fix(api):
  • Breaking changes use ! suffix or BREAKING CHANGE: footer (or both)
  • Footer tokens follow Git trailer convention
  • Default to English, but match the project's existing convention — check git log and follow whatever language recent commits use
  • Decide commit boundaries from purpose and dependency, not from the number of conversation rounds
  • Validate each message against the staged diff: every staged change must belong to the stated purpose, and every material claim must be supported by the diff
  • When asked to commit, state the proposed commit plan before creating any commit; then validate each staged commit separately
<type>[optional scope][!]: <description>

[optional body]

[optional footer(s)]

Core

TopicDescriptionReference
Commit PlanningInspect, group, split, and validate changes before committingcore-planning
FormatFull grammar, header/body/footer rules, length limitscore-format
TypesCommon types, project-level SemVer impact, and when to use eachcore-types

Features

TopicDescriptionReference
Breaking Changes! syntax and BREAKING CHANGE footer — when and howfeatures-breaking
FootersToken format rules, issue references, common tokensfeatures-footers
AI-Generated ChangesRequired Co-Authored-By attribution whenever an agent contributes to the commitfeatures-ai-attribution

Comments

Markdown supported