eduardo-sleduardo-sl/go-agent-skills/skills/(workflow)/git-commit/SKILL.md

git-commit

Skill85 starsChanged 18 days agoMITView on GitHub

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". Not for: code review (go-code-review), changelog generation.

Reads credentials

We split this skill into the rules it gives an agent

4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.

0
Common
Most of the 126 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Use the package name or module area:
line 54
Distinctive:
No period at the end
line 78
Distinctive:
Must describe WHAT changed, not HOW
line 80
Distinctive:
If any step fails, fix before committing.
line 176

“Common” is measured: kept by at least 6 in 10 of the 126 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

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.

Community default. A project skill or agent-config rule that explicitly supersedes git-commit takes precedence over this one.

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:

# 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

# 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:

Interactive rebase opens $EDITOR, so an agent cannot drive it. Prepare fixups non-interactively, then hand the final step to the developer:

# Mark a commit as a fixup of an earlier one (no editor)
git commit --fixup <sha>

# Collapse them automatically (no editor with --autosquash + GIT_SEQUENCE_EDITOR)
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash main

For reordering or rewording, tell the developer to run git rebase -i main themselves rather than attempting it.

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)

Download now (ZIP)

Other versions164 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 164
github/awesome-copilot★ 41ksame name
doocs/leetcode★ 37ksame name
tisfeng/Easydict★ 15ksame name
doocs/md★ 13ksame name
spinabot/brigade★ 11ksame name
GitTools/GitVersion★ 3.1ksame name
igorescodro/alkaa★ 1.6ksame name
microsoft/hve-core★ 1.6ksame name
mattmireles/gemma-tuner-multimodal★ 1.5ksame name
rohaquinlop/complexipy★ 898same name
154 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use git-pr, github-pr-create and 10 more.
Other files people use alongside this one.
- klauswgSkill
  git-pr
  Prepare, review, publish, or update a complete GitHub pull request for the current repository, including local commit readiness, safe push strategy, semantic title validation, repository-native PR templates, issue linking, and checks verification. Use when the user asks to draft, create, submit, publish, open, or update a pull request. Always require the user to review and explicitly approve the exact final PR before any push or GitHub write.
  Also in 9 projects that use this
- mjun0812Skill
  github-pr-create
  Pull Requestを作成するSkill。現在のbranchからpull requestを作成する。言語指定可能。ユーザーが「PR作って」「pull request作成して」のように依頼したら使うこと。
  Also in 3 projects that use this
- MicrosoftSkill
  git-branch
  Branch management for implementation. Use when you need to create a branch, switch branches, checkout, or verify branching strategy before implementing code. Do not use for commits (use git-commit), pull requests (use pull-request), or advanced git operations (rebase, merge).
  Also in 4 projects that use this
- klauswgSkill
  git-issue
  Prepare, review, create, or update evidence-based GitHub issues for the current repository with duplicate detection, repository-native templates, valid labels, and post-publication verification. Use when the user asks to draft, file, submit, publish, edit, or refine a GitHub issue, bug report, feature request, performance issue, or technical proposal. Always require the user to review and explicitly approve the exact final issue before any GitHub write.
  Also in 3 projects that use this
- gologo13Skill
  git-push
  Push current branch to origin and sync with remote updates; keywords: git, rebase. Use only on explicit request; before execution, review diffs and list impact scope.
  Also in 6 projects that use this
- GoogleSkill
  github-pr-review
  Review a GitHub pull request and leave inline comments in a natural human reviewing voice, indistinguishable from comments typed by hand on the GitHub web UI. Deliberately bounded to defects a reader can settle by looking at the anchored line, rather than a deep audit, so every comment is cheap for the author to check. Scales to 2-20 comments by PR size, parallelises analysis across sub-agents, drafts for approval, then posts individually with human pacing. Use when the user says "review this PR", "review PR 123", pastes a github.com/.../pull/N link, or asks for comments on a pull request. Don't use for reviewing local uncommitted changes or a diff against a branch (use the `review` skill for that).
  Also in 4 projects that use this
In this repository38 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/go-skills.mdcCursor rule
- go-api-designSkill
- go-architecture-reviewSkill
- go-cliSkill
- go-dependency-injectionSkill
- go-design-patternsSkill
- go-graphqlSkill
- go-grpcSkill
- go-interface-designSkill
- go-openapiSkill
- go-project-layoutSkill
- go-code-reviewSkill
- go-coding-standardsSkill
- go-contextSkill
- go-data-structuresSkill
- go-documentationSkill
- go-error-handlingSkill
- go-modernizeSkill
- go-namingSkill
- go-databaseSkill
- go-concurrency-reviewSkill
- go-defensive-codingSkill
- go-observabilitySkill
- go-performance-reviewSkill
- go-security-auditSkill
- go-troubleshootingSkill
- go-test-qualitySkill
- go-test-table-drivenSkill
- go-binary-sizeSkill
- go-build-releaseSkill
- go-ciSkill
- go-dependency-auditSkill
- go-refactoringSkill
- go-semantic-toolsSkill
- go-skills-routerSkill

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free