git-commit

Enforce Conventional Commit messages and pre-commit verification before each git commit.

3|Updated Feb 17, 2026
One-click install
npx skills add https://github.com/Mikeys-Tech-Lab/poc --skill git-commit-mikeys-tech-lab
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: git-commit
Source: https://github.com/Mikeys-Tech-Lab/poc/tree/main/.cursor/skills/git-commit
Command: npx skills add https://github.com/Mikeys-Tech-Lab/poc --skill git-commit-mikeys-tech-lab

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents broken, non-atomic, or poorly described commits by enforcing Conventional Commits discipline and running the repo’s required lint/build/test and pre-commit verification steps before anything is staged and recorded.

Core Features & Use Cases

  • Conventional Commit enforcement: Keeps commit messages consistent and machine-parseable, making change history easier to review and automate.
  • Pre-commit verification workflow: Runs the required checks in the correct order (lint first, then build, then tests, then internal reference validity) to catch issues before they reach CI.
  • Operational commit hygiene: Ensures atomic change scope, avoids unintended staged files, and confirms required GPG signing is active; includes PR description upkeep after pushing.

Quick Start

Use this skill before every git commit by running its pre-commit checklist in order, then commit using a Conventional Commits subject formatted as type(scope): subject.

Frequently Asked Questions about git-commit

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

FAQPage Schema
How do I enforce conventional commits and verify my code before pushing?

To enforce conventional commits, run lint, build, and test validation sequencing before staging files. This pre-commit verification ensures code is checked and commit messages follow the type(scope): subject format to prevent broken or non-atomic changes.

What is the correct sequence for pre-commit checks to avoid broken changes?

The correct pre-commit sequence runs lint first, then build, then tests, and finally internal reference validity checks. Following this deterministic order catches issues early and ensures only verified, atomic changes are staged for commit.

How do I review staged files and maintain atomic scope before a git commit?

Review staged files by running git diff --cached to inspect changes before committing. Maintaining atomic scope requires verifying that only intended files are staged, avoiding unintended files, and ensuring the commit represents a single, cohesive change.

Does this commit verification workflow support GPG signing and PR synchronization?

Yes, the commit verification workflow supports GPG signing by confirming it is active before each commit. It also handles PR maintenance by synchronizing the PR description after new commits are pushed to the repository.

Why should I use a pre-commit checklist instead of relying on CI for build verification?

Using a pre-commit checklist catches issues before they reach CI by running required checks locally. This prevents pushing broken or non-atomic changes, reducing CI failures and keeping the repository contribution history clean and deterministic.