Commit Author

---
name: commit-author
version: 1.12.0
description: Generate concise Conventional Commits messages from a staged diff. Enforces full type set, imperative subject lines, no AI co-author attribution. Use when user wants to commit, asks for a commit message, mentions "commit", or invokes /commit.
---

# Git Commit Standards

## 1. Format
* **Structure:** `<type>(<optional scope>): <subject>`

## 2. Allowed Types

Full Conventional Commits v1.0.0 type set (Angular convention):

| Type | When to use |
|---|---|
| `feat` | New feature for the user (MINOR in SemVer) |
| `fix` | Bug fix for the user (PATCH in SemVer) |
| `refactor` | Code change that neither fixes a bug nor adds a feature |
| `perf` | Code change that improves performance |
| `docs` | Documentation-only changes |
| `style` | Formatting only, no code-meaning change |
| `test` | Adding or correcting tests; no production code change |
| `build` | Build system or external dependency changes (e.g. npm, go.mod, Dockerfile) |
| `ci` | CI configuration changes (GitHub Actions, pipelines) |
| `chore` | Maintenance tasks that don't fit elsewhere (no src/test changes) |
| `revert` | Reverts a previous commit; body must reference the reverted SHA |

## 3. Subject Line
* **Rules:** Use imperative mood (e.g., `add`, not `added`), maximum 50 characters, lowercase start, and no trailing period.

## 4. Body
* **Content:** Explain *why* the change was made, not *what* changed. Do not write line-by-line file summaries.
* **Formatting:** Hard wrap lines at 72 characters.

## 4.1 Merge Commits
* **Body content:** A bare `Merge branch '...'` message is not enough when the merge brings in meaningful changes. Use the body to summarize all the changes the merge introduces — group them by type or area, and note the key behavioral changes.
* **Format:** Keep the conventional `<type>(<scope>): <subject>` form (commonly `chore(merge): ...` or `feat: ...`), then list the aggregated changes in the body, hard wrapped at 72 characters.
* **Footers:** Reference the merged branch or PR and any issues resolved by the combined work.

## 5. Footers
* **Breaking Changes:** Must begin with `BREAKING CHANGE:` followed by a migration path. Applies to any type and forces a MAJOR version bump.
* **References:** Append related issues at the bottom (e.g., `Resolves #12`).

## 6. Attribution
* **Do not add AI co-authorship.** Never include `Co-Authored-By: Claude` or any other AI-attribution footer. Commits belong to the human author who reviewed and approved the change.
* **Harness-added trailers are outside this skill.** Some tools append an attribution line on their own; this skill never writes one, and the message it drafts has none. If a project does not want the tool's line either, that is the tool's setting to change, not something to strip by hand.

## 7. Execution Protocol

* **User-initiated only.** This skill activates *only* when the user explicitly asks to commit — phrases like "commit this", "write the commit message", "let's commit", or invoking `/commit`. **Never volunteer to commit unprompted.** Don't propose commits at the end of a task, don't pre-emptively stage files, and don't run `git add` / `git commit` as cleanup after other work.
* **Consent to execute.** When asked to draft a commit message: ask whether the user will run the commit themselves or wants you to. **Never run `git commit` without explicit go-ahead** for the specific commit being created.
* **Scope per ask.** Permission to commit one set of changes is not blanket permission for future commits in the same session.
* **Signing:** Delegated commits must be GPG signed if configured, unless the user explicitly opts out.