Git Commit

Name: Git Commit
Author: dauquangthanh

dauquangthanh/hanoi-rainbow

23 installs
14 repo stars
Updated January 23, 2026
dauquangthanh/hanoi-rainbow

git-commit is a Hanoi Rainbow agent skill that generates conventional git commit messages so developers can keep atomic, descriptive version history.

About

The git-commit skill teaches agents to write conventional commit messages with clear types, optional scopes, imperative subjects, and detailed bodies when changes need context. It emphasizes atomic commits, automation-friendly prefixes, and footers for breaking changes and issue links. Use it whenever you or an agent are about to commit and want messages that match team standards and changelog tooling instead of vague one-liners.

Enforces type, scope, subject, body, and footer structure
Documents feat, fix, docs, refactor, test, ci, and chore types
Loads reference guides for templates, mistakes, and team conventions
Supports breaking-change footers and issue references like Closes #123

Git Commit by the numbers

23 all-time installs (skills.sh)
Ranked #377 of 733 Git & Pull Requests skills by installs in the Skillselion catalog
Data as of Jul 29, 2026 (Skillselion catalog sync)

npx skills add https://github.com/dauquangthanh/hanoi-rainbow --skill git-commit

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/dauquangthanh/hanoi-rainbow/git-commit.svg)](https://skillselion.com/skills/dauquangthanh/hanoi-rainbow/git-commit)

Installs	23
repo stars	★ 14
Last updated	January 23, 2026
Repository	dauquangthanh/hanoi-rainbow ↗

How should this change be committed so the message is clear, conventional, and safe for automation?

Drafts conventional commit messages with typed prefixes, scoped subjects, bodies, and footers so staged changes are atomic and changelog-friendly.

Who is it for?

Developers and agents committing incremental code changes who want Conventional Commits formatting without guessing types or footers.

Skip if: Repositories that forbid conventional commits or tasks that only need branch strategy without writing a message.

When should I use this skill?

Users ask to commit, write a commit message, or mention conventional commits or changelog formatting.

What you get

A ready-to-use commit message with type, scope, subject, optional body, and footers matching the skill format.

Files

SKILL.mdMarkdownGitHub ↗

Git Commit

Generates well-structured git commit messages following conventional commit standards and best practices.

Key Principles

1. Be specific: Describe exactly what changed 2. Be consistent: Follow conventional commit format 3. Be atomic: One logical change per commit 4. Be clear: Write for others (including future you) 5. Be complete: Include why and context when needed 6. Be conventional: Follow standard format for automation

Standard Format

<type>(<scope>): <subject>

<body>

<footer>

Components:

type: Category of change (required) - feat, fix, docs, refactor, perf, test, build, ci, chore, style, revert
scope: Area affected (optional) - auth, api, ui, db, etc.
subject: Brief description (required, ≤50 chars)
body: Detailed explanation (optional, wrap at 72 chars)
footer: Breaking changes, issue refs (optional)

Basic Workflow

1. Choose the commit type:

feat: New user-facing functionality
fix: Bug fix for users
docs: Documentation only
refactor: Code restructuring without behavior change
perf: Performance improvement
test: Adding/updating tests
build: Dependency/build system changes
ci: CI/CD configuration changes
chore: Maintenance tasks
style: Code formatting
revert: Reverting previous commit

2. Write subject line (imperative mood, ≤50 chars):

   ✅ feat(auth): add OAuth2 authentication
   ✅ fix(api): resolve race condition in user updates
   ❌ feat: added some stuff
   ❌ fix: bug fix

3. Add body if needed (explain why, not just what):

Required for breaking changes
Recommended for complex changes
Wrap lines at 72 characters

4. Include footer:

Breaking changes: BREAKING CHANGE: description
Issue references: Closes #123, Fixes #456

Quick Examples

Simple feature:

feat(auth): add password reset endpoint

Bug fix with context:

fix(api): prevent null pointer in user preferences

User preferences API crashed when optional fields were null.
Added null checks and default values.

Closes #456

Breaking change:

feat(api)!: change response format to JSON:API spec

BREAKING CHANGE: API responses now follow JSON:API format.
Update client code to parse data from `data` key instead
of root level.

Closes #789

Reference Documentation

For detailed guidance, load these reference files as needed:

[commit-types.md](references/commit-types.md): Complete list of commit types with examples
[quick-reference.md](references/quick-reference.md): Decision trees and checklists
[best-practices.md](references/best-practices.md): Atomic commits, meaningful messages, issue references
[writing-guidelines.md](references/writing-guidelines.md): Subject line rules, scope selection, body formatting
[common-scenarios.md](references/common-scenarios.md): Examples for typical development situations
[common-mistakes-to-avoid.md](references/common-mistakes-to-avoid.md): Anti-patterns and how to fix them
[team-conventions.md](references/team-conventions.md): Customizing conventions for teams
[commit-message-structure.md](references/commit-message-structure.md): Detailed format specifications
[commit-message-templates.md](references/commit-message-templates.md): Ready-to-use templates
[commit-workflow.md](references/commit-workflow.md): Integration with git workflows
[examples-by-project-type.md](references/examples-by-project-type.md): Examples for web apps, libraries, mobile, microservices
[advanced-patterns.md](references/advanced-patterns.md): Complex scenarios and edge cases
[commit-message-convention.md](references/commit-message-convention.md): Enforcement tools and configurations

Advanced Patterns

Co-authored Commits

For pair programming:

feat(payment): implement Stripe integration

Co-authored-by: Jane Doe <jane@example.com>
Co-authored-by: John Smith <john@example.com>

Signed Commits

For verified commits:

git commit -S -m "feat(auth): add 2FA support"

Message includes:

feat(auth): add 2FA support

Signed-off-by: Developer Name <dev@example.com>

Fixup and Squash

For cleaner history:

git commit --fixup=<commit-hash>   # Mark as fixup
git rebase -i --autosquash         # Squash fixups

Best Practices

Atomic Commits

DO: One logical change per commit

✅ Commit 1: feat(auth): add login endpoint
✅ Commit 2: feat(auth): add registration endpoint
✅ Commit 3: test(auth): add authentication tests

DON'T: Multiple unrelated changes

❌ Commit: feat(auth): add login, fix button styling, update docs, refactor utils

Meaningful Messages

DO: Describe what and why

✅ fix(api): handle null values in user preferences

User preferences API crashed when optional fields were null.
Added null checks and default values.

DON'T: Vague descriptions

❌ fix: bug fix
❌ update: changes
❌ misc: various updates

Present Tense, Imperative Mood

DO:

✅ add feature
✅ fix bug
✅ update documentation
✅ remove deprecated code

DON'T:

❌ added feature
❌ fixing bug
❌ updated documentation
❌ removes deprecated code

Reference Issues

Always link to issue tracker:

Closes #123
Fixes #456
Resolves #789
Related to #234

Breaking Changes Visibility

Use exclamation mark for breaking changes:

feat(api)!: change authentication method

BREAKING CHANGE: detailed description

Or in footer:

feat(api): change authentication method

BREAKING CHANGE: detailed description

Commit Message Convention

All commits must follow conventional commit format:

Required Types: feat, fix, docs, refactor, test, chore Optional Scopes: frontend, backend, api, db, auth, ui Subject Length: Maximum 50 characters Body: Required for breaking changes and complex fixes Footer: Must reference issue number when applicable


## Enforce with Tools

**commitlint:**

{ "extends": ["@commitlint/config-conventional"], "rules": { "type-enum": [2, "always", [ "feat", "fix", "docs", "refactor", "test", "chore", "perf", "ci", "build" ]], "subject-max-length": [2, "always", 50], "scope-enum": [2, "always", [ "auth", "api", "ui", "db", "config" ]] } }


**Git hooks (husky):**

{ "husky": { "hooks": { "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" } } }

Commit Message Structure

Basic Format

<type>(<scope>): <subject>

<body>

<footer>

Components:

type: Category of change (required)
scope: Area affected (optional)
subject: Brief description (required, ≤50 chars)
body: Detailed explanation (optional, wrap at 72 chars)
footer: Breaking changes, issue refs (optional)

Commit Message Templates

Template Setup

Create .gitmessage template:

# <type>(<scope>): <subject> (max 50 chars)

# Why is this change necessary?


# How does it address the issue?


# What side effects does this change have?


# Issue references (Closes #123, Fixes #456):

Configure git to use template:

git config --global commit.template ~/.gitmessage

Commit Types

Primary Types

feat: New feature for users

feat(auth): add OAuth2 authentication
feat(api): implement user profile endpoint
feat: add dark mode toggle

fix: Bug fix for users

fix(login): resolve session timeout issue
fix(api): handle null response from database
fix: prevent memory leak in image processing

docs: Documentation changes

docs(readme): update installation instructions
docs(api): add authentication examples
docs: fix typos in contributing guide

refactor: Code changes that neither fix bugs nor add features

refactor(auth): simplify token validation logic
refactor(db): extract query builder to separate module
refactor: convert callbacks to async/await

perf: Performance improvements

perf(search): optimize query with database indexing
perf(render): reduce component re-renders with memoization
perf: implement lazy loading for images

test: Adding or updating tests

test(auth): add unit tests for login flow
test(api): increase coverage for error scenarios
test: add integration tests for checkout process

build: Changes to build system or dependencies

build(deps): upgrade react to v18.2.0
build(webpack): optimize bundle size configuration
build: add npm script for production build

ci: Changes to CI/CD configuration

ci(github): add automated testing workflow
ci(deploy): configure staging environment
ci: update deployment pipeline timeout

chore: Other changes that don't modify src or test files

chore(deps): update development dependencies
chore: remove unused configuration files
chore(release): bump version to 2.1.0

style: Code style changes (formatting, missing semicolons, etc.)

style(eslint): fix linting errors
style: format code with prettier
style(css): organize stylesheet properties

revert: Reverting a previous commit

revert: revert "feat(api): add user endpoint"

This reverts commit abc123def456

Commit Workflow

1. Review Changes

Before committing, understand what changed:

git status          # See modified files
git diff            # See specific changes
git diff --staged   # See staged changes

2. Stage Appropriately

Create atomic commits (one logical change per commit):

git add <specific-files>        # Stage specific files
git add -p                      # Stage specific hunks interactively

3. Generate Message

For simple changes:

git commit -m "type(scope): subject"

For complex changes:

git commit
# Opens editor for multi-line message

4. Verify Message

Check commit before pushing:

git log -1          # View last commit
git show            # View last commit with diff
git commit --amend  # Modify last commit message

Common Mistakes to Avoid

Vague Messages

❌ fix: fixed issue
❌ update: updates
❌ changes
❌ WIP
❌ asdf

Too Much Detail in Subject

❌ feat(auth): add new authentication system with OAuth2, JWT tokens, refresh token rotation, and password hashing

Better:

✅ feat(auth): implement OAuth2 authentication

- Add JWT token generation and validation
- Implement refresh token rotation
- Upgrade password hashing to bcrypt

Missing Context

❌ fix(api): fix bug

Better:

✅ fix(api): prevent null pointer in user lookup

API crashed when querying users with deleted accounts.
Added null check and return 404 for deleted users.

Fixes #456

Multiple Unrelated Changes

❌ feat: add login, update button styles, fix typo, refactor utils

Better: Split into 4 separate commits

Wrong Tense/Mood

❌ fixed the login bug
❌ adding new feature
❌ updated documentation

Better:

✅ fix(auth): resolve login bug
✅ feat(api): add new endpoint
✅ docs(readme): update installation guide

Common Scenarios

Feature Addition

feat(checkout): add coupon code validation

- Implement coupon validation API endpoint
- Add coupon input field to checkout form
- Display discount amount in order summary
- Handle expired and invalid coupon errors

Closes #234

Bug Fix

fix(payment): resolve duplicate charge issue

Race condition in payment processing caused some
transactions to be charged twice. Added transaction
locking to prevent concurrent processing of same order.

- Add distributed lock with 30s timeout
- Implement idempotency key validation
- Add retry logic for lock acquisition failures

Fixes #567

Refactoring

refactor(user): extract validation to separate module

Move user validation logic from controller to dedicated
validator class for better testability and reuse.

- Create UserValidator class
- Move validation rules from UserController
- Add comprehensive validation tests
- Update documentation

Documentation

docs(api): add authentication flow examples

Add code examples showing:
- OAuth2 authorization flow
- JWT token refresh process
- Error handling patterns

Related to #123

Performance Improvement

perf(search): implement query result caching

Add Redis caching layer for search queries to reduce
database load and improve response times.

Results:
- Average response time: 450ms → 45ms
- Database queries reduced by 80%
- Cache hit rate: 92%

Closes #789

Breaking Change

feat(api)!: migrate to GraphQL schema v2

BREAKING CHANGE: GraphQL schema updated to v2 with
field naming changes and deprecated field removals.

Changes:
- Rename `userId` to `id` in User type
- Remove deprecated `fullName` field (use `firstName` + `lastName`)
- Change `createdAt` format to ISO 8601

Migration guide: docs/migration/v1-to-v2.md

Closes #456

Multiple Related Changes

refactor(auth): modernize authentication system

Comprehensive authentication refactor including:

- Replace session-based auth with JWT tokens
- Implement refresh token rotation
- Add OAuth2 provider support (Google, GitHub)
- Migrate password hashing to bcrypt
- Update security headers and CORS config

This improves security, performance, and enables SSO.
Session data migration script provided in scripts/migrate-sessions.js

Closes #234, #567, #890

Examples by Project Type

Web Application

feat(dashboard): add real-time analytics widget
fix(auth): resolve session expiry notification
refactor(api): simplify error handling middleware
perf(search): optimize full-text search queries
docs(readme): add deployment instructions

Library/Package

feat(core): add async/await support
fix(parser): handle malformed JSON gracefully
refactor(types): improve TypeScript definitions
test(utils): increase coverage to 95%
build(deps): update peer dependencies

Mobile App

feat(ios): implement biometric authentication
fix(android): resolve crash on API 29+
perf(ui): optimize list rendering performance
refactor(navigation): migrate to React Navigation v6
ci(fastlane): automate beta deployment

Microservices

feat(user-service): add email verification
fix(payment-service): handle webhook retries
refactor(gateway): extract rate limiting logic
perf(db): add indexes for common queries
ci(k8s): update deployment manifests

---

Quick Reference

Type Decision Tree

Does it add new user-facing functionality? → feat
Does it fix a user-facing bug? → fix
Is it only documentation? → docs
Does it change code structure without changing behavior? → refactor
Does it improve performance? → perf
Is it adding/updating tests? → test
Is it dependency/build/CI related? → build/ci/chore
Is it code formatting/style? → style
Are you reverting a commit? → revert

Subject Line Checklist

[ ] Type and optional scope present: type(scope):
[ ] Imperative mood: "add" not "added"
[ ] Under 50 characters
[ ] No period at end
[ ] Describes what the commit does
[ ] Specific and meaningful

Body Checklist

[ ] Blank line after subject
[ ] Explains "why" not just "what"
[ ] Lines wrapped at 72 characters
[ ] Bullets or paragraphs for multiple points
[ ] Blank line before footer

Footer Checklist

[ ] Breaking changes clearly marked
[ ] Issue references included
[ ] Co-author credits if applicable

Team Conventions

Establish Project Standards

Document in CONTRIBUTING.md:

Required commit types
Scope naming conventions
When to include body
Issue reference format
Breaking change policy

Example Team Convention

Writing Guidelines

Subject Line Rules

DO:

✅ Use imperative mood: "add" not "added" or "adds"
✅ Keep under 50 characters
✅ Don't end with period
✅ Capitalize first letter after type/scope
✅ Be specific and descriptive

Examples:

✅ feat(auth): add password reset functionality
✅ fix(api): resolve race condition in user updates
✅ refactor(db): simplify connection pooling logic

DON'T:

❌ feat: added stuff
❌ fix: fixes
❌ update: updated some files
❌ misc changes
❌ WIP

Scope Selection

Common Scopes by Project Type:

Web Application:

auth, api, ui, db, config, router, state, validation

Library/SDK:

core, utils, types, docs, examples, tests

Mobile App:

ios, android, ui, navigation, storage, network

Microservices:

user-service, payment-service, gateway, auth, logging

Omit scope when change affects multiple areas or entire project.

Body Content

When to include a body:

Change requires explanation
Multiple related changes
Context about "why" not obvious
Breaking changes need documentation
Complex bug fixes

Body Format:

<type>(<scope>): <subject>
[blank line]
- Explain what changed
- Explain why it changed
- Reference relevant context
- Note any side effects
[blank line]
<footer>

Example:

fix(auth): prevent token expiry race condition

- Add mutex lock around token refresh operations
- Implement exponential backoff for retry attempts
- Update token validation to check expiry before use

This fixes an issue where concurrent requests could cause
multiple token refresh attempts, leading to authentication
failures.

Closes #456

Footer Usage

Breaking Changes:

feat(api): change response format to JSON:API spec

BREAKING CHANGE: API responses now follow JSON:API format.
Update client code to parse data from `data` key instead
of root level. See migration guide in docs/MIGRATION.md

Issue References:

Closes #123
Fixes #456, #789
Resolves #234
Related to #567

Multiple References:

This change affects multiple systems and resolves several issues.

Closes #123, #456
Related to #789
See also: #234

Related skills

Caveman CommitGenerate terse, Conventional Commits messages that preserve intent without fluff or AI attribution.272k94k

Resolving Merge ConflictsQuickly understand, resolve, and commit merge conflicts without losing work or breaking their flow.183k193k

Git Guardrails Claude CodePrevent Claude Code from accidentally running destructive git commands like force push, hard reset, or clean.175k193k

Using Git WorktreesGuarantee every new feature or implementation task runs inside a clean, isolated workspace without polluting the main branch or current working directory.149k263k

Git CommitGenerate accurate conventional commit messages and intelligently stage files directly from natural language requests.40.6k37.2k

Resolve Merge ConflictsQuickly understand and resolve Git merge conflicts without losing context or breaking changes.16.5k148

FAQ

What commit format does it use?

It uses type(scope): subject with optional body and footer sections as documented in the skill.

Which types are supported?

It lists feat, fix, docs, refactor, perf, test, build, ci, chore, style, and revert in the basic workflow.

Where is deeper guidance?

The skill points to references such as commit-types.md, best-practices.md, and commit-workflow.md.

Git & Pull Requestsgit

About

Git Commit by the numbers

Add your badge

How should this change be committed so the message is clear, conventional, and safe for automation?

Who is it for?

When should I use this skill?

What you get

Files

Git Commit

Key Principles

Standard Format

Basic Workflow

Quick Examples

Reference Documentation

Advanced Patterns

Co-authored Commits

Signed Commits

Fixup and Squash

Best Practices

Atomic Commits

Meaningful Messages

Present Tense, Imperative Mood

Reference Issues

Breaking Changes Visibility

Commit Message Convention

Commit Message Structure

Basic Format

Commit Message Templates

Template Setup

Commit Types

Primary Types

Commit Workflow

1. Review Changes

2. Stage Appropriately

3. Generate Message

4. Verify Message

Common Mistakes to Avoid

Vague Messages

Too Much Detail in Subject

Missing Context

Multiple Unrelated Changes

Wrong Tense/Mood

Common Scenarios

Feature Addition

Bug Fix

Refactoring

Documentation

Performance Improvement

Breaking Change

Multiple Related Changes

Examples by Project Type

Web Application

Library/Package

Mobile App

Microservices

Quick Reference

Type Decision Tree

Subject Line Checklist

Body Checklist

Footer Checklist

Team Conventions

Establish Project Standards

Example Team Convention

Writing Guidelines

Subject Line Rules

Scope Selection

Body Content

Footer Usage

Related skills

FAQ

What commit format does it use?

Which types are supported?

Where is deeper guidance?

This week in AI coding