58 lines
3.8 KiB
Markdown
58 lines
3.8 KiB
Markdown
---
|
|
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
|
|
|
|
2. 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.
|
|
|
|
3. 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.
|
|
|
|
4. Commit the changes using `git commit -m "<drafted message>"`. If the user provided arguments, incorporate them into the message if appropriate.
|
|
|
|
5. 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.
|