agentsclimarketplace

Conventional commit pr

Skill sujanbhuiyan/Skills/skills/conventional-commit-pr

A curated, installable marketplace of production-grade Agent Skills for Claude — research, SEO/GEO, finance, deliverables & engineering, indexed by topic, lifecycle & domain.

Install
npx -y skills add sujanbhuiyan/Skills --skill conventional-commit-pr

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 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

Turns a code diff into Conventional Commit messages and a high-quality pull-request description. Use when committing staged or unstaged changes, when writing a commit message that follows the Conventional Commits spec, or when assembling a PR description with summary, changes, and a test-plan checklist.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.5 KB, as published. Nobody here has run it

Conventional Commit & PR

What this does

Reads a diff and produces (a) one or more Conventional Commit messages — correct type(scope): subject line, a body explaining the why, and a BREAKING CHANGE: footer when relevant — and (b) a clean pull-request description (Summary, Changes, Test plan checklist, linked issues). Well-formed Conventional Commits also drive automated semver bumps and changelogs.

When to use it

  • Committing staged/unstaged changes and you want a spec-correct message.
  • Splitting a mixed working tree into logically separate commits.
  • Writing a PR description from the branch's full set of commits/changes.

How to use it

  1. Inspect the changes: git status, git diff (unstaged) and git diff --staged (staged). For a PR, also review the whole branch: git log <base>..HEAD and git diff <base>...HEAD.
  2. Determine the type from the dominant change (see the spec summary in references/cheatsheet.md): feat · fix · docs · refactor · test · chore · perf · build · ci. If the diff mixes concerns, recommend splitting into separate commits — one type per commit.
  3. Pick an optional scope (the area touched, e.g. auth, api, orders).
  4. Write the subject: imperative mood, lowercase start, no trailing period, ≤ 72 chars (≤ 50 preferred). "add", "fix", "remove" — not "added"/"fixes".
  5. Write the body (wrap ~72 cols): explain why the change is needed and any context a reviewer needs — not a restatement of the diff.
  6. Add footers when relevant: BREAKING CHANGE: <description> for any incompatible change (or ! after the type/scope), and issue refs like Refs: #123 / Closes #123.
  7. Assemble the PR description from the template in the cheatsheet: Summary (why), Changes (bullets), Test plan (checklist), and linked issues.
  8. Present the final commit message(s) and PR body as copy-paste blocks. Only run git commit / open the PR if the user explicitly asks.

Inputs

  • The working-tree diff (staged and/or unstaged) or the branch's diff vs. base.
  • Optional: linked issue IDs, the target base branch, and any repo-specific commit/scope conventions (check the recent git log style).

Output

  • One or more Conventional Commit messages (subject + body + footers).
  • A PR description: Summary, Changes, Test plan checklist, linked issues.

Notes & constraints

  • Match the repo's existing style — read recent git log for scope naming and conventions before drafting.
  • One logical change per commit; recommend splitting when the diff spans unrelated concerns.
  • A breaking change requires either ! (e.g. feat(api)!: …) or a BREAKING CHANGE: footer — prefer including the footer so tooling catches it.
  • This skill drafts messages; it does not commit, push, amend, or force-push unless the user explicitly requests it. Never bypass hooks or signing.
  • Use forward-slash paths.

Gives 0 of the 12 instructions most plan spec skills give

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

  • ask one question at a timein 46 of 1100, across 38 files
  • Break plans into vertical slicesin 28 of 1100, across 10 files
  • Publish issues in dependency orderin 27 of 1100, across 9 files
  • Iterate until user approves the breakdownin 24 of 1100, across 6 files
  • Explore the repository to understand the codebase statein 24 of 1100, across 7 files
  • Use domain glossary vocabularyin 23 of 1100, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1100, across 5 files
  • Write failing tests before implementation codein 23 of 1100, across 18 files
  • Prefer AFK slices over HITLin 22 of 1100, across 7 files
  • ask clarifying questions until requirements are concretein 21 of 1100, across 13 files
  • Respect existing architecture decision recordsin 20 of 1100, across 5 files
  • write a specification before writing any codein 20 of 1100, across 12 files

Said here and by no other author read

  • review unstaged and staged changes
  • determine type from dominant change
  • pick optional scope
  • write subject in imperative mood
  • explain why in commit body
  • add footers for breaking changes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

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.