commit-messages

Generate conventional commit messages from staged git changes.

1|Updated Aug 21, 2023
One-click install
npx skills add https://github.com/jmuchovej/homelab --skill commit-messages-jmuchovej
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: commit-messages
Source: https://github.com/jmuchovej/homelab/tree/main/src/modules/ai-tools/skills/git-commit-messages
Command: npx skills add https://github.com/jmuchovej/homelab --skill commit-messages-jmuchovej

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing clear, consistent commit messages is hard to sustain across a team, leading to vague history like "fix bug" that makes code archaeology painful. This Skill generates conventional commit messages from staged changes so your git history stays readable and consistent. ## Core Features & Use Cases - Conventional Commit Generation: Produces type(scope): subject messages (feat, fix, docs, refactor, perf, test, build, ci, chore, revert) based on the files and diffs changed. - Style Detection: Checks git log to match the repository's existing convention, including path-based styles like modules/home/git: enable delta used in monorepos. - Breaking Change Flagging: Marks breaking changes with ! and BREAKING CHANGE footers when APIs, exports, or schemas change. - Use Case: After staging a bug fix in the checkout flow, ask for a commit message and get fix(checkout): prevent duplicate order submission with a body explaining the motivation and a Fixes #128 reference. ## Quick Start Generate a conventional commit message for my currently staged git changes following this repository's existing style.

Frequently Asked Questions about commit-messages

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): subject, such as feat(auth): add login page. Choose the type from the change kind (feat, fix, docs, refactor, perf, test, build, ci, chore, revert), derive scope from the changed file path, and keep the subject under 72 characters in imperative mood.

How to choose the right commit type for my changes?

Look at the files changed: new files usually mean feat, test-only changes mean test, config or build files mean build or ci, and documentation means docs. Examine the diff for bug fix patterns (fix), new exports (feat), restructuring (refactor), or optimizations (perf).

When should I use path-based commit messages instead of conventional commits?

Use path-based messages like modules/nixos/docker: fix socket permissions when the project strictly follows that convention, common in monorepos or Nixpkgs-style projects. Always check git log first to confirm which convention the repository actively uses.

How do I mark a breaking change in a commit message?

Add an exclamation mark after the type, like feat(api)!: change response format, and include a BREAKING CHANGE footer explaining the impact. Breaking changes include API format changes, removed exports, changed function signatures, and schema changes.

When should I omit the scope in a commit message?

Omit scope when changes span multiple unrelated areas, when the type alone is sufficient such as docs or ci, or when the scope would be too generic like code. Derive scope from the changed path only when it clarifies the change.