git-commit-best-practices

Enforces conventional commit message conventions and structured git commit workflows.

5|Updated Feb 2, 2026
One-click install
npx skills add https://github.com/sergiodxa/monorepo --skill git-commit-best-practices-sergiodxa
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: git-commit-best-practices
Source: https://github.com/sergiodxa/monorepo/tree/main/.agents/skills/git-commit-best-practices
Command: npx skills add https://github.com/sergiodxa/monorepo --skill git-commit-best-practices-sergiodxa

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Inconsistent commit messages and sloppy staging habits make git history hard to review, break changelog automation, and let unrelated changes slip into single commits. This Skill standardizes how commits are created, staged, and verified. ## Core Features & Use Cases - Conventional Commits Enforcement: Applies the <type>(<scope>): <description> format with correct type prefixes (feat, fix, docs, refactor, test, chore, style, perf) and monorepo-aware scope selection from package names. - Workflow Guardrails: Requires running git status and git diff --staged before committing, staging files selectively, and verifying results after each commit. - Hook Safety: Prohibits --no-verify and --no-gpg-sign unless explicitly requested, and defines how to handle hook failures and auto-formatting with follow-up commits. - Use Case: When finishing a feature in a monorepo package, the Skill guides staging only the related files, writing a message like feat(packages/auth): add token refresh to prevent session expiry, and verifying the commit succeeded. ## Quick Start Review my staged changes and create a commit that follows this repository's conventional commit conventions.

Frequently Asked Questions about git-commit-best-practices

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

FAQPage Schema
How do I write a conventional commit message?▼

Use the format `<type>(<scope>): <description>` with a type like feat, fix, docs, refactor, test, chore, style, or perf. Start the description lowercase, use imperative mood, keep it under 72 characters, and omit the trailing period.

How do I choose the right commit type prefix?▼

Match the prefix to the actual change: feat for new functionality, fix for bug corrections, perf for performance improvements, refactor for restructuring without behavior change, docs for documentation only, test for tests only, and chore for dependencies or tooling.

When should I omit the scope in a conventional commit?▼

Omit the scope when changes span multiple apps or packages across a monorepo. Use the package name for single-package changes and `root` for root-level configuration changes, but never invent scopes like `*` or `all`.

What should I do when a pre-commit hook fails?▼

Fix the underlying issue such as linting errors or formatting problems, then create a new commit. Never use --no-verify to bypass hooks unless the user explicitly requests it, and never amend a failed commit.

Why should I avoid git add . before committing?▼

Staging everything indiscriminately mixes unrelated changes into one commit, making reviews harder and preventing clean reverts. Stage only files related to a single logical change and create separate commits for unrelated work.

What if a pre-commit hook auto-formats my files?▼

Run git status after committing to detect hook modifications, then stage the reformatted files and create a new commit such as `style: apply auto-formatting from pre-commit hook`. Do not amend the original commit unless explicitly requested.