commit-msg

Generate Conventional Commit Message

Analyze the current git changes and produce a Conventional Commits message.

If $ARGUMENTS is provided, use it as the commit scope (e.g. auth, api, ui).

Step 1 — Read Git Status

Run:

git status --short

to see staged and unstaged files.

Run:

git diff --cached

to get staged changes (what will be committed).

If no staged changes, run:

git diff

to get unstaged changes instead, and note that the user should stage files first.

If neither has output, report: "No changes detected. Stage your changes with git add first." and stop.

Step 2 — Analyze Changes

Read the diff and identify:

What changed:

• New files added → likely feat
• Existing logic modified to fix incorrect behavior → fix
• Code restructured without behavior change → refactor
• CSS, formatting, whitespace only → style
• Test files only → test
• Markdown, comments, JSDoc → docs
• Config, dependencies, build scripts → chore
• Performance improvement (memoization, caching, query opt.) → perf

Scope (the area of the codebase affected):

• If $ARGUMENTS provided, use it as scope
• Otherwise infer from changed file paths:
  • src/components/auth/ → scope: auth
  • src/api/users/ → scope: users
  • src/hooks/ → scope: hooks
  • package.json only → scope: deps
  • Multiple unrelated areas → omit scope

Breaking change:

• Removed exported function/type
• Changed function signature
• Renamed route/endpoint
• Removed env variable

Step 3 — Draft Commit Message

Follow the Conventional Commits specification:

{type}({scope}): {subject}

{body}

{footer}

Rules:

• type: one of feat, fix, refactor, style, test, docs, chore, perf
• scope: optional, lowercase, no spaces (use - for multi-word: user-auth)
• subject: imperative mood, lowercase, no period, max 72 chars ✓ add login endpoint ✗ Added login endpoint.
• body: optional, explains why not what, wrap at 72 chars
• footer: BREAKING CHANGE: {description} if applicable, or Closes #123