agentsclimarketplace

Conventional git commit

Skill HenryZhang-ZHY/agents/skills/conventional-git-commit

Install
npx -y skills add HenryZhang-ZHY/agents --skill conventional-git-commit

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

Create git commits and draft, review, rewrite, or choose commit messages that follow Conventional Commits 1.0.0-beta.4. Use this skill whenever the user asks to commit changes, says "commit this", wants a commit message, asks whether a change is feat/fix/chore/refactor/etc., mentions breaking changes, changelogs, semantic versioning, release notes, squash commits, or wants staged changes summarized for git history. For exact specification wording and edge cases, consult references/conventional-commits-1.0.0-beta.4.md.

SKILL.md

4.0 KB, 800 tokens by cl100k_base, as published. Nobody here has run it

Conventional Git Commit

Use this skill to make commit history explicit and machine-readable. The message should communicate the intent of the change, support changelog generation, and map naturally to semantic versioning when feat, fix, or BREAKING CHANGE is used.

For exact wording, examples, and edge cases from the source specification, read references/conventional-commits-1.0.0-beta.4.md. Use the reference when the user asks about compliance details, SemVer implications, breaking changes, or ambiguous commit types.

Commit message format

<type>[optional scope][optional !]: <description>

[optional body]

[optional footer]

Type selection

Choose the most specific type that describes the primary intent of the commit:

ChangeType
Adds a new capabilityfeat
Patches a bugfix
Improves an existing implementation without adding a feature or fixing a bugimprovement
Improves performanceperf
Refactors code without changing behaviorrefactor
Adds or changes tests onlytest
Changes documentation onlydocs
Changes formatting onlystyle
Changes dependencies, packaging, or build configurationbuild
Changes CI workflowsci
Performs maintenance that does not fit another typechore

Process

  1. Inspect the changes being committed, preferably from the staged diff when available.
  2. Identify the primary intent. If the commit mixes unrelated intents, suggest splitting it before writing the final message.
  3. Choose the commit type from the table.
  4. Add a scope only when it gives useful context, such as parser, auth, docs, or deps.
  5. Write a concise imperative description after : . The description should complete the phrase "This commit will..."
  6. Add a body only when the reason, tradeoff, migration note, or behavioral detail would help future readers.
  7. Add footers for issue links, breaking changes, pull requests, reviewers, or required trailers.
  8. Verify the final message matches the format before running git commit.

Breaking changes

Use BREAKING CHANGE: <description> when the commit introduces a breaking API or user-facing compatibility change.

  • Put BREAKING CHANGE: at the beginning of the body or at the beginning of a footer line.
  • Keep BREAKING CHANGE uppercase exactly.
  • You may add ! before the colon in the subject, such as chore!: drop Node 6, but the message still needs a BREAKING CHANGE: body or footer.

Footer and trailer handling

  • Keep each footer as one piece of metadata per line.
  • Preserve required trailers such as Co-authored-by.
  • If there is both a body and footers, separate them with one blank line.
  • If there is no body, place footers one blank line after the subject.

Examples

Feature with breaking change:

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

Breaking maintenance change with !:

chore!: drop Node 6 from testing matrix

BREAKING CHANGE: dropping Node 6 which hits end of life in April

Documentation-only change:

docs: correct spelling of CHANGELOG

Scoped feature:

feat(lang): add polish language

Fix with issue footer:

fix: correct minor typos in code

See the issue for details on the typos fixed.

Closes #12

Gives 1 of the 12 instructions most pr commit review skills give in 800 tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-06

  • use conventional commits formatin 123 of 888, across 110 files
  • keep subject line under 72 charactersin 60 of 888, across 46 files
  • delete branches after mergein 50 of 888, across 37 files
  • use imperative mood in subject linein 50 of 888, across 41 files
  • use imperative mood in commit messagesin 45 of 888
  • generate a conventional commit messagein 42 of 888
  • make atomic commitsin 37 of 888, across 25 files
  • run tests before committingin 36 of 888, across 24 files
  • run project test suite to verify clean baselinein 35 of 888, across 7 files
  • run detected project setup commandsin 34 of 888, across 6 files
  • wrap commit body at 72 charactersin 32 of 888, across 25 files
  • split unrelated changes into separate commitshere, and in 32 of 888, across 27 files

Said here and by no other author read

  • inspect the changes being committed
  • add a body only when it helps future readers
  • verify the final message matches the format

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

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.