commit

Stage and commit changes with conventional messages and logical grouping.

8|Updated Jul 7, 2017
One-click install
npx skills add https://github.com/ebkn/dotfiles --skill commit-ebkn
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: commit
Source: https://github.com/ebkn/dotfiles/tree/main/root/.claude/skills/commit
Command: npx skills add https://github.com/ebkn/dotfiles --skill commit-ebkn

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Replaces ad-hoc, monolithic commits with small, well-scoped conventional commits so history is easier to review, revert, and understand. It reduces reviewer friction by ensuring each change is grouped by scope and intent and documented with a concise subject and optional explanatory body.

Core Features & Use Cases

  • Inspect working changes and recent history to decide logical commit boundaries using git diff and git log.
  • Stage related files or hunks into separate commits and produce Conventional Commits style messages with an optional body explaining why the change was made.
  • Use Case: Split simultaneous updates to zsh, vim, and tmux configs into separate commits classified by scope and intent for clearer review.

Quick Start

Run the commit skill to inspect diffs, split unrelated changes into logical staged sets, and create conventional commit messages following the repository style.

Frequently Asked Questions about commit

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

FAQPage Schema
How do I split mixed changes into separate conventional commits?

To split mixed changes into separate conventional commits, inspect the working diffs and recent logs to identify logical boundaries, then stage related files or hunks into distinct commits with concise, scope-based messages. This ensures history is easier to review and revert.

How do I stage related files or hunks into separate commits?

You stage related files or hunks into separate commits by using git diff to inspect changes, grouping related edits logically, staging them with git add, and committing with conventional messages that classify the change by scope and intent.

Does this conventional commit approach work with local git repositories?

Yes, this conventional commit approach works with local git repositories where developers have read and write access, the ability to run git status, diff, log, add, and commit, and apply human judgment to group hunks and compose messages.

Why use conventional commits instead of monolithic commits?

Use conventional commits instead of monolithic commits to ensure each change is grouped by scope and intent, producing a concise, reviewable history that is significantly easier to review, revert, and understand when examining project evolution.

What's the best way to group simultaneous updates to different config files in git?

The best way to group simultaneous updates to different config files is to split them into separate commits classified by scope and intent, such as isolating zsh, vim, and tmux configuration changes to produce a clearer, more reviewable history.

When should I not use conventional commits for staging changes?

You should not use conventional commits for staging changes if your local repository lacks git read and write access, or if the environment cannot execute git status, diff, log, add, and commit commands required to inspect diffs and group hunks.