Context
Before proposing anything, run these and read the output in full:
git status
git diff HEAD # staged + unstaged; use --cached when staging exists
git branch --show-current
git log --oneline -10 # match the existing message style
Commit message format
<type>[optional (scope)]: <description>
[optional body]
<Assisted by <model version>>
Types
| Type |
When to use |
feat |
New user-facing feature or capability |
fix |
Bug fix or correcting broken behavior |
ui |
Visual/layout changes |
refact |
Code restructure without changing behavior |
docs |
Documentation, references, specs, product plans |
content |
Case-study copy or assets — src/content/, images, video |
perf |
Performance improvement |
chore |
Maintenance — deps, config, cleanup |
Rules
- One logical change per commit. Group or split by topic — multiple types/scopes = multiple commits.
- Imperative present tense: "add", "fix", "update" — not "added", "fixes", "updated".
- Description under 72 characters. Lead with what changed, not which files.
- Scope is optional — use when it clarifies:
ui(profile):, fix(auth):, feat(directions):.
- Body bullets start with file name — e.g.
- tags.py: add search endpoint with prefix matching.
Safety
- Never commit files that may contain secrets (
.env, credentials, private keys). Warn the user.
- Never use
--no-verify, --force, or amend without explicit user request.
Workflow
If there ARE staged changes:
The commit scope is the staged changes only. Do NOT propose unrelated unstaged/untracked files for inclusion.
- Read the staged diff (
git diff --cached).
- Check unstaged/untracked files for anything directly related to the staged topic that might have been forgotten (e.g., a modified file that belongs with the same logical change). Flag these briefly and ask whether to include — but do not pull in unrelated work.
- If the staged changes cover a single topic → propose one commit message.
- If the staged changes span multiple topics → propose a split with separate commit messages (unstaging and restaging subsets as needed).
- Present the proposal and wait for Y (confirm) or N (reject).
If there are NO staged changes:
- Read all unstaged and untracked changes (
git diff + git status).
- Group changes by topic into one or more commits.
- For each group, list the files and propose a commit message.
- Present the full proposal and wait for Y (confirm) or N (reject).
On confirm (Y):
- Stage the relevant files and create the commit(s) in order.
- If multiple commits, execute them sequentially.
On reject (N):
Arguments:
- If the user provided arguments (e.g.,
/commit fix the search bug), use that as context for the message but still verify the diff matches.
Last Updated: 2026-05-25
1---2name: commit3description: Create a git commit following this project's conventions4---567## Context89Before proposing anything, run these and read the output in full:1011```12git status13git diff HEAD # staged + unstaged; use --cached when staging exists14git branch --show-current15git log --oneline -10 # match the existing message style16```1718## Commit message format1920```21<type>[optional (scope)]: <description>2223[optional body]2425<Assisted by <model version>>26```2728### Types2930| Type | When to use |31|----------|-------------------------------------------------|32| `feat` | New user-facing feature or capability |33| `fix` | Bug fix or correcting broken behavior |34| `ui` | Visual/layout changes |35| `refact` | Code restructure without changing behavior |36| `docs` | Documentation, references, specs, product plans |37| `content`| Case-study copy or assets — `src/content/`, images, video |38| `perf` | Performance improvement |39| `chore` | Maintenance — deps, config, cleanup |4041### Rules42431. **One logical change per commit.** Group or split by topic — multiple types/scopes = multiple commits.442. **Imperative present tense**: "add", "fix", "update" — not "added", "fixes", "updated".453. **Description under 72 characters.** Lead with what changed, not which files.464. **Scope is optional** — use when it clarifies: `ui(profile):`, `fix(auth):`, `feat(directions):`.475. **Body bullets start with file name** — e.g. `- tags.py: add search endpoint with prefix matching`.4849### Safety5051- **Never** commit files that may contain secrets (`.env`, credentials, private keys). Warn the user.52- **Never** use `--no-verify`, `--force`, or amend without explicit user request.5354## Workflow5556### If there ARE staged changes:5758**The commit scope is the staged changes only.** Do NOT propose unrelated unstaged/untracked files for inclusion.59601. Read the staged diff (`git diff --cached`).612. Check unstaged/untracked files for anything **directly related** to the staged topic that might have been forgotten (e.g., a modified file that belongs with the same logical change). Flag these briefly and ask whether to include — but do not pull in unrelated work.623. If the staged changes cover a single topic → propose one commit message.634. If the staged changes span multiple topics → propose a split with separate commit messages (unstaging and restaging subsets as needed).645. Present the proposal and wait for **Y** (confirm) or **N** (reject).6566### If there are NO staged changes:67681. Read all unstaged and untracked changes (`git diff` + `git status`).692. Group changes by topic into one or more commits.703. For each group, list the files and propose a commit message.714. Present the full proposal and wait for **Y** (confirm) or **N** (reject).7273### On confirm (Y):7475- Stage the relevant files and create the commit(s) in order.76- If multiple commits, execute them sequentially.7778### On reject (N):7980- Ask what to change.8182### Arguments:8384- If the user provided arguments (e.g., `/commit fix the search bug`), use that as context for the message but still verify the diff matches.858687**Last Updated**: 2026-05-25
ledtorch