Create a git commit following the Conventional Commits specification (conventionalcommits.org). Reads the diff, auto-infers scope from file paths, proposes type + scope + description + body, and shows the message for approval before committing. Supports optional push, language choice, Claude attribution, staging control, breaking-change marking, amend, and issue references. Global and project-agnostic. Trigger when the user says "commit", "make a commit", "commit my changes", "create a commit...
Scanned 6/9/2026
Install via CLI
Skills Directoryopenskills install ada-ggf25/AI-Tools---
name: commit
description: Create a git commit following the Conventional Commits specification (conventionalcommits.org). Reads the diff, auto-infers scope from file paths, proposes type + scope + description + body, and shows the message for approval before committing. Supports optional push, language choice, Claude attribution, staging control, breaking-change marking, amend, and issue references. Global and project-agnostic. Trigger when the user says "commit", "make a commit", "commit my changes", "create a commit", "/commit", or "commit with conventional commits".
---
# Conventional Commits — git commit skill
Creates a well-formed [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)
commit from the current working tree. Reads the diff, proposes a message for approval, then
commits. Never commits silently — the user always sees and approves the message first.
## Accepted flags (parsed from the user's invocation text)
| Flag | Effect |
|---|---|
| `--push` | `git push` after a successful commit |
| `--british` | British English spelling in the message (default: American English) |
| `--credit` | Append `Co-Authored-By: Claude` trailer to the commit |
| `--all` | Stage all modified/deleted tracked files before committing (equivalent to `git add -u`) |
| `--staged` | Commit only what is already staged; never touch the index |
| `--breaking` | Mark as a breaking change (appends `!` and adds `BREAKING CHANGE:` footer) |
| `--amend` | Amend the last commit instead of creating a new one |
| `--closes N` | Append `Closes #N` footer |
| `--refs N` | Append `Refs #N` footer |
If the user provides a free-text hint (e.g. `/commit fix the login redirect loop`), use it
as a strong signal for the description — do not ignore it.
## Conventional Commits format
```text
<type>[optional scope]: <description>
<body>
[optional footers]
```
**Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`
**Scope:** noun in parentheses describing the section of the codebase (e.g. `feat(auth):`)
**Breaking change:** append `!` after type/scope AND add `BREAKING CHANGE: <explanation>` footer
**Description:** imperative mood, no period at the end, lowercase after the colon
**Body:** starts one blank line after the description; explains *what* and *why*, not *how*
## Procedure
### 1. Parse flags and hint
- Extract all flags listed above from the user's invocation.
- Capture any free-text after the command name (and after flags) as the user hint.
- Determine staging mode:
- `--staged` → use index as-is.
- `--all` → run `git add -u` (tracked files only; never `git add .`).
- Neither flag → if staged files exist, use the index; if nothing staged, default to
`git add -u` and inform the user.
### 2. Gather diff context
Run these in parallel:
- `git status --short` — working tree overview.
- `git diff --cached --stat` + `git diff --cached` — staged changes (what will be committed).
- `git diff --stat` — unstaged changes (for awareness).
- `git log --oneline -5` — recent commit style reference.
### 3. Branch guard
- Check current branch: `git rev-parse --abbrev-ref HEAD`.
- If the branch is `main` or `master`: **pause and require explicit confirmation** before
proceeding. State the branch name clearly. Do not commit until the user says yes.
### 4. Sensitive-file check (only when staging with `--all` or defaulting to `git add -u`)
- Scan for files matching patterns: `.env*`, `*credentials*`, `*secret*`, `*token*`,
`*.pem`, `*.key`, `*.p12`, lock files over 1 MB.
- If any are found, list them and ask the user to confirm before including them.
### 5. Infer scope from file paths
- Group the staged files by top-level directory or dominant component. Examples:
- All changes in `src/auth/` → scope `auth`
- Mix of `src/api/` and `tests/api/` → scope `api`
- Changes scattered across many directories → no scope
- Propose the inferred scope (or "no scope") and let the user accept, change, or drop it.
### 6. Propose the commit message
Compose a full draft:
- **Type:** infer from the nature of the changes (bug fix → `fix`, new feature → `feat`,
dependency bump → `chore`, etc.). State your reasoning in one line.
- **Scope:** from step 5.
- **Description:** imperative, lowercase, ≤72 chars total for the subject line, informed
by the user's hint if one was given. Use American English unless `--british` was passed.
- **Body:** always generate a paragraph (2–4 sentences) explaining *what changed* and *why*.
Do not describe *how* (the diff already shows that). Use the same language as the subject.
- **Breaking change:** if `--breaking` was passed, append `!` to type/scope and add a
`BREAKING CHANGE: <explanation>` footer.
- **Issue refs:** if `--closes N` or `--refs N` were passed, add the corresponding footers.
- **Attribution:** if `--credit` was passed, append `Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>`.
Show the full proposed message in a code block. Ask the user to approve, edit, or cancel.
Do not proceed until the user approves.
### 7. Stage files (if not `--staged`)
- Run the staging command determined in step 1 (`git add -u` or specific files if the
user narrowed the scope during review).
### 8. Commit
- Run `git commit -m "$(cat <<'EOF'\n<message>\nEOF\n)"` using a heredoc to preserve
formatting. Pass `--amend` if `--amend` flag was given.
- If the commit fails (pre-commit hook or other error): **do not retry with --no-verify**.
Diagnose the error, fix the underlying issue, and create a fresh commit.
### 9. Push (if --push)
- Run `git push`. If the branch has no upstream, suggest `git push -u origin <branch>` and
ask before running it.
### 10. Report
- Show the commit hash and subject line (`git log --oneline -1`).
- If pushed, confirm the remote ref.
## Guardrails
- **Never commit without user approval of the message.** Always show the full proposed
message and wait for explicit confirmation.
- **Never use `--no-verify`** to bypass pre-commit hooks. Fix the root cause instead.
- **Never use `git add .`** (may include untracked sensitive files). Use `git add -u` or
explicit file paths.
- **Never force-push** unless the user explicitly asked for it in this invocation.
- **Never amend a commit that has already been pushed** to a remote without warning the
user that this will require a force-push.
- **Require explicit confirmation** before committing to `main` or `master`.
- Keep the subject line ≤72 characters (Conventional Commits + readability best practice).
- Always write the body; the spec requires only a subject but this skill always adds one.
- If the diff is empty (nothing staged, nothing changed), say so and stop — do not create
an empty commit.
No comments yet. Be the first to comment!
