---
name: commit
description: Create a git commit following project conventions. Use when the user says "/commit", "commit my changes", "make a commit", "commit this", or "commit and changelog". Runs pre-commit checks, creates a conventionally formatted commit, then invokes the changelog skill.
version: 1.0.0
argument-hint: [feature|fix|chore|...] [squash]
allowed-tools: [Bash, Read]
---

# Commit Skill

Create a well-formed git commit. This skill orchestrates three steps in order:
1. Pre-commit checks (formatting, linting)
2. Commit creation
3. Changelog update

## Step 1 — Pre-Commit Checks

Before staging or committing anything, invoke the **pre-commit** skill. Do not proceed if pre-commit fails.

## Step 2 — Analyse Changes

Gather context:
```bash
git status
git diff HEAD
git log --oneline -10
```

Use this to understand:
- What changed and why (infer from diff + recent commit messages)
- Whether this is a single atomic change or a set of related changes
- What commit type applies (see Conventional Commits below)

## Step 3 — Squash Decision

**Squash when:** the user passes `squash` as an argument, OR there are multiple recent commits that are clearly part of the same feature/fix and have not yet been pushed to the remote.

To check if commits are unpushed:
```bash
git log @{u}..HEAD --oneline 2>/dev/null || git log --oneline -5
```

If squashing: use `git reset --soft <base-sha>` to collapse the commits, then create a single feature commit. Confirm with the user before squashing if it is not explicit in their request.

**Do not squash** if any of the commits have already been pushed to the remote.

## Step 4 — Stage Files

Stage relevant files:
```bash
git add <files>
```

- Prefer staging specific files over `git add -A`.
- Never stage: `.env`, credentials, secrets, compiled artefacts (unless the project tracks them intentionally).
- If unrelated changes are present in the working tree, stage only the files relevant to this commit and note what was left unstaged.

## Step 5 — Commit Message

Follow **Conventional Commits** format:

```
<type>(<scope>): <short description>

[optional body]
```

**Types:** `feat`, `fix`, `refactor`, `chore`, `docs`, `test`, `perf`, `style`, `build`, `ci`

**Rules:**
- Subject line: imperative mood, no period, ≤72 characters.
- Scope: optional, lowercase, matches a module/subsystem name.
- Body: explain the *why*, not the *what*. Wrap at 72 characters.
- **No `Co-authored-by`, `Generated by`, or `Authored by` lines** — ever.
- Match the style of recent commits in the repo when a pattern is established.

**Examples:**
```
feat(audio): add silence detection pass before VAD

fix(tokenizer): load added_tokens from tokenizer.json

refactor(decoder): extract beam search into separate module

chore: update dependencies
```

Create the commit:
```bash
git commit -m "$(cat <<'EOF'
<type>(<scope>): <description>

<body if needed>
EOF
)"
```

## Step 6 — Invoke Changelog Skill

After the commit succeeds, immediately invoke the **changelog** skill. The changelog skill will update `CHANGELOG.md` and amend the commit to include it.

## Error Handling

- If pre-commit fails: stop, report errors, do not commit.
- If staging fails: report which files could not be staged and why.
- If the commit command fails: report the error verbatim.
- If changelog fails: report it but do not undo the commit — the user can run `/changelog` separately.
