commit-author

name	commit-author
description	Suggests a conventional commit message for the current staged changes, following the rules in `.commitlintrc.yml`: conventional commits format, subject ending with a period, and header ≤ 100 characters. Use when the user asks to "commit", "suggest a commit message", "write a commit", "draft a commit", or "commit these changes". Also trigger on: "what should my commit say", "generate commit message", or any variant of committing staged/unstaged work. Do NOT use for creating PRs, rebasing, or any task that does not end in proposing or executing a git commit.
allowed-tools	Bash Read
license	GPL-3.0-only
metadata	{"version":"0.1.0","author":"Leandro Kellermann de Oliveira <[e-mail]>","model":"sonnet"}

Commit Author

This skill inspects staged (and optionally unstaged) changes in the current repo and proposes a commit message that satisfies the project's .commitlintrc.yml rules:

• Follows the Conventional Commits spec (type(scope): subject).
• Subject line ends with a period (.) — enforced by subject-full-stop: [2, always, '.'].
• Full header is ≤ 100 characters — enforced by header-max-length: [2, always, 100].

---

Step 1 — Inspect staged and recent changes

Run these commands to understand what is about to be committed:

# What is staged
git diff --cached --stat
git diff --cached

# Unstaged changes (for context only — do not commit unless user asks)
git diff --stat

# Recent commits for style reference
git log --oneline -10

If there is nothing staged (git diff --cached returns empty), tell the user and ask whether to stage all changes (git add -A) or a specific set before continuing.

---

Step 2 — Determine commit type

Pick the single best type from the conventional commits vocabulary:

Type	When to use
feat	New feature or capability visible to users/consumers
fix	Bug fix — corrects incorrect behaviour
docs	Documentation only (README, inline comments, docstrings)
style	Formatting, whitespace, lint — no logic change
refactor	Code restructuring without behaviour change, not a bug fix
perf	Performance improvement
test	Adding or correcting tests, no production code change
build	Build system, packaging, dependency changes (pyproject, Makefile…)
ci	CI/CD pipeline changes (GitHub Actions, Makefile ci targets…)
chore	Maintenance that fits none of the above
revert	Reverts a previous commit — include the reverted SHA in the body

If the change spans multiple types, choose the dominant one. If two types are genuinely co-equal (e.g. feat + test), split into two commits and say so.

---

Step 3 — Determine scope (optional but preferred)

Scope is the subsystem or module most affected. Derive it from the changed file paths:

Path pattern	Suggested scope
*/skills/<name>/	<name> (skill name)
*/.claude-plugin/	plugin
src/<module>/	<module>
tests/	tests
.github/	ci
docs/	docs
pyproject.toml, ruff.toml, lock files	deps or build
Root config files (.env, .gitignore)	config

If changes are repo-wide or cross multiple unrelated scopes, omit the scope.

---

Step 4 — Compose the subject line

Rules (all are hard requirements from .commitlintrc.yml):

1. Imperative mood — "add", "fix", "remove", not "added", "fixes", "removes".
2. No capital first letter after the colon+space — feat: add … not feat: Add ….
3. Ends with a period — the last character of the subject must be ..
4. Full header ≤ 100 characters — count type(scope): subject. including the dot.

Formula:

<type>(<scope>): <concise imperative description ending with .>

Examples (all valid):

feat(commit-author): add conventional commit suggestion skill.
fix(parser): handle empty diff output gracefully.
refactor: extract scope-detection logic into helper.
docs(wap): add Iceberg cherry-pick example.
chore(deps): bump ruff to 0.4.0.

If the first draft exceeds 100 characters, shorten the description — abbreviate the scope or tighten the wording. Never truncate with ….

---

Step 5 — Compose the body (when needed)

Add a body when the why is non-obvious from the subject alone. Skip it for routine changes (style fixes, version bumps, trivial additions).

Body format:

• Blank line separating header from body.
• Wrap at 72 characters per line.
• Explain why the change was made, not what (the diff already shows what).
• If reverting, include: Reverts <SHA> — <reason>.

---

Step 6 — Present and optionally commit

Present the proposed message to the user:

Proposed commit message:

  <header>

  <body if any>

Then ask:

• Commit as-is? — run git commit -m "…" (or with a HEREDOC if multi-line).
• Edit first? — show the message for the user to adjust, then commit.
• Skip committing? — copy the message for manual use.

Only run git commit if the user explicitly confirms. Never amend a previous commit unless the user asks.

---

Validation checklist (run mentally before presenting)

• Type is from the approved list.
• Scope (if present) matches the dominant changed subsystem.
• Subject is in imperative mood.
• Subject starts with a lowercase letter after ": ".
• Subject ends with ..
• Full header (type(scope): subject.) is ≤ 100 characters.
• Body (if present) is separated by a blank line and wraps at 72 chars.

---

Error handling

• Nothing staged: inform the user, show unstaged files, ask what to stage.
• Not a git repo: stop and tell the user.
• Ambiguous changes spanning many unrelated areas: propose splitting into multiple commits, one per logical concern.
• Pre-commit hook fails after committing: do NOT amend. Fix the underlying issue, re-stage, and create a new commit.