conventional-commitslisted

This skill inspects your staged changes and produces a commit message that follows the [Conventional Commits](https://www.conventionalcommits.org/) specification. It picks the right type and scope, writes a concise imperative subject, adds a body explaining the *why* when the change is non-trivial, and flags breaking changes correctly — so your history stays readable and your tooling (changelogs, semantic-release) keeps working. ## When to use this skill - You have changes staged with `git add` and want to commit them. - You want a consistent, spec-compliant message instead of free-form text. - You are unsure which type (`feat`, `fix`, `chore`, …) fits the change. - Your repo uses semantic versioning or automated changelog generation that depends on commit conventions. > [!NOTE] > This skill only reads and commits what is **already staged**. Stage the exact hunks you want first (`git add -p`). It will not stage files for you. ## Instructions 1. Read the staged diff to understand what actually changed: ```bash git diff --cached ``` If nothing is returned, stop and tell the user there are no staged changes to commit. 2. Check the staged file list for scope hints (directory or package names): ```bash git diff --cached --name-only ``` 3. Choose the **type** from the staged changes: - `feat` — a new user-facing capability - `fix` — a bug fix - `docs` — documentation only - `style` — formatting, no logic change - `refactor` — code change tha