agentsclimarketplace
Sign in

Conventional commit pr

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

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.From its SKILL.md

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 file declares

Copied from the file, not written here

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, 775 tokens by cl100k_base, 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.

What ships with it: 1 file

3.7 KB alongside SKILL.md

references/

Keep looking

Skills are one crate of 325,949. 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.