# Conventional Commit

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

- Skill: `eminboydak/conventional-commit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add eminboydak/conventional-commit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/eminboydak/conventional-commit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: eminboydak (https://skillmd.com/u/eminboydak)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/eminboydak/conventional-commit

---


# 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 staged diff.
4. Write the commit message following the format above.
5. Repeat per logical change until the work is fully committed.
6. Never push unless the user explicitly asks.

## Examples

```
feat(serial): add port discovery with USB metadata
fix(ui): prevent terminal overflow on rapid input
docs(adr): add DT-0001 tech stack selection
refactor(ipc)!: replace command interface

BREAKING CHANGE: clients must use new invoke() signatures.
```