code-commit

Conventional Commit Skill

Create coherent, reviewable commits that follow the Conventional Commits specification. Message syntax matters, but the selected changes must tell one clear story too.

Message Format

Every generated commit has a title and body:

<type>(<scope>): <imperative title>

<1-5 lines describing the change and, when useful, its reason or effect>

Use a lowercase scope that identifies the affected component. The title is concise, imperative, lowercase, and has no trailing period. The body is concrete: explain the behavior, motivation, or important implementation decision rather than restating the title.

Type	Use for
feat	New user-facing capability
fix	Corrected behavior
docs	Documentation only
style	Formatting only
refactor	Restructuring without behavior change
test	Tests only
chore	Maintenance or tooling
perf	Performance improvement
ci	Continuous integration configuration
build	Build system or dependencies
revert	Reverting a prior commit

Breaking changes may use ! after the type or scope, a BREAKING CHANGE: footer, or both. Include issue footers such as Closes #123 only when the issue is known.

Create a Commit

When the user asks to commit, first inspect the complete worktree:

1. Run git status --short.
2. Read both git diff --cached and git diff so pre-staged work is not mistaken for the entire change.
3. List untracked files with git ls-files --others --exclude-standard and inspect relevant ones.
4. Read recent subjects with git log --oneline -10 to match established scopes and wording.
5. Flag likely secrets, credentials, local configuration, or generated output. Do not stage them without explicit direction.

Decide Whether to Split

Default to one commit containing all intended, related changes. Look for an obvious file-level split only when changes are independent and each group can stand alone.