git-commit

Original：🇺🇸 English

Translated

Structured git commit messages following Conventional Commits format for Go projects. Generates well-scoped, atomic commits with clear descriptions. Use when committing changes, writing commit messages, preparing PRs, or reviewing commit history quality. Trigger examples: "commit these changes", "create commit", "commit message", "prepare PR", "squash commits". Do NOT use for changelog generation (use changelog-generator) or code review (use go-code-review).

2installs

Sourceeduardo-sl/go-agent-skills

Added on2026-03-28

NPX Install

npx skill4agent add eduardo-sl/go-agent-skills git-commit

SKILL.md Content

View Translation Comparison →

Git Commit Standards

Commits tell the story of your codebase. A good commit history is worth more than any amount of documentation — because it's always up to date.

1. Conventional Commits Format

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Types:

Type	When
`feat`	New feature (correlates with MINOR in semver)
`fix`	Bug fix (correlates with PATCH in semver)
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`docs`	Documentation changes only
`chore`	Build process, tooling, dependencies
`ci`	CI/CD configuration changes
`style`	Formatting, whitespace (not CSS — code formatting)

Scope:

Use the package name or module area:

feat(auth): add JWT refresh token rotation
fix(store/postgres): handle connection pool exhaustion
refactor(service): extract validation into dedicated package
test(handler): add table-driven tests for user endpoints
chore(deps): bump go.uber.org/zap to v1.27.0

Breaking changes:

feat(api)!: change pagination from offset to cursor-based

BREAKING CHANGE: The `offset` and `limit` query parameters are replaced
by `cursor` and `page_size`. All existing clients must migrate.

2. Commit Message Rules

Subject line:

Imperative mood: "add feature", NOT "added feature" or "adds feature"
Lowercase after type prefix
No period at the end
Max 72 characters
Must describe WHAT changed, not HOW

Body (when needed):

Blank line between subject and body
Explain WHY the change was necessary
Explain WHAT is different at a high level
Wrap at 72 characters

Footer:

Reference issues:
```
Fixes #123
```
,
```
Closes #456
```
,
```
Refs #789
```
Co-authors:
```
Co-authored-by: Name <email>
```
Breaking changes:
```
BREAKING CHANGE: description
```

3. Examples

Simple change:

fix(handler): return 404 instead of 500 for missing user

With body:

refactor(service): replace manual SQL with sqlx named queries

The raw SQL string concatenation for dynamic WHERE clauses was
error-prone and difficult to maintain. sqlx named queries provide
the same flexibility with automatic parameter binding.

No behavior change — all existing tests pass.

Breaking change:

feat(config)!: migrate from YAML to environment variables

BREAKING CHANGE: Configuration is now loaded from environment
variables instead of config.yaml. See README.md for the full
list of supported variables.

Closes #234

Dependency update:

chore(deps): upgrade pgx to v5.5.0

Picks up connection pool improvements and fixes for
COPY protocol handling. See release notes:
https://github.com/jackc/pgx/releases/tag/v5.5.0

4. Atomic Commits

Each commit should be ONE logical change that:

Compiles on its own (
```
go build ./...
```
passes)
Tests pass (
```
go test ./...
```
passes)
Can be reverted independently without breaking other changes

Split large changes:

# ❌ Bad — one commit doing everything
feat(user): add user management with CRUD, validation, auth, and tests

# ✅ Good — atomic, reviewable commits
feat(domain): add User entity and validation rules
feat(store): implement PostgreSQL user repository
feat(service): add user service with create and get operations
feat(handler): add REST endpoints for user management
test(service): add table-driven tests for user creation
docs(api): document user endpoints in OpenAPI spec

5. Pre-Commit Verification

Before committing, run:

bash

# Format and lint
goimports -w .
golangci-lint run

# Build
go build ./...

# Test
go test -race ./...

# Tidy modules
go mod tidy

If any step fails, fix before committing. Never commit broken code with "will fix later" — you won't.

6. Commit Workflow

bash

# Stage specific files (not git add .)
git add internal/service/user.go
git add internal/service/user_test.go

# Review staged changes
git diff --staged

# Commit with message
git commit -m "feat(service): add user creation with email validation"

# Or use editor for longer messages
git commit  # opens $EDITOR

Interactive rebase before PR:

bash

# Clean up commit history before opening PR
git rebase -i main

# Squash fixup commits
# Reword unclear messages
# Reorder for logical flow

7. What NOT to Commit

Generated files (
```
*.pb.go
```
unless required,
```
mocks/
```
)
IDE configuration (
```
.idea/
```
,
```
.vscode/
```
— use global gitignore)
OS files (
```
.DS_Store
```
,
```
Thumbs.db
```
)
Binaries and build artifacts
```
.env
```
files with secrets
```
vendor/
```
(unless explicitly required by project policy)

git-commit

NPX Install

Tags

SKILL.md Content

Git Commit Standards

1. Conventional Commits Format

Types:

Scope:

Breaking changes:

2. Commit Message Rules

Subject line:

Body (when needed):

Footer:

3. Examples

Simple change:

With body:

Breaking change:

Dependency update:

4. Atomic Commits

Split large changes:

5. Pre-Commit Verification

6. Commit Workflow

Interactive rebase before PR:

7. What NOT to Commit