Version history: Conventional Commits

Initial version.

  ---
  description: Write commit messages in Conventional Commits format.
  alwaysApply: true
  ---
  
  # Conventional Commits
  - - Format: `type(scope): subject` — e.g. `feat(auth): add GitHub sign-in`.
- - Allowed types: feat, fix, docs, style, refactor, perf, test, build, ci, chore.
- - Subject in imperative mood, lower case, no trailing period, under 72 chars.
- - Body explains the why, not the what. Wrap at 100 chars.+ Every commit an agent makes on this repo must be a Conventional Commit. Humans
+ skim `git log`; tools parse it. Do not invent a parallel style.
+ 
+ ## Format
+ 
+ ```
+ type(scope): subject
+ 
+ optional body
+ 
+ optional footer
+ ```
+ 
+ - **type** (required): feat, fix, docs, style, refactor, perf, test, build, ci, chore.
+ - **scope** (optional): a short area name already used in the repo (`auth`, `worker`, `scan`).
+ - **subject**: imperative, lowercase, no trailing period, ≤72 characters.
+   Good: `feat(auth): add Google sign-in`. Bad: `Added Google login.`
+ 
+ ## Body
+ 
+ Explain *why*, not what the diff already shows. Wrap at 100 characters. If the
+ change is a breaking API, start the body with `BREAKING CHANGE:` and a
+ migration hint.
+ 
+ ## Do not
+ 
+ - Mix unrelated work in one commit.
+ - Mention ticket numbers in the subject (footers are fine: `Fixes #123`).
+ - Use `update` or `misc` as a type.