conventional-commit-prlisted

# 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