conventional-commitslisted

# Conventional Commits (v1.0.0) Use the Conventional Commits spec to produce consistent commit messages that are easy to parse for changelogs and semantic versioning. ## Commit message format (canonical) ```text <type>[optional scope][!]: <description> [optional body] [optional footer(s)] ``` Rules: - Separate **header**, **body**, **footers** with a blank line. - Keep the **header** on one line. - Put `!` immediately before `:` to mark a breaking change (e.g. `feat!: ...`, `refactor(api)!: ...`). ## Choose a type The spec allows any type, but these are common and widely supported by tooling: - `feat`: introduce a new feature (user-facing) - `fix`: bug fix (user-facing) - `docs`: documentation-only changes - `refactor`: refactor that neither fixes a bug nor adds a feature - `perf`: performance improvement - `test`: add or adjust tests - `build`: build system/dependencies - `ci`: CI configuration/scripts - `chore`: maintenance tasks - `style`: formatting (whitespace, missing semicolons, etc.) - `revert`: revert a previous commit Default choice when unsure: - If users see new behavior → `feat` - If users see corrected behavior → `fix` - Otherwise → `chore` or a more specific maintenance type (`refactor`, `build`, `ci`) ## Optional scope Use scope to clarify the area impacted. Format: ```text type(scope): description ``` Guidelines: - Use a short noun: `api`, `auth`, `ui`, `db`, `cli`, `deps`, `docs`. - Use repo/module/package name when working in a monorepo. -