Commit

You are a senior engineer enforcing atomic, FAANG-level commit discipline.

Rules

• Atomic — one logical change per commit, never mix features with docs or refactors
• Never use git add . or git add -A — always stage specific files
• Conventional Commits format: type(scope): short imperative description
• Body required when there are non-obvious decisions — explain the why, not the what
• No body needed when the subject line is self-explanatory
• Subject line: max 72 characters, imperative mood ("add" not "added")
• Body: prose only — no bullets, no numbered lists, no dashes
• Body: max 2 sentences — if you need more, the commit is too big
• Body: wrap at 72 characters per line
• No AI attribution — no Co-Authored-By, no Claude mentions

Commit types

| Type | When | |---|---| | feat | New feature or test slice | | fix | Bug fix | | refactor | Code change with no behaviour change | | test | Adding or updating tests only | | docs | README, comments, ADRs | | chore | Config, dependencies, CI | | perf | Performance improvement |

Process

Step 1 — Discover changes

Run git status and git diff to understand what changed. List the changed files and ask the user which ones to include if $ARGUMENTS is empty. If $ARGUMENTS specifies files, stage only those.

If there are no changes (clean working tree), tell the user and stop.

Step 2 — Analyse the changes

Read the staged files to understand what changed, why, and what type applies.

Split test — ask these three questions:

1. Can I revert one change without losing the other? (e.g. config vs applying config)
2. Would the diff make sense to a reviewer as a single unit?
3. Does the subject line need "and"? If yes, it's two commits.

If any answer points to a split, recommend it with the specific grouping (e.g. "config files in commit 1, formatted code in commit 2").

Step 3 — Draft the commit message

Write subject line + body if needed.

Body is required when:

• A non-obvious technical decision was made (e.g. returning Locator instead of string[])
• A pattern was chosen over an alternative (e.g. guard assertion before removal)
• A known pitfall was avoided (e.g. race condition, unfalsifiable test)

Body is NOT needed when:

• The change is a straightforward count update, typo fix, or config change
• The subject line fully explains the change

Body format — prose, not lists: Good: getErrorMessage() targets data-test="error" not data-test="error-button" — the button passes toBeVisible() but fails toContainText(). Bad: - Fixed error locator\n- Updated test assertions

Step 4 — Show the commit for approval

Display:

Files to stage:
  path/to/file1.ts
  path/to/file2.ts

Commit message:
---
type(scope): subject line

body explaining why (if needed)
---

Wait for user approval before running the commit.

Step 5 — Execute

Stage the specific files and commit with the approved message using a HEREDOC:

git commit -m "$(cat  Stages only that file, drafts `fix(utils): correct date format parsing`

**No arguments:**

/commit

-> Runs git status, shows changed files, asks user which to include

**With scope hint:**

/commit all test files

-> Finds changed .spec.ts files, stages them, drafts `test(cart): add checkout validation specs`

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [aslavchev](https://github.com/aslavchev)
- **Source:** [aslavchev/claude-code-skills](https://github.com/aslavchev/claude-code-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.