Generate Commit Message

Generate commit messages following cbea.ms guidelines.

Output Format

Default output: Plain text commit message in a code block with NO language tag.

The user should be able to copy the entire content directly. Do NOT include:

• git commit -m wrapper
• EOF or HEREDOC syntax
• bash language tag on the code block
• Extra commentary outside the code block
• Co-authored-by trailers or any git trailers

Short Example

Add input validation to form components

Detailed Example

Implement input validation for form components

- Create validation utility with reusable validators
- Add validators for email, phone, and text inputs
- Update Button and Input to use validation

Format Options

• Short (default): Subject line only (~50 chars)
• Detailed: Subject + bullet list body (3–6 bullets recommended)

When to use detailed:

• User explicitly requests: "detail", "detailed", "comprehensive", "full"
• Many changes: Ask preference before generating

Large change thresholds (trigger preference question):

• Files changed: 5+
• OR Insertions + deletions: 200+

Workflow

1. Run git diff --staged --stat to see staged changes
2. If nothing is staged, ask the user to stage files
3. Analyze git diff --staged
4. Generate the commit message based only on staged changes
5. Decide Short vs Detailed (rules above)
6. Output the plain commit message in a code block (no language tag)

Commit Message Rules

1. Subject line ≤50 chars (warn at 50-72, error >72)
2. Capitalize subject
3. No period at end
4. Imperative mood: "Add feature" not "Added feature"
5. Blank line between subject and body
6. Body lines ≤72 chars

Imperative Test

Subject should complete: "If applied, this commit will [subject]"

Imperative Verbs by Change Type

Context Detection

Infer context from file paths in the staged diff:

• Monorepo app directories (e.g., apps/<name>/*) → mention the app name
• Shared packages (e.g., packages/<name>/*) → mention the package name
• Test files (*.test.*, *.spec.*) → "Add tests" / "Update tests"
• Documentation (*.md) → "Document" / "Update docs"
• Config files (.eslintrc, tsconfig.json, etc.) → "Configure" / "Update config"

Large Changes Handling

When a large change threshold is hit and the user didn't specify format, ask:

I see 8 files staged. Would you like:
1. Short commit message (subject only)
2. Detailed commit message (with bullet points)

Tips

• If changes are too large, suggest splitting into multiple commits
• Keep bullet points action-oriented and concise (3-6 recommended)
• Focus on WHAT and WHY, not HOW
• Never add Co-authored-by or other git trailers to commit messages