Generate Commit Message Skill

Overview

This skill generates concise, meaningful commit messages by:

•First priority: Use conversation context (files edited, changes discussed)
•Fallback: Run git diff when context is unavailable
•Keep messages brief and focused

When to Use

•After implementing changes discussed in the conversation
•When you want a commit message that reflects the actual work done
•To quickly commit without manual message writing

Usage

Simply invoke this skill after making changes. The skill will:

•Check conversation context for what was changed
•If no context: run git diff --cached to analyze changes
•Generate a concise commit message
•Prompt for user confirmation before committing

Commit Message Format

code

<type>: <brief summary (<=50 chars)>

[Optional body: concise explanation of what/why, <=3 lines]

[Optional footer: Breaking changes, issue refs]

Type Prefixes

•feat: New feature
•fix: Bug fix
•refactor: Code restructure without behavior change
•perf: Performance improvement
•docs: Documentation only
•style: Formatting, whitespace
•test: Add/update tests
•chore: Build, tools, dependencies
•build: Build system changes
•ci: CI/CD changes

Implementation Guidelines

Step 1: Check Conversation Context

Has context if:

•Files were edited via Write/Edit tools in this conversation
•User described what was changed
•Features/fixes were discussed

No context if:

•User just says "commit my changes" without prior discussion
•Changes were made outside this conversation
•Files were modified manually by user

Step 2: Get Change Information

If context available:

•Use known file edits and changes
•Skip git diff entirely

If no context:

bash

# Get list of changed files with status
git diff --cached --name-status

# Get file-level stats
git diff --cached --stat

# Get actual changes (for understanding what was done)
git diff --cached

# Alternative: if nothing staged, check working directory
git status --short
git diff --stat
git diff

Step 3: Generate Concise Message

Principles:

•Brevity: Summary <=50 chars, body <=3 lines
•What, not how: Describe the outcome, not implementation
•Imperative mood: add, fix, update (not added, fixed)

Good Examples:

code

feat: add scroll limit config commands

Add get-scroll-settings and set-scroll-limit commands
to es_tool.sh for managing ES scroll configuration.

code

fix: ensure bulk requests end with newline

ES bulk API requires NDJSON format with trailing newline.

code

refactor: translate es_tool comments to English

Bad Examples:

code

feat: implement comprehensive elasticsearch scroll configuration management system

This commit adds a full suite of commands for managing scroll-related
settings in Elasticsearch including viewing current configuration,
modifying document count limits, enabling/disabling rejection behavior...
[TOO VERBOSE]

Step 4: Present and Confirm

bash

# Show what will be committed
git status --short

# Present message
echo "Proposed commit message:"
echo "----------------------------------------"
echo "<generated_message>"
echo "----------------------------------------"
echo ""
read -p "Commit these changes? (y/n): " response

Step 5: Execute Commit

CRITICAL: The commit message MUST be clean and professional. DO NOT include:

•🤖 Generated with [Claude Code] markers
•Co-Authored-By: Claude attributions
•Any other tool-generated metadata or signatures

These add no value and clutter the commit history.

bash

# Commit with generated message (NO extra metadata)
git commit -m "$(cat <<'EOF'
<generated_message>
EOF
)"

# Show result
git log -1 --oneline

Decision Flow

code

START
  |
  v
Do we have conversation context about changes?
  |
  +-- YES --> Use context to generate message
  |            (Skip git diff)
  |
  +-- NO --> Run git diff to analyze changes
              |
              v
            Are changes staged?
              |
              +-- YES --> git diff --cached
              |
              +-- NO --> git diff (working directory)
  |
  v
Generate concise commit message
  |
  v
Present to user for confirmation
  |
  v
User confirms?
  |
  +-- YES --> git commit
  |
  +-- NO --> Exit (no commit)
  |
  v
END

Examples

Example 1: With Context (No Git Diff)

Conversation:

code

User: Add health check commands to es_tool.sh
Assistant: [edits es_tool.sh, adds check-health, check-shards, etc.]
User: Create a commit

Skill execution:

•Context available: Edited es_tool.sh, added health check commands
•Skip git diff

•Generate:

code

feat: add cluster health check commands

Implements check-health, check-shards, explain-allocation,
and fix-red-shards for ES cluster diagnostics.

Example 2: No Context (Use Git Diff)

Conversation:

code

User: Generate commit message

Skill execution:

•No context available

•Run git diff --cached:

diff

diff --git a/script/es_tool.sh b/script/es_tool.sh
@@ -841,7 +841,7 @@ execute_http_request() {
-            content_type="text/plain"
+            content_type="application/x-ndjson"
+            # Ensure body ends with newline
+            if [[ "$body" != *$'\n' ]]; then
+                body="${body}"$'\n'
+            fi

•Analyze: Changed content-type for bulk requests, added newline

•Generate:

code

fix: correct bulk request content-type

Use application/x-ndjson and ensure trailing newline
for ES bulk API NDJSON format compliance.

Example 3: User Provides Context

Conversation:

code

User: Commit the fix for the bulk API newline issue

Skill execution:

•Context from user: "fix for bulk API newline issue"
•
Quick check: git diff --cached --name-only (just filenames)
code
```
script/es_tool.sh
```

•Generate (minimal diff needed):

code

fix: ensure bulk requests end with newline

Add trailing newline to bulk request body for
ES NDJSON format requirements.

Best Practices

DO:

•Use conversation context when available
•Run git diff when context is missing
•Keep summary under 50 characters
•Use imperative mood (add, fix, update)
•Focus on WHAT and WHY
•Confirm with user before committing

DON'T:

•Skip git diff when you have no context
•Write verbose explanations
•Describe HOW code was implemented
•Auto-commit without confirmation
•Use past tense (added, fixed, updated)

Git Tags

When user requests creating a tag (for CI/CD pipeline trigger, release, etc.):

•
Check existing tag format first:
bash
```
git tag --sort=-creatordate | head -5
```
•
Keep format consistent - DO NOT add 'v' prefix unless project already uses it:
- •If existing: 0.4.0, 0.3.0 → use 0.4.1 (no 'v')
- •If existing: v0.4.0, v0.3.0 → use v0.4.1 (with 'v')
•
Never assume tag format - always verify from existing tags

Notes

•Optimizes for speed by using context when available
•Falls back to git diff when needed for accuracy
•Generates concise but informative messages
•Always confirms before committing
•Works in both interactive and standalone scenarios