Prepare semantic commit (session → Conventional Commits + release bump)

What “last chat” means

• Primary source of truth: git status, git diff (unstaged), and git diff --cached (staged). Run these in the repo root (or the paths the user changed).
• Context: use the current conversation to summarize intent and to spot breaking API/behavior changes that diff alone may not show.
• If the user tracks a session baseline (e.g. branch, tag, or git stash create at start), you may git diff <baseline>..HEAD plus uncommitted diffs; otherwise use only the index and working tree.

Quick workflow

1. Inventory — List changed paths; group by feature vs chore vs docs vs test-only.
2. Decide commit shape — One atomic commit is ideal. If the diff mixes unrelated concerns, recommend multiple commits (each with its own type/scope) before suggesting one message.
3. Classify for semantic release — Using the default analyzer-style mapping (same idea as semantic-release / Conventional Commits): fix → patch, feat → minor, breaking → major.
4. Write the message — type(optional-scope)!: description (see REFERENCE.md). Use ! or a BREAKING CHANGE: footer when behavior contracts change.
5. Deliver — Output:
   • Proposed full commit message (title + optional body + footers).
   • Release bump this commit would drive under typical defaults: patch | minor | major | none (e.g. chore/ci/docs that do not trigger a version in many setups — say “project-dependent”).
   • Optional: git add … and git commit -m / git commit (file) instructions; do not run destructive git commands unless the user asked.