conventional-commits-writinglisted

# conventional-commits-writing ## When to use Use this skill when: - Generating a commit message from staged changes - Generating a squash merge title from a PR - Deciding the correct Conventional Commit type for a change - Reviewing whether a commit message is correct - Splitting one vague change into multiple commit messages Do NOT use when: - Only explaining the Conventional Commits standard (just reference the rule) - The message is already correct and does not need review - Following the Git workflow (use `git-workflow` skill) ## Procedure: Generate commit message ### 1. Identify the actual intent Determine whether the change is: - New behavior → `feat` - Bug fix → `fix` - Structural cleanup → `refactor` - Docs only → `docs` - Tests only → `test` - CI/build/tooling → `ci` or `build` - Maintenance → `chore` - Performance → `perf` - Formatting only → `style` Classify by **user-visible or system-relevant intent**, not by file type alone. ### 2. Detect mixed concerns Check whether the change includes more than one unrelated concern. If yes: - Suggest splitting into multiple commits - Or choose the dominant net effect for squash merge title ### 3. Choose scope Add a scope only if it improves clarity: - Jira ticket ID: `DEV-1234` - Module/area: `api`, `auth`, `skills`, `rules`, `ci` ### 4. Write the description - State the intent clearly - Avoid generic filler (`update stuff`, `fix things`) - Stay concise — max 72 chars total for first line - Imperative mood