commit

Organize code changes into atomic git commits by logical intent.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/swtch1/dotfiles --skill commit-swtch1
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: commit
Source: https://github.com/swtch1/dotfiles/tree/main/.claude/skills/commit
Command: npx skills add https://github.com/swtch1/dotfiles --skill commit-swtch1

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps you create well-structured and atomic git commits by grouping changes based on their underlying intent, rather than just by file. This leads to a cleaner, more understandable, and maintainable commit history.

Core Features & Use Cases

  • Intent-Based Committing: Organizes changes into logical units of work.
  • Conventional Commit Guidance: Adheres to standard commit message formats (e.g., feat:, fix:).
  • Atomic Commits: Ensures each commit represents a single, independent change.
  • Use Case: When you've made multiple unrelated changes (e.g., a new feature, a bug fix, and documentation updates), this skill guides you to create separate, focused commits for each, making it easier to revert or cherry-pick changes later.

Quick Start

Stage and commit the current changes using a clear, intent-based message.

Frequently Asked Questions about commit

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

FAQPage Schema
How do I create atomic git commits based on logical intent instead of file structure?

To create atomic git commits based on logical intent, you need to survey staged changes, identify distinct intents, and group files into separate commits. This ensures each commit represents a single independent change for easier reverts.

What is the best way to write conventional commit messages for multiple unrelated changes?

The best way to write conventional commit messages for multiple changes is to separate them into focused commits. Survey the changes, identify the distinct intent of each, and apply concise imperative messages using detected formats like feat: or fix:.

How do I split mixed code changes into separate git commits for a cleaner history?

Splitting mixed code changes into separate git commits requires identifying the distinct logical intent behind each modification. Plan and execute separate commits for each intent, excluding temporary files, to maintain a clean and understandable history.

Does this approach to version control exclude temporary files when staging code?

Yes, this approach to version control ensures the exclusion of temporary files when staging code. It surveys your working directory to organize only meaningful modifications into atomic commits based on their underlying intent.

When do I need to use conventional commit formats in my development workflow?

You need to use conventional commit formats in your development workflow when you want a standardized, readable history. The process detects existing conventional formats like feat: or fix: and guides you to apply them with concise imperative messages.