conventional-commitslisted

# Conventional Commits ## Core Question What Conventional Commit message accurately describes the exact change evidence provided, without expanding scope or claiming unsupported impact? ## When To Use Use this skill when the user asks to: - write or revise a Conventional Commit message, - validate an existing commit message, - choose a commit type, scope, subject, body, or footer, - express a breaking change using `!` or `BREAKING CHANGE:`, - generate a message from staged diff or from explicitly provided diff evidence. ## When Not To Use Do not use this skill to stage files, unstage files, create commits, split commits, or decide atomic boundaries. Route to: - `atomic-commits` when the task requires staging, unstaging, commit execution, commit splitting, or multiple commits. - `changelog-maintenance` when updating a changelog file. - `release-notes` when drafting user-facing release notes. - `version-bump` when deciding or editing versions. - `tag-release` when creating or pushing Git tags. ## Required Evidence Inspect or establish: - the exact staged diff when the message is for the current commit, - the exact file or hunk evidence provided by a caller such as `atomic-commits`, - user-provided change summary when no repository evidence is available, - project commit conventions such as `.commitlintrc*`, `commitlint.config.*`, `package.json`, `CONTRIBUTING.md`, or recent commit style, - breaking-change evidence before using `!` or a `BREAKING CHANGE:` footer, - i