# Git Commit Helper > Creates professional, conventional commit messages following best practices. Use when committing code changes, reviewing staged files for commit message suggestions, generating changelogs, or ensuring commit history consistency across a team. - Skill: `mehdiozdemir/git-commit-helper` (Agent Skill) - Install (CLI): `npx skillmds@latest add mehdiozdemir/git-commit-helper` - Raw SKILL.md: https://api.skillmd.com/api/skills/mehdiozdemir/git-commit-helper/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: mehdiozdemir (https://skillmd.com/u/mehdiozdemir) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/mehdiozdemir/git-commit-helper --- # Git Commit Helper Skill This skill generates clear, consistent, and informative commit messages following industry standards and best practices. Use this whenever you need to commit changes, review staged files, or ensure commit history quality. ## Core Principles ### 1. **Conventional Commits Standard** Follow the [Conventional Commits](https://www.conventionalcommits.org/) specification: ``` [optional scope]: [optional body] [optional footer(s)] ``` ### 2. **Atomic Commits** - Each commit should represent ONE logical change - Changes should be self-contained and reviewable - Avoid mixing unrelated changes - Keep commits small and focused ### 3. **Clear Communication** - Messages should explain WHAT changed and WHY - Anyone reading the history should understand the change - Use imperative mood ("Add feature" not "Added feature") - Be specific, not vague ## Commit Types ### Standard Types | Type | Description | Example | |------|-------------|---------| | `feat` | New feature for the user | `feat(auth): add OAuth2 login support` | | `fix` | Bug fix | `fix(api): resolve null pointer in user lookup` | | `docs` | Documentation only | `docs(readme): update installation instructions` | | `style` | Formatting, no code change | `style(lint): apply prettier formatting` | | `refactor` | Code change without fix/feature | `refactor(utils): extract validation helpers` | | `perf` | Performance improvement | `perf(db): add index for user queries` | | `test` | Adding/updating tests | `test(auth): add unit tests for login flow` | | `build` | Build system or dependencies | `build(deps): upgrade express to v5.0` | | `ci` | CI/CD configuration | `ci(github): add automated testing workflow` | | `chore` | Other changes (no src/test) | `chore(release): bump version to 2.0.0` | | `revert` | Revert previous commit | `revert: feat(auth): add OAuth2 login support` | ### Breaking Changes Use `!` after type/scope or `BREAKING CHANGE:` in footer: ``` feat(api)!: remove deprecated v1 endpoints BREAKING CHANGE: The v1 API endpoints have been removed. Migrate to v2 endpoints as documented in the migration guide. ``` ## Commit Message Structure ### Subject Line (Required) ``` (): ``` **Rules:** - Maximum 50 characters (hard limit: 72) - Use imperative mood: "Add" not "Added" or "Adds" - No period at the end - Lowercase after the colon - Scope is optional but recommended **Good Examples:** ``` feat(auth): add password reset functionality fix(cart): prevent duplicate item additions refactor(api): extract response formatting logic docs(contributing): add pull request guidelines perf(images): implement lazy loading for gallery ``` **Bad Examples:** ``` ❌ Fixed bug (too vague) ❌ feat: Added new feature. (past tense, period) ❌ Update files (no type, vague) ❌ WIP (not descriptive) ❌ misc changes (meaningless) ``` ### Body (Optional but Recommended) Provide additional context when the subject line isn't enough: **Include:** - Motivation for the change - Contrast with previous behavior - Side effects or caveats - Reference to related issues **Format:** - Separate from subject with blank line - Wrap at 72 characters - Use bullet points for multiple items **Example:** ``` fix(auth): prevent session fixation attacks The previous implementation reused session IDs after login, making the application vulnerable to session fixation attacks. Changes: - Regenerate session ID after successful authentication - Clear old session data before creating new session - Add security headers to session cookies This follows OWASP recommendations for session management. ``` ### Footer (Optional) Use for metadata and references: **Common Patterns:** ``` Refs: #123 # References issue Closes: #456 # Closes issue on merge See-also: #789 # Related issues Co-authored-by: Name # Multiple authors Signed-off-by: Name # Developer sign-off Reviewed-by: Name # Code reviewer BREAKING CHANGE: description # Breaking change note ``` ## Scope Guidelines ### What Makes a Good Scope? - Component or module name: `auth`, `cart`, `api`, `db` - Feature area: `login`, `checkout`, `search` - File or directory: `utils`, `config`, `models` - Layer: `frontend`, `backend`, `infra` ### Scope Consistency ``` # Project-specific scopes (define in CONTRIBUTING.md) auth - Authentication and authorization api - REST/GraphQL endpoints ui - User interface components db - Database schema and queries core - Core business logic config - Configuration management deps - Dependencies ci - CI/CD pipelines docs - Documentation test - Test infrastructure ``` ## Commit Analysis Process ### Step 1: Analyze Changes When asked to create a commit message: 1. **Review staged files:** Understand what files changed 2. **Identify change type:** Is it a feature, fix, refactor, etc.? 3. **Determine scope:** Which component/module is affected? 4. **Assess impact:** Is this a breaking change? 5. **Check relationships:** Related issues or PRs? ### Step 2: Assess Commit Quality Evaluate if changes should be one or multiple commits: ``` # Single commit scenarios: ✅ One logical change across multiple files ✅ Feature with its tests ✅ Bug fix with regression test ✅ Refactor in one component # Split into multiple commits: ⚠️ Unrelated bug fixes ⚠️ Feature + unrelated refactoring ⚠️ Multiple independent features ⚠️ Formatting changes + logic changes ``` ### Step 3: Generate Message Create message following this template: ``` (): <50-char description in imperative mood>