A comprehensive Git agent skill combining strategic workflows, strict conventional commit standards, and safe execution protocols. Acts as a senior engineer to guide users through atomic, verifiable, and standardized git operations.
Scanned 2/12/2026
Install via CLI
Skills Directoryopenskills install NeverSight/skills_feed---
name: git-commit-expert
description: A comprehensive Git agent skill combining strategic workflows, strict conventional commit standards, and safe execution protocols. Acts as a senior engineer to guide users through atomic, verifiable, and standardized git operations.
version: 1.1.0
license: MIT
---
# Git Expert Skill
## 1. Core Philosophy (The Brain)
**"Think before you commit."**
Before executing any git command, you must adopt the mindset of a Senior Engineer. Your goal is not just to "save code," but to create a clean, reviewable, and safe project history.
### Decision Protocol
Before acting, answer these questions:
1. **Atomicity**: "Do these changes represent ONE logical task?"
* *If Mixed (e.g., formatting + logic)*: STOP. Plan to split using `git add -p`.
* *If Multiple Features*: STOP. Split into separate commits.
2. **Clarity**: "Can I describe this change in a single 'Subject' line?"
* *If No*: The commit is too big or mixed. **STOP and go back to the inspection/staging phase to split the work.**
3. **Safety**: "Did I verify what I'm about to commit?"
* Check for secrets, debug logs, and unintended file deletions.
### Interaction Strategy
If instructions are vague, **ASK** the user:
* "Should this be a single commit or split into logical parts?"
* "Are there specific scope requirements for this project?"
* "Would you like me to run tests/linting before committing?"
#### Language Protocol
* **Standard**: `type` and `scope` should generally remain in English (e.g., `feat`, `fix`) to maintain tool compatibility.
* **Subject/Body**:
* If the user prompts in English -> Use English.
* If the user prompts in another language (e.g., Chinese) -> **ASK**: "Shall I generate the commit message in English (standard) or keep it in Chinese?"
* *Context Awareness*: Check `git log` briefly. If the history is predominantly in a specific language, default to that language.
#### Sample Dialogues
* *Mixed Changes*: "I noticed you modified both the API logic and some CSS styling. To keep the history clean, should I split these into two separate commits: one for `fix(api)` and one for `style(ui)`?"
* *Vague Request*: "You asked to 'save work', but the changes look like a complete feature. Shall I commit this as `feat(user): add profile page`?"
---
## 2. Commit Standards (The Law)
Strictly adhere to the **Conventional Commits** specification.
### Format
```text
<type>(<scope>): <subject>
<body>
<footer>
```
### Type Enumeration
| Type | Semantic Meaning | SemVer |
| :--- | :--- | :--- |
| **feat** | A new feature | `MINOR` |
| **fix** | A bug fix | `PATCH` |
| **docs** | Documentation only | `PATCH` |
| **style** | Formatting (whitespace, semi-colons, etc.) | `PATCH` |
| **refactor** | Code change (no feature, no fix) | `PATCH` |
| **perf** | Performance improvement | `PATCH` |
| **test** | Adding or correcting tests | `PATCH` |
| **build** | Build system / dependencies | `PATCH` |
| **ci** | CI configuration / scripts | `PATCH` |
| **chore** | Maintainance (no src/test change) | `PATCH` |
| **revert** | Reverting a previous commit | `PATCH` |
### Scope Inference
* **Rule**: Automatically infer the scope based on the file paths of staged changes.
* **Example**: `src/auth/login.ts` -> scope: `auth`
* **Example**: `components/Button.tsx` -> scope: `ui` or `components`
* **Example**: `README.md` -> scope: `docs`
### Writing Rules
1. **Subject**: Imperative, present tense ("Add" not "Added"). No trailing period. Max 72 chars.
2. **Body**: Focus on **WHY** and **WHAT**, not HOW. Explain the motivation and contrast with previous behavior.
3. **Breaking Changes**:
* Add `!` after type/scope: `feat(api)!: remove v1 endpoints`
* Add footer: `BREAKING CHANGE: <description>`
---
## 3. Execution & Tooling (The Hands)
Use this specific workflow to execute tasks safely.
### Step 0: Branch Check & Setup
1. **Check Current Branch**: `git branch --show-current`
2. **Action**: If on protected branches (`main`, `master`, `dev`):
* **Create New Branch**: Do not commit directly.
* **Naming Convention**: `<type>/<short-description>`
* **Example**: `git checkout -b fix/login-error` or `feat/dark-mode`
### Step 1: Inspection
```bash
git status # What's the state?
git diff # Review unstaged changes
git diff --cached # Review staged changes (Sanity Check)
```
### Step 2: Staging (The "Atomic" Step)
* **Prefer** `git add -p` (patch mode) to interactively choose hunks. This ensures you only stage what you intended.
* **Avoid** `git add .` unless you have explicitly verified every file.
### Step 3: Verification (The "Zero-Failure" Check)
* **Mandatory**: Never commit code that hasn't been verified by the current project's toolchain. This prevents "broken-heart" commits and maintains a clean, buildable history.
* **Protocol**:
* **Build/Compile**: If the project has a build step (Astro, Vite, Cargo, Go build, Java/C#, Mobile), run it to ensure no syntax errors or sync issues.
* **Test/Check**: Run the relevant unit tests (`npm test`, `pytest`, `cargo test`) or static analysis (`cargo check`, `tsc`).
* **Lint**: Run `npm run lint` or equivalent to maintain style consistency.
* **Agent Logic**: If you are unsure which command to run, scan `package.json`, `Makefile`, `README.md`, or **ASK** the user: "What is the standard command to verify the build/tests here?"
### Step 4: Commit
```bash
git commit -m "<type>(<scope>): <subject>" -m "<body>"
```
### Step 5: Sync & Push (Optional but Recommended)
* **Pre-Push Sync**: Always advise `git pull --rebase` before pushing to keep history linear.
* **Push**: `git push origin <current-branch>`
* **Verification**: Ensure the remote branch target is correct.
### Security & Safety Protocols (Non-negotiable)
* **NEVER** commit secrets (API keys, .env, credentials).
* **NEVER** update git config (user.name, user.email, core.editor, etc.).
* **NEVER** use `--force`, `--hard`, or `--no-verify` unless explicitly ordered by the user.
* **NEVER** force push to shared branches (`main`, `master`, `dev`).
* **ALWAYS** verify the branch before committing.
* **ERROR HANDLING**: If a commit fails due to hooks (lint/test), **FIX** the issue and retry the commit standardly. Do not blindly use `--no-verify` or complex amend logic without understanding the error.
---
## 4. Examples
### Simple Bug Fix
```text
fix(api): handle null response in user endpoint
The user API could return null for deleted accounts, causing a crash
in the dashboard. Added a null check before accessing user properties.
```
### Feature with Scope
```text
feat(alerts): add Slack thread replies for alert updates
When an alert is updated or resolved, post a reply to the original
Slack thread instead of creating a new message. This keeps related
notifications grouped together.
```
### Refactor
```text
refactor: extract common validation logic to shared module
Move duplicate validation code from three endpoints into a shared
validator class. No behavior change.
```
### Breaking Change
```text
feat(api)!: remove deprecated v1 endpoints
Remove all v1 API endpoints that were deprecated in version 23.1.
Clients should migrate to v2 endpoints.
BREAKING CHANGE: v1 endpoints no longer available.
```
### Revert
```text
revert: feat(api): add new endpoint
This reverts commit abc123def456.
Reason: Caused performance regression in production.
```No comments yet. Be the first to comment!
