Human Commit

Reads git changes and generates commit messages that sound like a real developer wrote them.

Workflow

Step 1 — Read the diff

git diff --cached 2>/dev/null

If output is empty (nothing staged), fall back to:

git diff HEAD 2>/dev/null

Also check what files are involved:

git status --short 2>/dev/null

If the diff is longer than ~500 lines, don't try to analyze it raw. First identify the top changed files:

git diff --cached --stat 2>/dev/null || git diff HEAD --stat 2>/dev/null

Then focus analysis on the most-changed files and the overall theme, not every line.

Step 1b — Detect repo commit style

git log --oneline -5 2>/dev/null

Look at the last 5 commits. If most follow Conventional Commits format (type(scope): subject or type: subject), the repo uses CC. If they're plain lowercase sentences, stick to plain style. Match the existing style — don't introduce a new one.

Step 2 — Analyze the changes

Identify:

What files changed and in what area (auth, UI, deps, config, tests, etc.)
The nature of the change (fix, add, remove, move, update, refactor)
Whether there's an obvious "why" (bug, cleanup, new feature, maintenance)
Scope (for monorepos): if changed files are under packages/, apps/, or named workspaces, infer scope from the directory name (e.g., packages/auth/ → scope auth)
Breaking changes: if the diff removes exported functions, renames public interfaces, changes function signatures, or bumps a major version, flag it — the message may need a BREAKING CHANGE footer

Step 3 — Generate 3 options

Output exactly 3 commit message options. Each on its own line, in a code block.

Style rules (adapt to repo style detected in Step 1b):

If the repo uses Conventional Commits (detected in Step 1b):

Use type(scope): subject format — fix, feat, refactor, chore, docs, test, build
Scope is optional; include it if changed files suggest a clear scope
Subject lowercase, imperative mood, ≤72 chars
If a breaking change was detected: add blank line + BREAKING CHANGE: <what changed>

If the repo uses plain style (or no clear pattern):

Lowercase subject line
Subject ~50 chars (up to 72 is fine)
No conventional commit prefixes — fix tokens not expiring not fix: resolve token expiry
Imperative mood — "fix X" not "fixed X" or "fixes X"

Both styles:

Skip obvious filler — not "update code to fix the issue with the login"
Optional body — add a blank line + 1-2 lines only if the change genuinely needs explanation (lines ≤72 chars)

Anti-patterns to avoid:

❌ implement JWT token validation middleware with expiry checking
❌ refactor: extract authentication logic into separate service module
❌ fix: resolve issue with user authentication token expiration handling
✅ fix tokens not expiring
✅ move auth to its own file
✅ bump deps
✅ add dark mode toggle
✅ fix login redirect on mobile

Output Format

Plain style:

Option 1: fix tokens not expiring
Option 2: auth middleware wasn't checking expiry
Option 3: fix expired jwt tokens still passing through

Conventional Commits style:

Option 1: fix(auth): tokens not expiring on check
Option 2: fix(auth): jwt expiry not validated
Option 3: fix: expired tokens still passing auth middleware

With a body (when useful):

Option 2: reorganize auth module

pulled jwt logic out, the file was getting too long

With a breaking change footer:

Option 1: refactor(api): rename user endpoints

BREAKING CHANGE: /users/:id renamed to /users/:userId

Pick the best option as Option 1.