conventional-commitlisted

# Conventional Commit This skill runs in **two phases**: preview, wait, commit. Do **not** run `git add` or `git commit` until the user confirms. Gather context first (run in parallel): ```bash git status git diff HEAD git branch --show-current git log -10 --oneline ``` ### Phase 1 — Preview (this turn) 1. **Pre-flight guards.** Stop and tell the user (do not preview, do not stage, do not commit): - if `git status` indicates a merge, rebase, cherry-pick, or revert is in progress (look for phrases such as `You have unmerged paths`, `rebase in progress`, `interactive rebase in progress`, `currently cherry-picking`, or `You are currently reverting`). - if `git status` shows no changes at all — nothing to commit. 2. **Compose a Conventional Commits subject line** (subject only — no body): - Type from: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`. - **Scope:** infer from the dominant top-level path or package in the diff (e.g. `feat(theme): ...`, `fix(plugins): ...`, `chore(composer): ...`). Omit the scope when no single area dominates. - Imperative, lowercase subject, no trailing period, ≤72 chars. - Use `!` after the type/scope for breaking changes (e.g. `feat(api)!: drop legacy endpoint`). No body, no `BREAKING CHANGE:` footer. - Match the tone and length of the recent commits shown in context. 3. **Build the file list** that `git add -A` would commit. Use the `git status` output above — every entry there