git-commits

Generate conventional commit messages with enforced format rules and pre-commit diff verification.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/zcawood-mie/agentz --skill git-commits-zcawood-mie
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-commits
Source: https://github.com/zcawood-mie/agentz/tree/main/skills/git-commits
Command: npx skills add https://github.com/zcawood-mie/agentz --skill git-commits-zcawood-mie

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Reduce unclear, messy, or unsafe commit histories by providing explicit conventions and verification steps so commits are reviewable, reversible, and informative.

Core Features & Use Cases

  • Conventional Commit Types: Guidance on feat, fix, docs, refactor, chore and when to use each.
  • Format Rules: Enforce imperative mood, 50-character subject limit, no trailing period, and wrapped body at 72 characters.
  • Atomic Commits & History Guidance: Recommend one logical change per commit, prefer many small commits, and avoid amend/squash/rebase unless the user explicitly requests it.
  • Pre-Commit Verification: Verify diffs before committing to ensure only intended changes are included and provide steps to isolate unrelated edits.
  • Use Case: When preparing a change for review, use these rules to craft a single, focused commit message that clearly describes the intent and scope of the change.

Quick Start

Create a conventional commit message for the staged changes using an appropriate conventional type, imperative mood, and a subject under 50 characters.

Frequently Asked Questions about git-commits

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

FAQPage Schema
How do I write a conventional commit message for staged git changes?

To write a conventional commit message, select an appropriate type like feat or fix, use imperative mood, keep the subject under 50 characters without a trailing period, and wrap the body at 72 characters. This ensures the commit is reviewable and informative.

What is the best way to keep git commits atomic and focused?

The best way to keep git commits atomic is to limit each commit to one logical change. You should verify diffs before committing to ensure only intended changes are included, and isolate any unrelated edits into separate commits.

When should I use amend, squash, or rebase to rewrite git history?

You should only use amend, squash, or rebase to rewrite git history when explicitly requested. By default, you should avoid rewriting history to ensure commits remain reversible and safe, preferring many small, focused commits instead.

Does the conventional commits format require a specific subject line length?

Yes, the conventional commits format requires a subject line length limit of 50 characters. It also mandates using imperative mood and prohibits adding a trailing period to the commit subject.

How do I verify git diffs before committing to avoid unintended changes?

To verify git diffs before committing, review the staged changes to ensure only intended modifications are included. If unrelated edits are present, isolate them by unstaging those specific files before finalizing the commit.

What conventional commit type should I use for documentation updates?

For documentation updates, you should use the docs conventional commit type. Other types include feat for new features, fix for bug fixes, refactor for code restructuring, and chore for maintenance tasks.