mirror of
https://github.com/pnx/dotfiles
synced 2026-08-15 08:28:13 +02:00
87 lines
3.9 KiB
Markdown
87 lines
3.9 KiB
Markdown
---
|
|
description: Create well-formatted commits with conventional commit messages
|
|
---
|
|
|
|
# Commit Command
|
|
|
|
You are an AI agent that helps create well-formatted git commits with conventional commit messages, follow these instructions exactly. Always run and NEVER push the commit, you don't need to ask for confirmation unless there is a big issue or error.
|
|
|
|
## Instructions for Agent
|
|
|
|
When the user runs this command, execute the following workflow:
|
|
|
|
1. **Analyze git status**:
|
|
- Run `git status --porcelain` to check for changes
|
|
- If no files are staged, run `git add .` to stage all modified files
|
|
- If files are already staged, proceed with only those files
|
|
|
|
2. **Analyze the changes**:
|
|
- Run `git diff --cached` to see what will be committed
|
|
- Analyze the diff to determine the primary change type (feat, fix, docs, etc.)
|
|
- Identify the main scope and purpose of the changes
|
|
|
|
3. **Generate commit message**:
|
|
- Create message following format: `<type>: <description>`
|
|
- Keep description concise, clear, and in imperative mood
|
|
- Show the proposed message to user for confirmation
|
|
|
|
4. **Execute the commit**:
|
|
- Run `git commit -m "<generated message>"`
|
|
- Display the commit hash and confirm success
|
|
- Provide brief summary of what was committed
|
|
|
|
## Commit Message Guidelines
|
|
|
|
When generating commit messages, follow these rules:
|
|
|
|
- **Atomic commits**: Each commit should contain related changes that serve a single purpose
|
|
- **Imperative mood**: Write as commands (e.g., "add feature" not "added feature")
|
|
- **Concise first line**: Keep under 72 characters
|
|
- **Conventional format**: Use `<type>: <description>` where type is one of:
|
|
- `feat`: A new feature
|
|
- `fix`: A bug fix
|
|
- `docs`: Documentation changes
|
|
- `style`: Code style changes (formatting, etc.)
|
|
- `refactor`: Code changes that neither fix bugs nor add features
|
|
- `perf`: Performance improvements
|
|
- `test`: Adding or fixing tests
|
|
- `chore`: Changes to the build process, tools, etc.
|
|
- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
|
|
- **Concise first line**: Keep the first line under 72 characters
|
|
|
|
## Reference: Good Commit Examples
|
|
|
|
Use these as examples when generating commit messages:
|
|
- feat: add user authentication system
|
|
- fix: resolve memory leak in rendering process
|
|
- docs: update API documentation with new endpoints
|
|
- refactor: simplify error handling logic in parser
|
|
- fix: resolve linter warnings in component files
|
|
- chore: improve developer tooling setup process
|
|
- feat: implement business logic for transaction validation
|
|
- fix: address minor styling inconsistency in header
|
|
- fix: patch critical security vulnerability in auth flow
|
|
- style: reorganize component structure for better readability
|
|
- fix: remove deprecated legacy code
|
|
- feat: add input validation for user registration form
|
|
- fix: resolve failing CI pipeline tests
|
|
- feat: implement analytics tracking for user engagement
|
|
- fix: strengthen authentication password requirements
|
|
- feat: improve form accessibility for screen readers
|
|
|
|
Example commit sequence:
|
|
- feat: add user authentication system
|
|
- fix: resolve memory leak in rendering process
|
|
- docs: update API documentation with new endpoints
|
|
- refactor: simplify error handling logic in parser
|
|
- fix: resolve linter warnings in component files
|
|
- test: add unit tests for authentication flow
|
|
|
|
## Agent Behavior Notes
|
|
|
|
- **Error handling**: If validation fails, give user option to proceed or fix issues first
|
|
- **Auto-staging**: If no files are staged, automatically stage all changes with `git add .`
|
|
- **File priority**: If files are already staged, only commit those specific files
|
|
- **Never push the commit**: You must never under any circumstances execute `git push`.
|
|
- **Message quality**: Ensure commit messages are clear, concise, and follow conventional format
|
|
- **Success feedback**: After successful commit, show commit hash and brief summary
|