---
description: Write a Conventional Commits message for the staged changes
argument-hint: [optional context, e.g. issue ref or scope]
allowed-tools:
  - Bash(git diff *)
  - Bash(git log *)
  - Bash(git status *)
  - Bash(git branch *)
---

## Staged files

!`git diff --cached --stat`

## Staged diff

!`git diff --cached`

## Recent commit subjects (match this style)

!`git log --format=%s -15`

## Current branch

!`git branch --show-current`

## Extra context from the user

$ARGUMENTS

## Task

Write one commit message for the staged changes above.

1. If nothing is staged, say so and stop. Do not stage files.
2. If the staged changes contain clearly unrelated changes, say which files belong together and suggest splitting. Still offer a message for the whole set.
3. Format:
   ```
   <type>(<scope>): <subject>

   <body>

   <footers>
   ```
   - `type`: one of `feat`, `fix`, `perf`, `refactor`, `docs`, `test`, `build`, `ci`, `chore`, `revert`. Choose by effect: user-visible new capability is `feat`; corrected behavior is `fix`; no behavior change is `refactor`.
   - `scope`: include only if recent commits use scopes; use the same vocabulary.
   - `subject`: imperative mood ("add", not "added"), lowercase start unless the history does otherwise, no trailing period, 72 characters or fewer including the prefix.
   - `body`: include when the reason is not obvious. Explain why and what the impact is, not a file-by-file list. Wrap at 72 characters.
   - Footers: `BREAKING CHANGE: <what and how to migrate>` if a public API, CLI flag, config key, schema or response shape changed incompatibly (also add `!` after the type/scope). Add `Refs: #<n>` or `Closes #<n>` only if the user gave an issue number or the branch name contains one.
4. Do not mention that the message was generated.
5. Output the message in a single fenced code block, then ask: "Commit with this message?"
6. If the user confirms, run `git commit -F -` with the message on stdin (using a heredoc), then show `git log -1 --stat`.