Git & Conventional Commits

Pathrule2 Rules • 1 Memory • 1 Skill

A workflow bundle that standardizes how AI agents and humans commit, branch, and open pull requests. It enforces the Conventional Commits v1.0.0 spec, short-lived branches off main, and small reviewable PRs so changelogs and version bumps can be generated automatically.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root
Commit messages follow Conventional Commits v1.0.0
Short-lived branches, squash merge, no rebase of pushed branches
git-conventional-commits-review
.github/
Commit automation stack: commitlint + lefthook + release-please

Rules

2
Commit messages follow Conventional Commits v1.0.0/roothighstrictEvery commit subject uses a typed prefix and stays under 52 characters.
1Format every commit as `<type>[optional scope][!]: <description>` per Conventional Commits v1.0.0 so release-please can derive versions and generate changelogs automatically.
2 
3- Allowed types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`.
4- Subject in imperative mood, lowercase after the colon, no trailing period, at most 52 characters; wrap body at 72.
5- `feat` maps to a MINOR semver bump and `fix` to a PATCH; signal breaking changes with `!` after the type or a `BREAKING CHANGE:` footer for a MAJOR bump.
6- Add a scope in parentheses when it clarifies the area, for example `fix(auth): refresh token before expiry`.
7- This is enforced by commitlint in a lefthook `commit-msg` hook and repeated on the PR title since squash merge turns the PR title into the landed commit.
Short-lived branches, squash merge, no rebase of pushed branches/roothighadvisoryBranch off main, squash merge PRs, never rebase commits already pushed to a shared branch.
1Keep integration cheap and history linear by coupling short-lived branches with squash merge.
2 
3- Cut branches from `main` and merge them back within a day or two; PRs stay under ~400 changed lines.
4- Squash merge every PR so it lands as a single Conventional Commit on `main`; the PR title becomes that commit and must pass commit linting.
5- Rebase your local branch onto `main` to stay current before opening a PR, but never rebase a branch others have already pulled.
6- One logical change per PR so reverts are a single `git revert` with no collateral damage.

Memories

1
Commit automation stack: commitlint + lefthook + release-please/.githubHow local hooks, CI title checks, and release-please wire together for zero-manual changelogs.
1Commit hygiene is enforced at three choke points: the local commit hook, the CI PR-title check, and the release pipeline.
2 
3- `@commitlint/cli` with `@commitlint/config-conventional` validates messages via a `lefthook` `commit-msg` hook, so a bad message is rejected before it is committed.
4- Because we squash merge, the PR title becomes the final commit subject. A GitHub Actions workflow lints the PR title against the same rules using `amannn/action-semantic-pull-request`.
5- `release-please` watches commits on `main`, computes the semver bump from the highest type (`feat` = MINOR, `fix` = PATCH, `!` or `BREAKING CHANGE` = MAJOR), opens a release PR with a generated `CHANGELOG.md`, and cuts the GitHub Release on merge.
6- Keep `lefthook.yml` and `commitlint.config.ts` at the repo root; keep GitHub Actions workflows under `/.github/workflows`.
7- A `feat!: description` commit, or any commit with a `BREAKING CHANGE:` footer, triggers a MAJOR bump and requires explicit team acknowledgment before merge.

Skills

1
git-conventional-commits-review/rootPre-commit and pre-PR checklist for clean commits and reviewable pull requests.
1---
2name: git-conventional-commits-review
3description: Checklist to run before committing and before opening a PR so commits follow Conventional Commits v1.0.0, branches stay short-lived, and PRs are small and reviewable. Use when writing a commit, opening a pull request, or auditing git history hygiene.
4---
5 
6# Git & Conventional Commits review
7 
8## Commit message
9 
10- [ ] Subject matches `<type>[scope][!]: <description>` using an allowed type (`feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`).
11- [ ] Subject is imperative mood, lowercase after the colon, no trailing period, and at most 52 characters.
12- [ ] Body (if present) explains the why, wraps at 72 characters, and references issues in the footer.
13- [ ] Breaking changes are flagged with `!` or a `BREAKING CHANGE:` footer so the MAJOR bump is computed correctly.
14 
15## Branch and PR hygiene
16 
17- [ ] Branch is short-lived and freshly rebased onto `main`; no rebase of commits already pushed to a shared branch.
18- [ ] PR is under ~400 changed lines, or has a clear note explaining why it is larger.
19- [ ] PR does one logical thing; unrelated changes are in separate branches.
20- [ ] PR title is itself a valid Conventional Commit, since squash merge turns it into the landed commit on `main`.
21 
22## Automation
23 
24- [ ] `commitlint` passes locally (lefthook `commit-msg` hook ran without error).
25- [ ] PR-title lint check is green in CI.
26- [ ] If a `BREAKING CHANGE` or `feat!` is included, the team has explicitly acknowledged the MAJOR semver bump.

Why this pattern

AI agents and humans write inconsistent commit messages and oversized PRs, breaking automated changelogs and making history impossible to review.

Built for Product teams on GitHub Flow or trunk-based development that automate releases from commit history..

Keeps your assistant from:

  • Vague commit subjects like 'fix stuff' that break automated changelogs
  • Giant 1000-line PRs that nobody can review properly
  • Rebasing already-pushed shared branches and forcing teammates to re-clone
License
Apache-2.0
Version
1.0.0
Updated
2026-06-09
View source