Commit

Smart Commit Skill

This skill helps users create well-structured, semantic git commits by analyzing changes and suggesting appropriate commit messages.

CRITICAL REQUIREMENT: SINGLE-LINE COMMITS ONLY

ALL commit messages created by this skill MUST be single-line only.

• DO: git commit -m "feat: add user authentication"
• DON'T: Multi-line commits with body text
• DON'T: Multiple -m flags
• DON'T: Commit messages with \n or additional paragraphs

Keep commits concise and focused. If more detail is needed, suggest adding it separately in PR descriptions or documentation.

Overview

This skill automates the process of reviewing git changes and creating meaningful, conventional commits following the semantic commit format (feat/fix/chore/test).

Core Philosophy

THINK IN PURPOSES, NOT FILES

This skill prioritizes understanding the OVERALL GOAL of changes before deciding how to commit them. The default approach is to:

1. Understand what the developer is trying to achieve
2. Group all related changes into meaningful, purpose-driven commits
3. Prefer fewer, cohesive commits over many fragmented ones

DO NOT commit file-by-file. DO NOT separate tests from implementation. DO NOT fragment features across multiple commits.

Instead, ask: "What story do these changes tell?" and commit accordingly.

Usage

To use this skill, simply say:

• "Help me commit my changes"
• "Create semantic commits"
• "Review and commit changes"
• Use the command: /commit

Process Steps

1. Analyze Git Status

First, check the current git status to understand:

• What files have been modified, added, or deleted
• Which files are staged vs unstaged
• Overall state of the working directory

git status
git diff --stat

2. HOLISTIC ANALYSIS - Understand the Overall Purpose

CRITICAL: Before diving into file-by-file analysis, step back and ask:

• What is the developer trying to achieve overall? (e.g., "Add authentication feature", "Fix login bugs", "Refactor database layer")
• Is there a common theme or goal across these changes?
• Can multiple changes be explained by a single higher-level purpose?

Think strategically, not tactically:

• BAD: "Changed auth.rb, changed user.rb, changed session.rb" -> 3 separate commits
• GOOD: "These are all part of implementing user authentication" -> 1 commit

Review ALL changes together first:

# Get overview of all changes
git diff --stat
git diff

Look for patterns:

• Do multiple files serve the same feature?
• Are there related bug fixes across files?
• Is there a refactoring that touches multiple files?
• Are tests accompanying their implementation?

3. Review Changes in Detail

Now examine each file to understand specifics:

• The nature of changes (new feature, bug fix, refactoring, tests, documentation)
• How it connects to the overall purpose identified in step 2
• Whether it's part of the main change or a separate concern

git diff <file>

4. INTELLIGENT GROUPING - Merge Similar Changes

CRITICAL PRINCIPLE: Prefer fewer, meaningful commits over many small commits

Grouping Strategy:

1. Same Feature/Purpose = One Commit

   • All files contributing to the same feature should be in ONE commit
   • Tests for a feature belong with the feature implementation
   • Related configuration changes belong with the feature

2. Ask: "Would I explain these separately in a code review?"

   • If you'd say "I added X, Y, and Z as part of feature F" -> ONE commit
   • If you'd say "I added X, and separately I fixed Y" -> TWO commits

3. Look for these grouping opportunities:

   • Feature + Tests: Always together
   • Implementation across multiple files: One commit if same feature
   • Bug fix + Test: Together if addressing same issue
   • Refactoring across modules: One commit if same refactoring goal
   • Documentation + Code: Together if documenting the same change
   • Configuration + Code: Together if config is required for the code

4. Only split when:

   • Changes serve genuinely different purposes
   • Mixing would make the commit unclear or too broad
   • One change is risky and should be isolated
   • Different semantic types that shouldn't mix (feat vs fix vs chore)

Examples of Good Grouping:

GOOD - Merged into ONE commit:

Commit: feat: add user authentication
  - lib/auth/authenticator.rb (new authentication logic)
  - lib/user.rb (user model updates)
  - lib/session.rb (session management)
  - spec/auth/authenticator_spec.rb (tests)
  - spec/user_spec.rb (updated tests)
  - config/routes.rb (auth routes)

GOOD - Different purposes, TWO commits:

Commit 1: feat: add user authentication
  - lib/auth/authenticator.rb
  - spec/auth/authenticator_spec.rb
  
Commit 2: fix: resolve database timeout issue
  - lib/database/connection.rb
  - spec/database/connection_spec.rb

BAD - Over-splitting, should be ONE commit:

Commit 1: feat: add authentication logic
  - lib/auth/authenticator.rb
  
Commit 2: feat: update user model for authentication
  - lib/user.rb
  
Commit 3: test: add authentication tests
  - spec/auth/authenticator_spec.rb
  
Commit 4: chore: add authentication routes
  - config/routes.rb

Decision Tree:

Are changes related to the same goal/feature/purpose?
|-- YES -> Combine into ONE commit
|   +-- Even if they touch different files/modules
+-- NO -> Keep as separate commits
    +-- Ask: Are they different semantic types (feat/fix/chore)?
        |-- YES -> Definitely separate
        +-- NO -> Consider if they could still be combined

5. Generate Commit Messages

Based on the holistic analysis, generate commit messages following the conventional commit format:

Format: <type>: <description>

Types:

• feat: New features or functionality
• fix: Bug fixes
• chore: Routine tasks, maintenance, dependencies
• test: Adding or modifying tests (only if standalone)
• docs: Documentation changes (only if standalone)
• refactor: Code refactoring without changing functionality
• style: Code style changes (formatting, whitespace)
• perf: Performance improvements

CRITICAL GUIDELINES:

• MUST BE SINGLE-LINE: Commit messages MUST be a single line only. DO NOT create multi-line commit messages.
• Keep messages concise (ideally under 50 characters)
• Use imperative mood ("add feature" not "added feature")
• Don't end with a period
• Be specific but brief
• One logical PURPOSE per commit (not one file per commit)
• Describe the overall goal, not implementation details
• If more detail is needed, suggest adding it in PR description or commit body separately, but the initial commit MUST be single-line

Examples:

• feat: add user authentication (not "add authenticator.rb, user.rb, session.rb")
• fix: resolve login timeout issues (not "fix auth.rb timeout")
• chore: update dependencies (not separate commits for each gem)
• refactor: simplify database connection logic (not one commit per file)
• docs: update API documentation (only if pure documentation change)