git-commit

Generate Conventional Commits messages for Go repository changes.

64|9|Updated Mar 27, 2026
One-click install
npx skills add https://github.com/eduardo-sl/go-agent-skills --skill git-commit-eduardo-sl
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: git-commit
Source: https://github.com/eduardo-sl/go-agent-skills/tree/main/skills/%28workflow%29/git-commit
Command: npx skills add https://github.com/eduardo-sl/go-agent-skills --skill git-commit-eduardo-sl

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill enforces structured, atomic git commit messages so repositories maintain a clear, navigable history and PRs contain well-scoped changes that are easy to review and revert.

Core Features & Use Cases

  • Conventional Commits Format: Guides the creation of type(scope): description subjects, optional bodies, and footers for breaking changes and issue references.
  • Atomic Commit Guidance: Encourages single-purpose commits that build and test independently and can be squashed or reordered during interactive rebases.
  • Pre-commit Workflow: Recommends verification steps such as formatting, linting, building, and testing before committing to avoid broken commits.

Quick Start

Create a Conventional Commit message for the staged Go changes that summarizes the primary change in imperative mood, includes a package scope when relevant, and adds issue references or breaking-change footers as needed.

Frequently Asked Questions about git-commit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a Conventional Commit message for my Go repository?▼

To write a Conventional Commit message, use the format type(scope): description with an imperative subject line, a body wrapped at 72 characters, and footers for issue references or breaking changes to keep Go history atomic.

What is the correct structure for conventional commit types and scopes?▼

The correct conventional commit structure uses a type like feat or fix, followed by an optional scope in parentheses, a colon, and an imperative description, optionally adding a wrapped body and footers for breaking changes or issue references.

How do I keep my git history atomic and easy to squash during an interactive rebase?▼

To keep git history atomic for interactive rebases, ensure each single-purpose commit builds and tests independently, uses imperative conventional commit subjects, and includes relevant package scopes and issue footers for easy reversion.

Do I need to run linting and tests before creating a conventional commit?▼

Yes, the pre-commit workflow recommends running formatting, linting, building, and testing before committing changes to verify they pass independently and avoid pushing broken commits into your repository history.

How do I indicate a breaking change in a conventional commit message?▼

To indicate a breaking change in a conventional commit message, add a footer starting with BREAKING CHANGE: describing the modification, or append an exclamation mark after the type and scope before the colon.

Why should I wrap my conventional commit body at 72 characters?▼

Wrapping the conventional commit body at 72 characters ensures the message displays correctly in terminal windows and git log outputs without awkward line breaks, maintaining readability for structured atomic history.