This Claude skill automates the generation of professional, standardized git commit messages by analyzing staged changes and project history. It ensures strict adherence to Conventional Commits and project-specific styles, helping developers maintain a clean, readable, and searchable repository history while accelerating the development workflow.

When should I use commit?

commit is useful in the following scenarios: • Standardizing repository history across a team by automatically applying Conventional Commits formatting (feat, fix, refactor, etc.). • Generating accurate and descriptive commit messages for complex changes by analyzing 'git diff' and 'git status' output. • Maintaining project consistency by automatically referencing recent commit logs to match the existing naming conventions and style. • Streamlining the CLI workflow by combining change analysis, message drafting, and commit execution into a single AI-powered step.

name	commit
description	Generate commit messages following project conventions for staged changes. Use when the user asks to commit changes or run /commit.

Commit Message Generator

Generate commit messages following project conventions for staged changes.

Instructions

When this skill is invoked:

Run git diff --staged to review the staged changes
Run git status to understand the overall state
Run git log --oneline -10 to see recent commit style for context
Analyze what was changed and why
Generate a commit message following the format below
Present the commit message to the user for approval - keep it concise, just show the message and ask for approval
If approved, execute the commit

Presentation Style: Be direct and minimal. Present only the commit message and ask "Proceed with this commit message?" - no analysis, explanations, or bullet points unless the changes are complex or ambiguous.

Commit Message Format

<type>: <short description>

[optional body with more detail]

Types

feat - New feature
fix - Bug fix
refactor - Code restructuring without behavior change
test - Adding or updating tests
docs - Documentation changes
style - Formatting, whitespace (no code change)
chore - Build, config, dependency updates

Rules

First line: Must be under 72 characters
Tense: Present tense, imperative mood ("add" not "added" or "adds")
Description: Complete the sentence "This commit will..."
Body: Optional, use for explaining "why" not "what"
NO AI attribution: Never include "Generated with Claude Code" or "Co-Authored-By" lines

Examples

feat: add auto-reveal toggle for estimation rounds

fix: prevent duplicate user connections to lobby

refactor: extract insight resolution logic to separate resolvers

test: add usecase tests for SetEstimateCommand handler

docs: update architecture documentation with processing groups

chore: upgrade Spring Boot to 3.4.12

Analysis Guidelines

When analyzing changes, consider:

Module affected: Which module (api, lobby, session, ui)?
Layer affected: Domain, usecase, adapter, or API contract?
Intent: What problem does this solve or capability does it add?
Scope: Is this a single logical change or mixed concerns?

Common Patterns to Recognize

Backend Changes:

New Commands/Events/Queries in api/ → feat: add X command/event/query
Handler implementations → feat: implement X handler or fix: correct X handler logic
Domain logic updates → feat: add X behavior to aggregate or refactor: simplify X logic
Read model updates → feat: update X view projection
Tests → test: add tests for X

Frontend Changes:

New components → feat: add X component
State management → feat: implement X state handling
UI improvements → feat: enhance X interface
Styling → style: update X component styles

Mixed Changes:

If frontend + backend for same feature → feat: add X feature (describe full feature)
If unrelated changes → Suggest splitting into multiple commits

commit

When & Why to Use This Skill

Use Cases