# 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.

- Skill: `sujanbhuiyan/conventional-commit-pr` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add sujanbhuiyan/conventional-commit-pr`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sujanbhuiyan/conventional-commit-pr/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: sujanbhuiyan (https://skillmd.com/u/sujanbhuiyan)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sujanbhuiyan/conventional-commit-pr

---


# 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`](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.