conventional-commitlisted

Use when creating git commits or branches. Enforces Conventional Commits formatting, atomic English commits, and branch naming (type/scope-description) off the integration branch. Triggers on commit, branch, git, Conventional Commits, PR.
eminboydak/embedded-agent-skills · ★ 0 · Code & Development · score 68

Install: claude install-skill eminboydak/embedded-agent-skills

# Conventional Commit & Branch Workflow Enforce the repository's git conventions. All commit and branch text is **English**. The integration branch defaults to `dev`; if the repo uses another name (`main`, `develop`), ask once and reuse it. ## Branches - Feature/fix/refactor work branches off the **integration branch**, never `main` (unless `main` IS the integration branch). - Exception: `hotfix/` may branch off `main` for urgent production fixes. - Naming: `type/scope-short-description`, lowercase `kebab-case`. - Valid types: `feat`, `fix`, `chore`, `docs`, `refactor`, `test`, `hotfix`. - Examples: `feat/serial-connection`, `fix/hex-view-overflow`, `chore/update-deps`. ## Commits - **Atomic**: one logical change per commit. If the description needs "and", split it. - Format: `type(scope): subject` - `type`: `feat`, `fix`, `chore`, `docs`, `refactor`, `test`, `perf`, `ci`, `build`, `style`. - `scope` (optional): affected area (`serial`, `ui`, `docs`...). - `subject`: imperative mood, lowercase first word, no trailing period, ≤72 chars. - Body: explain **why**, not what. Wrap at ~72 chars. Reference issues/ADRs. - Breaking change: `feat(api)!: ...` plus a `BREAKING CHANGE: <reason>` footer. - Stage only the files relevant to the commit. Never bundle unrelated changes. - Never push unless the user explicitly asks. ## Procedure 1. Confirm you are on a correctly named branch off the integration branch. 2. Stage the files for **one** logical change. 3. Re-read the