---
name: git-commit
description: Creates a git commit summarizing all current working tree changes (staged and unstaged). Use when the user asks to commit, save progress, or invoke /git-commit.
---

# Git Commit

## When to use

- When the user asks to commit current changes.
- When invoked via `/git-commit`.

## Arguments

- `dry-run` — perform steps 1–3 only (gather context, identify files, draft commit message) and then **ask the user** whether to proceed with the actual commit or cancel. Do **not** stage or commit until the user confirms.

## Workflow

1. **Gather context** — run these commands in parallel:
   - `git status` — to see all tracked modifications and untracked files.
   - `git diff` and `git diff --cached` — to see unstaged and staged changes.
   - `git log --oneline -10` — to match the repository's commit message style.

2. **Stage all relevant changes** — add all modified and untracked files that are part of the current work. Use specific file paths rather than `git add -A`. Do **not** stage files that likely contain secrets (`.env`, credentials, etc.) — warn the user if any are present.

3. **Draft the commit message** — analyse the diff and write a concise commit message:
   - One summary line (imperative mood, under 72 characters) describing the *why* / *what* of the change.
   - If the change is non-trivial, add a blank line followed by bullet points elaborating key changes.
   - **Don't pad small commits**: if the summary line already captures the change, omit the body entirely. Most single-purpose commits need only the summary line.
   - **Stay high-level**: never reference code-level details like variable names, function names, method calls, or file paths in the commit message. Describe *what changed for the user or system*, not *which functions were modified*.
   - Match the style and conventions visible in the recent git log.

4. **Commit** — create the commit using a heredoc for the message:
   ```bash
   git commit -m "$(cat <<'EOF'
   <summary line>

   <optional body>
   EOF
   )"
   ```

5. **Verify** — run `git status` after the commit to confirm it succeeded and the working tree is clean (or shows only intentionally unstaged files).

6. **Show the commit** — run `git log -1` and display the **entire** commit message (summary line and body) to the user so they can review it. Do not truncate or abbreviate — if the message has bullet points or a multi-line body, include all of it in your response.

## Rules

- Never amend an existing commit unless the user explicitly asks.
- Never push to the remote unless the user explicitly asks.
- Never use `--no-verify` or skip pre-commit hooks.
- If a pre-commit hook fails, fix the issue, re-stage, and create a **new** commit (do not amend).
- Never stage `.env`, credential files, or other secrets.
- Never add `Co-Authored-By`, `Authored-By`, `Made-with` or any other attribution trailer to commit messages.