Create a git commit

allowed-tools: Bash(git status:), Bash(git diff:), Bash(git log:), Bash(git branch:), Bash(git commit:*) argument-hint: [additional explanation] description: Create a git commit

Context

• Current git status: !git status
• Staged changes: !git diff --staged
• Recent commits (for language detection): !git log -n 10 --pretty=format:"%s"
• Current branch: !git branch --show-current

Your Task

Based on the above context:

1. Analyze the staged changes for any critical issues:

   • Review the Staged changes from context above
   • Check for sensitive information (passwords, API keys, etc.)
   • Verify that the changes are complete and coherent
   • If issues are found, confirm with the user before proceeding

2. Determine the commit message language:

   • Based on the Recent commits from context above
   • If the majority are in English, write in English
   • If the majority are in Japanese, write in Japanese
   • If $ARGUMENTS includes a language instruction, follow that instead

3. Create and execute the commit:

   • Refer to the Commit Message Guidelines section below when writing the message
   • Use git commit -m with an appropriate message

4. Verify the commit was successful:

   • Execute git status to verify the commit was successful
   • Provide a summary of what was committed to the user

Commit Message Guidelines

• Follow the Conventional Commits specification:

  • Format: <type>(optional scope): <description>
  • Example: feat(auth): add OAuth2 login support

• Allowed types: feat, fix, docs, style, refactor, perf, test, chore

• Use the imperative mood in the description (e.g., "add", not "added" or "adds").

• Keep the summary concise (max ~72 characters).

• Body rules:

  • Always include a body — no exceptions, even for trivial-looking changes

  • Insert one blank line after the summary, then write the body

  • The body must be written as bullet points — never use prose paragraphs or a single free-form line

  • Each bullet should describe a reason, context, or detail of the change

  • Example:

    feat(auth): add OAuth2 login support
    
    - implement login with OAuth2
    - update user model with providerId
    - add tests for OAuth2 flow
    

• Language rule:

  • Use the same language as the majority of recent commits
  • If $ARGUMENTS includes a language instruction, follow that instead
  • Scope language matches the message language: for Japanese commits, the scope may also be written in Japanese (e.g., feat(認証): OAuth2 ログインを追加). For English commits, keep the scope in English.

• Focus rule:

  • Do not write vague phrases like "fixed review comments", or "minor fix".
  • Always describe what was actually changed (e.g., "remove unused import", "fix null check in auth flow").

• Arguments rule:

  • Treat $ARGUMENTS as additional context or instruction for the commit message

HEREDOC Handling for Commit Messages

When composing a multi-line commit message with git commit -m "$(cat <<...EOF ... EOF)", the HEREDOC quoting style affects how backticks are interpreted:

• Single-quoted HEREDOC (<<'EOF'): No shell expansion happens, so write raw backticks directly (e.g., inline `functionName` or `file.ts` is safe)
• Double-quoted or unquoted HEREDOC (<<"EOF" / <<EOF): Bash may interpret backticks as command substitution. Avoid inline single backticks — use triple-backtick fenced blocks (```) if a code span is needed

Rationale: In double-quoted/unquoted HEREDOC, backticks sometimes get auto-escaped as \`, which leaks literal backslashes into the commit message.

Recommendation: Prefer <<'EOF' whenever the commit message contains backticks or code identifiers — it is the safest default.

Important Notes

• Do not execute git add
• The changes are already staged with the correct granularity and responsibility.
• Do not execute git push