git-commit

You are running in a VS Code workspace.

Goal: Analyze the current git changes and suggest high-quality Conventional Commit message(s). Prefer staged changes when present. Do NOT create commits—only suggest messages.

STRICT SAFETY RULE:

• •You MUST NOT run git commit, git push, or modify git history in any way.
• •You MUST ONLY analyze repository state and OUTPUT suggested commit message(s).

Hard Requirements:

• •All suggestions MUST follow Conventional Commits: <type>(optional-scope): <subject>
• •Allowed types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
• •Subject rules:
  • •imperative mood
  • •no trailing period
  • •<= 72 characters
• •Scope: optional but recommended when obvious
• •If a breaking change is detected, use '!' and include a BREAKING CHANGE note.
• •Do not invent changes that are not present in git status/diff/log.
• •NEVER add co-author information or Claude attribution
• •Commits should be authored solely by the user
• •Do not include any "Generated with Claude" messages
• •Do not add "Co-Authored-By" lines
• •Write commit messages as if the user wrote them

Process:

1. •

   Collect git context using the Bash tool with these read-only commands in parallel:

   • •git rev-parse --show-toplevel
   • •git status --porcelain=v1
   • •git diff --stat
   • •git diff
   • •git diff --staged --stat
   • •git diff --staged
   • •git log -n 10 --oneline --decorate
2. •

   Determine review target:

   • •If staged changes exist, analyze the staged diff output
   • •Otherwise, analyze the unstaged diff output
3. •

   Analyze changes:

   • •Identify primary intent (feat, fix, refactor, docs, test, chore, build, ci).
   • •Infer scope from paths/modules when clear.
   • •Detect multiple concerns and recommend splitting if appropriate.
   • •Detect breaking changes:
     • •removed/renamed public APIs
     • •behavior changes
     • •schema changes
     • •incompatible config changes

Output Format (exactly):

A) Summary

• •2–4 bullets describing what changed
• •Whether staged or unstaged diffs were used
• •Whether multiple commits are recommended

B) Recommended Commit(s)

• •If a single commit is appropriate, show one.
• •If multiple commits are cleaner, show them in order.

C) Copy-Ready Commit Message(s) Provide the final commit message(s) in Markdown code block(s), formatted exactly as they should be used.

Rules for Code Blocks:

• •Use triple backticks
• •One commit per code block
• •No commentary inside the code block
• •Ready to paste into git commit -m or an editor
• •If a description body is included, format each item as a bullet point using - Example:
  code

  feat(auth): add OAuth2 login flow
  
  - Add Google and GitHub provider support
  - Implement token refresh logic
  - Update user model with provider fields
  

Quality Bar:

• •Prefer refactor over feat if behavior did not change.
• •Prefer chore(deps) for dependency updates.
• •Prefer build/ci for pipeline/config changes.
• •Prefer docs for documentation-only changes.
• •Prefer test when only tests change.
• •Keep suggestions realistic and grounded in the diff.

Now run the process and produce the output.