Conventional Commit Command

Generate a conventional commit message following https://www.conventionalcommits.org/en/v1.0.0/ specification and create commits automatically.

Quality Guidelines

CRITICAL: Commit messages must accurately describe ACTUAL changes:

1. Read the diff - Base message ONLY on what you see in the diff, not assumptions
2. Verify scope - Check which files/modules actually changed before setting scope
3. Check breaking changes - Look for removed exports, changed APIs, deleted functions
4. No guessing - If unsure about change purpose, ask user rather than assume

Your Task

Phase 1: Parallel Change Analysis (Use SubAgents for Complex Changes)

For changes spanning multiple files or concerns, spawn parallel agents:

If git diff shows >100 lines or >5 files changed:

Agent 1 - Semantic Analysis:
- prompt: "Analyze this git diff and explain what the code changes actually DO. Focus on behavior changes, not just file names. What features were added? What bugs were fixed?"
- subagent_type: "general-purpose"

Agent 2 - Breaking Change Detection:
- prompt: "Check this git diff for breaking changes: removed public functions, changed function signatures, deleted exports, renamed APIs. List any breaking changes found."
- subagent_type: "general-purpose"

Agent 3 - Commit Splitting Analysis:
- prompt: "Should these changes be split into multiple commits? Look for: mixing features with fixes, unrelated changes, docs mixed with code. Recommend how to split if needed."
- subagent_type: "general-purpose"

Merge results → Generate accurate commit message(s)

Track Progress with TodoWrite (For Multiple Commits)

When changes need to be split into multiple commits, use TodoWrite:

Example: Changes include a feature, a fix, and docs update

TodoWrite:
- [ ] Commit 1: feat(auth): add OAuth2 support
- [ ] Commit 2: fix(api): resolve null pointer exception
- [ ] Commit 3: docs: update authentication guide

Mark each as in_progress → completed as you stage and commit.

Phase 2: Analyze Changes

1. Analyze Changes: Run git status and git diff --staged to understand current changes
2. Group Related Changes: Identify logically separate changes that should be committed individually (e.g., separate feature additions from bug fixes, documentation updates from code changes)
3. For Each Logical Group:

• Determine the appropriate commit type:
  • feat: New feature for the user
  • fix: Bug fix for the user
  • docs: Documentation only changes
  • style: Code style changes (formatting, missing semi-colons, etc.)
  • refactor: Code change that neither fixes a bug nor adds a feature
  • perf: Performance improvements
  • test: Adding missing tests or correcting existing tests
  • build: Changes to build system or external dependencies
  • ci: Changes to CI configuration files and scripts
  • chore: Other changes that don't modify src or test files
  • revert: Reverts a previous commit
• Identify the scope if applicable (component, module, or area affected)
• Write a concise description in imperative mood (max 50 characters)
• Add a detailed body if the change is complex (wrap at 72 characters)
• Include breaking change footer if applicable: BREAKING CHANGE: description
• Format as: type(scope): description

4. Commit Strategy:

• If changes represent a single logical unit: create one commit
• If changes span multiple concerns: create separate commits for each logical group
• Stage files appropriately for each commit using git add
• Create each commit with the generated message

Example Formats

feat(auth): add OAuth2 login support
fix(api): resolve null pointer in user endpoint
docs: update installation instructions
chore(deps): bump lodash to 4.17.21
refactor(parser): extract validation logic to separate module

feat(shopping-cart)!: remove deprecated calculate() method

BREAKING CHANGE: calculate() has been removed, use computeTotal() instead

Important Notes

• Multiple Commits: If you identify different types of changes (e.g., feat + fix + docs), create separate commits for each type
• Staging: Use git add <specific-files> to stage only relevant files for each commit
• Imperative Mood: Use "add" not "added", "fix" not "fixed"
• Breaking Changes: Append an exclamation mark after type/scope and add a BREAKING CHANGE: footer
• Scope: Optional but recommended for clarity (e.g., component name, module name)
• Body: Use for complex changes to explain the "what" and "why", not "how"
• Pre-commit Hooks: NEVER use --no-verify to skip pre-commit hooks - it's a bad practice that bypasses important quality gates

Generate the most appropriate commit message(s) based on the changes and commit automatically. Ask for confirmation before committing if the changes are complex or span multiple concerns.