/smart-commit:commit

Analyze all staged git changes and generate an intelligent conventional commit message.

Process

1. Run git diff --cached --stat to identify all staged files and their change magnitudes.

2. Run git diff --cached to read the full diff of staged changes.

3. Determine the primary commit type based on the nature of changes:

   • feat - New functionality, new files introducing features, new endpoints or UI components
   • fix - Bug corrections, error handling improvements, null checks, edge case fixes
   • refactor - Code restructuring without behavior change, renaming, extraction of functions
   • docs - Documentation-only changes, comments, README updates, docstrings
   • test - Adding or modifying tests, test fixtures, test utilities
   • chore - Build config, dependency updates, CI changes, tooling, linting rules
   • perf - Performance improvements, caching, query optimization, lazy loading
   • style - Formatting, whitespace, semicolons, code style (no logic change)
   • ci - CI/CD pipeline changes, workflow files, deployment configs

4. Derive the scope from the most affected directory or module:

   • Use the top-level directory name if changes span one area (e.g., auth, api, ui)
   • Use a broader scope if changes span multiple areas (e.g., core, app)
   • Omit scope if changes are truly cross-cutting or trivial

5. Write the commit subject line (max 72 characters):

   • Use imperative mood ("add" not "added", "fix" not "fixes")
   • Focus on WHY the change was made, not WHAT files changed
   • Be specific: "fix race condition in websocket reconnect" not "fix bug"
   • Do not end with a period

6. Determine if a body is needed (skip for obvious single-line changes):

   • Explain the motivation behind the change
   • Describe the approach taken and why alternatives were rejected
   • Keep each line under 80 characters

7. Add footers when applicable:

   • BREAKING CHANGE: <description> if the change breaks existing APIs or behavior
   • Closes #<number> if the change resolves a tracked issue
   • Refs: <context> for related PRs, issues, or discussions

8. Present the commit message for review, then execute git commit with the approved message.

Output Format

type(scope): concise imperative description

Optional body explaining the motivation and approach.

Optional footers.

Rules

• Never fabricate issue numbers or references
• If multiple types apply equally, prefer the one with the largest behavioral impact
• When in doubt between feat and refactor, ask: does the user-visible behavior change?
• Run git log --oneline -10 first to match the repository's existing commit style
• If nothing is staged, inform the user and suggest what to stage