conventional-commit

name	conventional-commit
description	Preview a Conventional Commits subject for all working-tree changes, then commit only after the user confirms. Use when the user asks for a conventional commit, commit preview, or to commit with confirmation.
disable-model-invocation	true

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):

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 (modified, added, deleted, renamed, untracked) is included. Use simplified single-letter prefixes:

   • M modified
   • A added
   • D deleted
   • R renamed (R old -> new)
   • ?? untracked

   Render as a plain markdown bullet list (not inside a fenced code block). Wrap each prefix + path in inline backticks so paths render monospaced. Example:

   • M public/app/themes/example/functions.php
   • A public/app/themes/example/inc/foo.php
   • ?? public/app/themes/example/new.php

   Cap at 30 files. If more, show the first 30 and add a final bullet - ... and N more files.

4. Present the preview as a single message with exactly these sections in this order:

   • Branch: <current branch>
   • Commit message: the proposed subject line in a fenced code block.
   • Files (N): the bullet list from step 3, where N is the total file count (not capped).
   • Final line: Reply 'yes' (or 'y') to commit, anything else to abort.

   Do not include diff sizes, per-directory summaries, or any other metadata.

5. STOP. Do not call any tools after presenting the preview. Wait for the user's reply.

Phase 2 — Commit (next turn, only on confirmation)

6. Strict confirmation check. The reply counts as confirmation only if, after trimming whitespace and lowercasing, it is exactly one of: yes, y, confirm, ok. Anything else — including sure, go, lgtm, yes but ..., or any request to modify the message — aborts. On abort, reply Commit aborted. and do nothing else (no staging, no commit, no follow-up questions).

7. On confirmation, in a single message via parallel tool calls where possible:

   • git add -A
   • git commit -m "<message>"
   • git log -1 --oneline and report the resulting short SHA + subject to the user.

   Do not push. Do not create branches. Do not create PRs.