Conventional Commit

Write a well-structured commit message following the Conventional Commits specification.

When to use

The user has their own commit message format documented in §10 of their project's Copilot instructions
The project uses a different commit convention (check §4 and §10 of the project's Copilot instructions first)

Read the staged changes — Run git diff --cached --stat to see which files changed, then git diff --cached for the full diff.

Determine the type — Choose the most appropriate type:

Type	When to use
`feat`	A new feature or capability
`fix`	A bug fix
`docs`	Documentation-only changes
`style`	Formatting, whitespace, semicolons — no logic change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependency changes
`ci`	CI configuration changes
`chore`	Maintenance tasks that don't modify src or test files

Determine the scope — Identify the primary area affected (e.g., auth, api, ci, docs). Use the directory name or module name. Omit scope if the change spans many areas.
Write the subject line — Format: <type>(<scope>): <imperative summary>
- Use imperative mood ("add", not "added" or "adds")
- Lowercase first letter after the colon
- No period at the end
- Maximum 72 characters
Write the body (if the change is non-trivial):
- Blank line after the subject
- Explain what changed and why (not how — the diff shows how)
- Wrap at 72 characters
- Reference issue numbers if applicable: Fixes #123, Closes #456
Add breaking change footer (if applicable):
- Add ! after the type/scope: feat(api)!: remove v1 endpoints
- Add footer: BREAKING CHANGE: <description of what breaks and migration path>
Present the message — Show the complete commit message for user review:
```
<type>(<scope>): <subject>

<body>

<footer>
```
Wait for approval — Do not run git commit until the user approves or modifies the message.