Files
website-enchun-mgr/.claude/commands/git-commit.md

3.8 KiB

description
description
Execute a git commit following repository guidelines, analyzing changes and drafting a meaningful commit message.

The user input to you can be provided directly by the agent or as a command argument - you MUST consider it before proceeding with the prompt (if not empty).

User input:

$ARGUMENTS

When the user invokes /git-commit, follow these steps carefully to create a new git commit:

  1. You have the capability to call multiple tools in a single response. ALWAYS run the following bash commands in parallel, each using the Bash tool:
    • Run git status to see all untracked files.
    • Run git diff to see both staged and unstaged changes that will be committed.
    • Run git log --oneline -10 to see recent commit messages, so that you can follow this repository's commit message style.

Provide descriptions for each:

  • git status: Shows working tree status
  • git diff: Displays unstaged changes
  • git log --oneline -10: Lists last 10 commit messages
  1. Analyze all staged changes (both previously staged and newly added) and draft a commit message. Wrap your analysis process in <commit_analysis> tags:

<commit_analysis>

  • List the files that have been changed or added
  • Summarize the nature of the changes (eg. new feature, enhancement to an existing feature, bug fix, refactoring, test, docs, etc.)
  • Brainstorm the purpose or motivation behind these changes
  • Assess the impact of these changes on the overall project
  • Check for any sensitive information that shouldn't be committed
  • Draft a concise (1-2 sentences) commit message that focuses on the "why" rather than the "what"
  • Ensure your language is clear, concise, and to the point
  • Ensure the message accurately reflects the changes and their purpose (i.e. "add" means a wholly new feature, "update" means an enhancement to an existing feature, "fix" means a bug fix, etc.)
  • Ensure the message is not generic (avoid words like "Update" or "Fix" without context)
  • Review the draft message to ensure it accurately reflects the changes and their purpose </commit_analysis>

Use the git context at the start of this conversation to determine which files are relevant to your commit. Be careful not to stage and commit files (e.g. with git add .) that aren't relevant to your commit.

  1. You have the capability to call multiple tools in a single response. ALWAYS run the following commands in parallel:

    • Add relevant untracked files to the staging area using git add <files>. Stage only relevant changes based on the analysis.
    • Run git status to make sure the staging succeeded.
  2. Commit the changes using git commit -m "<drafted message>". If the user provided arguments, incorporate them into the message if appropriate.

  3. If the commit fails due to pre-commit hook changes, retry the commit ONCE to include these automated changes using git commit -m "<message>" --no-verify or similar if needed. If it fails again, report the error. If the commit succeeds but files were modified by the pre-commit hook, amend the commit using git commit --amend -m "<updated message>" to include them.

Important notes:

  • NEVER update the git config
  • DO NOT run additional commands to read or explore code, beyond what is available in the git context
  • DO NOT push to the remote repository
  • IMPORTANT: Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported.
  • If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit. Instead, output: "No changes to commit."
  • Ensure your commit message is meaningful and concise. It should explain the purpose of the changes, not just describe them.
  • Return an empty response - the user will see the git output directly. If no commit was made, briefly explain why.

Use absolute paths and avoid changing directories unnecessarily.