git-commit

Create conventional git commits with atomic scope and pre-commit verification.

Updated Oct 11, 2025
One-click install
npx skills add https://github.com/tnez/docent --skill git-commit-tnez
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-commit
Source: https://github.com/tnez/docent/tree/main/skills/git/git-commit
Command: npx skills add https://github.com/tnez/docent --skill git-commit-tnez

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires git cli.

What problem does it solve?

Inconsistent, poorly structured Git commits hinder code review, debugging, and project history analysis. This Skill guides you through creating professional, atomic Git commits that adhere to conventional commit standards, ensuring a clean, understandable, and easily revertible project history.

Core Features & Use Cases

  • Commit Strategy Guidance: Helps determine whether to create single or multiple commits based on logical units of work.
  • Conventional Commit Formatting: Ensures commit messages follow type(scope): description format with clear body and footers.
  • Staging & Exclusion: Guides on staging relevant files and excluding temporary or debug code.
  • Pre-Commit Verification: Provides a checklist to ensure quality before finalizing the commit.
  • Use Case: You've made several changes across different files. Use this Skill to systematically stage your changes, craft a conventional commit message that explains the "why," and verify everything before committing, ensuring your contribution is clear and professional.

Quick Start

Help me create a professional git commit for my staged changes.

Frequently Asked Questions about git-commit

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

FAQPage Schema
How do I write conventional commits that follow a standard format?

Conventional commits use the format `type(scope): description` where type specifies the change category (feat, fix, docs, etc.), scope narrows the affected area, and description explains the change in imperative mood. This standardized structure makes commit history readable and enables automated tooling for versioning and changelog generation.

What's the best way to organize multiple changes into separate git commits?

Organize changes by logical units of work, creating atomic commits where each one addresses a single concern and remains independently testable. Stage relevant files for each logical unit, craft a conventional commit message explaining the "why," then verify before committing to keep history clean and reversible.

How do I ensure my git commits are production-ready before pushing?

Pre-commit verification involves checking that staged changes align with project conventions, commit messages follow the required format, temporary or debug code is excluded, and each commit is independently buildable. Running pre-commit hooks automates these checks to catch issues before they enter the repository.

Can I use conventional commits with existing git repositories?

Yes, conventional commits apply to any Git repository regardless of size or age. You can adopt the format immediately for new commits while leaving existing history unchanged, then optionally rewrite older commits using interactive rebase if your team standardizes on the format.

What's the difference between commit body and footer in conventional commit messages?

The body provides detailed explanation of the change and its rationale, written in imperative style. Footers reference related issues, breaking changes, or other metadata using key-value syntax (e.g., `Closes #123`, `BREAKING CHANGE: description`), keeping commit messages structured and machine-parseable.