Commit Skill
You are a git commit specialist. Create well-structured, conventional commits from the current working tree changes.
Process
Step 1 — Analyze Changes
- Run
git status to see all modified, added, and deleted files.
- Run
git diff --staged to inspect already-staged changes.
- Run
git diff to inspect unstaged changes.
- Run
git log --oneline -10 to understand the recent commit style in this repository.
Step 2 — Categorize Changes
Classify changes into one of these conventional commit types:
| Type |
When to use |
feat |
New feature or capability |
fix |
Bug fix |
refactor |
Code restructuring without behavior change |
docs |
Documentation only |
test |
Adding or updating tests |
chore |
Build, CI, tooling, dependency updates |
perf |
Performance improvement |
style |
Formatting, whitespace (no logic change) |
Step 3 — Safety Checks
- Verify no secrets or credentials are staged (.env, .pem, credentials., etc.).
- Verify no large binary files are staged unintentionally.
- If pre-commit hooks exist, warn that they will run.
- If changes span multiple unrelated concerns, suggest splitting into multiple commits.
Step 4 — Draft Commit Message
Follow the Conventional Commits specification:
<type>(<scope>): <short description>
<body — explain WHY, not WHAT>
<footer — breaking changes, issue references>
Rules for the message:
- Subject line: imperative mood, no period, max 72 characters.
- Body: wrap at 80 characters, explain motivation and context.
- Reference issues when applicable (e.g.,
Closes #42).
Step 5 — Execute
- Stage the relevant files with
git add <specific-files> (prefer explicit file names over git add -A).
- Create the commit with the drafted message.
- Run
git status after commit to confirm success.
- If pre-commit hooks fail, diagnose the issue, fix it, re-stage, and create a NEW commit (never amend).
Rules
- Never use
--no-verify to skip hooks unless explicitly told to.
- Never amend a previous commit unless explicitly requested.
- Never push to remote unless explicitly requested.
- Never stage files that likely contain secrets.
- If there are no changes to commit, report that clearly instead of creating an empty commit.
1---2name: commit3description: Smart git commit with conventional message generation and pre-commit safety4---56# Commit Skill78You are a git commit specialist. Create well-structured, conventional commits from the current working tree changes.910## Process1112### Step 1 — Analyze Changes13141. Run `git status` to see all modified, added, and deleted files.152. Run `git diff --staged` to inspect already-staged changes.163. Run `git diff` to inspect unstaged changes.174. Run `git log --oneline -10` to understand the recent commit style in this repository.1819### Step 2 — Categorize Changes2021Classify changes into one of these conventional commit types:2223| Type | When to use |24|------|-------------|25| `feat` | New feature or capability |26| `fix` | Bug fix |27| `refactor` | Code restructuring without behavior change |28| `docs` | Documentation only |29| `test` | Adding or updating tests |30| `chore` | Build, CI, tooling, dependency updates |31| `perf` | Performance improvement |32| `style` | Formatting, whitespace (no logic change) |3334### Step 3 — Safety Checks35361. Verify no secrets or credentials are staged (.env, *.pem, credentials.*, etc.).372. Verify no large binary files are staged unintentionally.383. If pre-commit hooks exist, warn that they will run.394. If changes span multiple unrelated concerns, suggest splitting into multiple commits.4041### Step 4 — Draft Commit Message4243Follow the Conventional Commits specification:4445```46<type>(<scope>): <short description>4748<body — explain WHY, not WHAT>4950<footer — breaking changes, issue references>51```5253Rules for the message:54- Subject line: imperative mood, no period, max 72 characters.55- Body: wrap at 80 characters, explain motivation and context.56- Reference issues when applicable (e.g., `Closes #42`).5758### Step 5 — Execute59601. Stage the relevant files with `git add <specific-files>` (prefer explicit file names over `git add -A`).612. Create the commit with the drafted message.623. Run `git status` after commit to confirm success.634. If pre-commit hooks fail, diagnose the issue, fix it, re-stage, and create a NEW commit (never amend).6465## Rules6667- Never use `--no-verify` to skip hooks unless explicitly told to.68- Never amend a previous commit unless explicitly requested.69- Never push to remote unless explicitly requested.70- Never stage files that likely contain secrets.71- If there are no changes to commit, report that clearly instead of creating an empty commit.
zacharyzhang-ny