git-storytelling-commit-messages

# Git Storytelling - Commit Messages

This skill guides you in crafting commit messages that are clear, informative, and tell the story of your development process. Good commit messages are documentation that lives with your code.

## Core Principles

### The Purpose of Commit Messages

Commit messages serve multiple audiences and purposes:

- **Future developers** (including yourself) understanding why changes were made
- **Code reviewers** evaluating the intent and scope of changes
- **Project managers** tracking progress and understanding what was delivered
- **Automated tools** generating changelogs and release notes
- **Git tools** like blame, log, and bisect for debugging

### The Three-Part Structure

Effective commit messages follow a consistent structure:

1. **Subject Line**: Brief summary (50 characters or less)
2. **Body** (optional): Detailed explanation of what and why
3. **Footer** (optional): Issue references, breaking changes, co-authors

### The Subject Line Format

```
<type>: <description>

Examples:
feat: add user authentication system
fix: resolve race condition in payment processing
docs: update API documentation for v2 endpoints
```

## Commit Message Anatomy

### Subject Line Rules

**DO:**

- Start with a type prefix (feat, fix, docs, etc.)
- Use imperative mood ("add" not "added" or "adds")
- Keep it under 50 characters
- Don't end with a period
- Capitalize the first letter after the colon
- Be specific and descriptive

**DON'T:**

- Use vague terms like "update stuff" or "fix things"
- Include file names unless necessary
- Describe HOW you did it (that's what the code shows)
- Use past tense
- Be too generic

### Body Guidelines

The body should explain:

- **What** changed (briefly, the code shows details)
- **Why** the change was needed
- **Any side effects** or implications
- **Alternatives** considered
- **Context** that isn't obvious from the code

Format:

- Wrap at 72 characters per line
- Use bullet points for multiple items
- Se