Git & Conventional Commits
Pathrule2 Rules • 2 Memories • 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 and small focused PRs
Rebase vs merge decision guide
git-conventional-commits-review
.github/
Commit and release automation stack
Rules
2Commit messages follow Conventional Commits v1.0.0/roothighstrictEvery commit subject uses a Conventional Commits type and stays under 50 characters.
| 1 | Format every commit as `<type>[optional scope][!]: <description>` per Conventional Commits v1.0.0 so `release-please` can derive versions and changelogs. |
| 2 | |
| 3 | - Use only these types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`. |
| 4 | - Keep the subject in imperative mood, lowercase after the colon, no trailing period, and at most 50 characters; wrap the body at 72. |
| 5 | - A `feat` maps to a MINOR bump and a `fix` to a PATCH; signal breaking changes with a `!` 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`. |
Short-lived branches and small focused PRs/roothighadvisoryBranch off main, keep PRs under ~400 lines, and never rebase pushed shared branches.
| 1 | Work on short-lived branches cut from `main` and merge them back within a day or two to keep integration cheap. |
| 2 | |
| 3 | - Target under ~400 changed lines per PR; split larger work into stacked or sequential PRs. |
| 4 | - One logical change per PR so reviews are fast and reverts are clean. |
| 5 | - Rebase your local branch onto `main` to stay current, but never rebase a branch others have already pulled. |
| 6 | - Use squash merge so each PR lands as a single Conventional Commit on `main`; the PR title becomes that commit and must pass commit linting. |
Memories
2Rebase vs merge decision guide/rootWhen to rebase, when to merge, and the one rule you must never break.
| 1 | Pick the integration strategy by branch lifecycle, not by habit. |
| 2 | |
| 3 | - Rebase private short-lived feature branches onto `main` before opening or updating a PR to keep a linear, bisectable history. |
| 4 | - Use a true merge (no rebase) for long-lived branches like a release branch going back into `main`, preserving collaboration context. |
| 5 | - The hard rule: never rebase commits already pushed to a shared branch, since rewriting public history forces teammates to force-pull or re-clone. |
| 6 | - Prefer squash merge for PR landings so the merged result is one clean Conventional Commit regardless of messy intermediate commits. |
Commit and release automation stack/.githubHow commitlint, lefthook, and release-please wire together in CI.
| 1 | Commit hygiene is enforced locally and in CI, then drives automated releases. |
| 2 | |
| 3 | - `@commitlint/cli` with `@commitlint/config-conventional` validates messages; run it from a `lefthook` `commit-msg` hook so bad messages never get committed. |
| 4 | - Because we squash merge, the PR title becomes the commit, so lint PR titles in a GitHub Action against the same Conventional Commits rules. |
| 5 | - `release-please` parses Conventional Commits on `main`, opens a release PR with the computed semver bump and generated `CHANGELOG.md`, and cuts the GitHub release on merge. |
| 6 | - Keep `lefthook.yml` and the commitlint config at the repo root; keep the release-please and PR-title-lint workflows under `/.github/workflows`. |
Skills
1git-conventional-commits-review/rootPre-commit and pre-PR checklist for clean commits and reviewable pull requests.
| 1 | --- |
| 2 | name: git-conventional-commits-review |
| 3 | description: Checklist to run before committing and before opening a PR so commits follow Conventional Commits v1.0.0, branches stay short-lived, and PRs stay small and reviewable. Use when writing a commit, opening a pull request, or reviewing git history hygiene. |
| 4 | --- |
| 5 | |
| 6 | # Git & Conventional Commits review |
| 7 | |
| 8 | - [ ] Subject matches `<type>[scope][!]: <description>` using an allowed type (`feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`). |
| 9 | - [ ] Subject is imperative mood, lowercase after the colon, no trailing period, and at most 50 characters. |
| 10 | - [ ] Body (if present) explains the why, wraps at 72 characters, and references issues in the footer. |
| 11 | - [ ] Breaking changes are flagged with `!` or a `BREAKING CHANGE:` footer so the MAJOR bump is correct. |
| 12 | - [ ] The change is one logical unit; unrelated changes are split into separate commits or PRs. |
| 13 | - [ ] Branch is short-lived and freshly rebased onto `main`, with no rebase of commits already pushed to a shared branch. |
| 14 | - [ ] PR is under ~400 changed lines, or has a clear plan to split it. |
| 15 | - [ ] PR title is itself a valid Conventional Commit, since squash merge turns it into the landed commit. |
| 16 | - [ ] `commitlint` and the PR-title lint check pass locally and in CI before requesting review. |
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