---
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.
```

---
Source attribution: NeverSight
Original project: https://github.com/NeverSight/skills_feed/blob/main/data/skills-md/chiperman/agent-skills/git-commit-expert/SKILL.md
License: MIT
License information: https://opensource.org/license/mit
Original upstream instructions; downloaded from Dave AI.

## Upstream license notice

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.



# Dave AI resource metadata

Creator / publisher: NeverSight
Original project: https://github.com/NeverSight/skills_feed/blob/main/data/skills-md/chiperman/agent-skills/git-commit-expert/SKILL.md
Attribution basis: Source repository record

Fields of work: Development & Engineering, Sales
Roles: Backend Developer, Frontend Developer, QA / Test Engineer, Sales Engineer, Sales Development Rep (SDR)
Specialties: Git
Tools: Tool not specified
Country applicability: Country not specified
Classification basis: Source catalog labels
Instruction SHA-256: 6d57ac04f126af8d3fb333b96b2617063997988bfc5589d34a14a9c01dde33f7