commit

Create small atomic git commits using conventional commit format at validated checkpoints.

Updated Nov 7, 2024
One-click install
npx skills add https://github.com/jeremysball/dotfiles --skill commit-jeremysball
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: commit
Source: https://github.com/jeremysball/dotfiles/tree/main/.pi/skills-archive/commit
Command: npx skills add https://github.com/jeremysball/dotfiles --skill commit-jeremysball

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents messy, oversized commits by guiding you to split work into small, logical, validated changes with clear conventional commit messages. ## Core Features & Use Cases - Atomic Commit Discipline: Enforces one logical change per commit with staged-diff review before committing. - Mixed Worktree Playbook: Groups dirty worktree files into logical slices and commits each separately, using git add -p for mixed hunks. - Conventional Commit Format: Standardizes messages as type[scope]: description with types like feat, fix, docs, refactor, and test. - Use Case: After finishing a feature with tests and docs updated, stage only the related files, run targeted validation, and commit as feat(memory): add support profile scope contract without dragging in unrelated changes. ## Quick Start Ask the assistant to review the current worktree and commit the completed changes as small conventional commits.

Frequently Asked Questions about commit

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, such as feat(auth): add login endpoint. Keep the type and scope lowercase, write an imperative description, and keep the summary under 72 characters.

How do I split a dirty git worktree into multiple commits?

Group modified files by logical change rather than directory, name each commit in one line, then stage and commit each slice separately. Use git add -p when a single file contains unrelated hunks.

When should I use git add -p instead of git add?

Use git add -p only when one file contains unrelated hunks that belong to different commits. If the change is already clean and atomic, plain git add of the intended files is sufficient.

What should I check before making a git commit?

Confirm the staged diff is one logical change, relevant validation passed on the touched surface, no unrelated files are staged, and the message is specific. Review git diff --cached before committing.

Should I commit everything at once when asked?

First determine whether everything is one logical change or several. If it is several slices, propose the split and get confirmation; only make one large commit if the user explicitly insists.