Commit Assistant

Comprehensive guidance on conventional commits with automatic message generation integrated with CCPM's Linear workflow. Ensures all commits are properly formatted, issue-linked, and semantically meaningful.

When to Use

This skill auto-activates when:

• User asks "commit my changes", "create a git commit", "how do I commit"
• User asks about "conventional commits" or "commit message format"
• Running /ccpm:commit command
• Making changes that need to be committed to version control
• Need guidance on commit type or commit message structure
• Need help generating commit messages from code changes

Core Principles

1. Conventional Commits Format

All commits in CCPM follow Conventional Commits specification:

type(scope): message

[optional body]

[optional footer]

Format breakdown:

• type: What kind of change (feat, fix, docs, refactor, test, chore, perf, style)
• scope: What component or module changed (optional but recommended)
• message: Clear, concise description in imperative mood
• body: Detailed explanation (only for complex changes)
• footer: Issue references, breaking changes (optional)

2. Why Conventional Commits Matter

Conventional commits enable:

• ✅ Automatic changelog generation
• ✅ Semantic versioning (SemVer) automation
• ✅ Better git history readability
• ✅ Linear issue linking
• ✅ Filtered log searches (git log --grep="^feat")
• ✅ CI/CD pipeline triggers (e.g., deploy on "feat:" commits)

3. Imperative Mood

Always write commit messages in imperative mood (command form):

✅ Correct:

• "add user authentication"
• "fix database connection timeout"
• "refactor auth module for clarity"
• "update API documentation"

❌ Incorrect:

• "added user authentication"
• "fixed database connection timeout"
• "refactoring auth module"
• "updates API documentation"

Why: Imperative mood matches git's own commit messages and convention specifications.

Commit Types Explained

feat: - New Features

Use when: Adding new functionality to the codebase.

Examples:

• feat(auth): add JWT token refresh endpoint
• feat(api): implement rate limiting middleware
• feat(ui): add dark mode toggle

When NOT to use: Bug fixes should use fix:, not feat:

fix: - Bug Fixes

Use when: Fixing a bug or defect in existing functionality.

Examples:

• fix(auth): prevent expired tokens from accessing protected routes
• fix(api): handle null values in user query results
• fix(ui): correct button alignment on mobile devices

When NOT to use: Adding new features should use feat:, not fix:

docs: - Documentation Changes

Use when: Writing or updating documentation, comments, README, or API docs.

Examples:

• docs(readme): add installation instructions
• docs(api): document rate limiting headers
• docs: add troubleshooting guide

Impact: Does NOT trigger version bumps (not a "feature" or "fix")

refactor: - Code Refactoring

Use when: Restructuring code without changing functionality (performance, readability, maintainability).

Examples:

• refactor(auth): extract JWT validation to separate module
• refactor(api): simplify error handling logic
• refactor: rename misleading variable names

Impact: Does NOT trigger version bumps (internal improvement only)

test: - Test Additions/Changes

Use when: Adding, updating, or fixing tests (no production code changes).

Examples:

• test(auth): add tests for JWT expiration
• test(api): improve test coverage for rate limiter
• test: fix flaky database integration test

Impact: Does NOT trigger version bumps

chore: - Build/Tooling Changes

Use when: Updating dependencies, build config, CI/CD, or development tools.

Examples:

• chore(deps): upgrade Node.js to v20.11
• chore(build): update webpack configuration
• chore(ci): configure GitHub Actions for linting

Impact: Does NOT trigger version bumps

perf: - Performance Improvements

Use when: Code optimization that improves performance metrics.

Examples:

• perf(api): cache database queries for 5 minutes
• perf(ui): optimize image rendering for 40% faster load time
• perf: reduce bundle size by 15%

Impact: Triggers patch version bump (like fix:)

style: - Code Style Changes

Use when: Formatting, whitespace, or code style changes (no logic changes).

Examples:

• style: reformat code according to ESLint rules
• style(css): remove unused CSS classes
• style: add missing semicolons

Impact: Does NOT trigger version bumps

Auto-Generation with /ccpm:commit

The /ccpm:commit command provides intelligent commit message auto-generation.

Usage

Basic usage:

/ccpm:commit                    # Auto-detect issue, generate message
/ccpm:commit AUTH-123           # Li

...