feat(commands): add /commit command for conventional commits
Add streamlined commit workflow that analyzes staged changes and generates conventional commit messages (feat:, fix:, etc.) with user approval before committing. Closes #18 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit was merged in pull request #78.
This commit is contained in:
86
commands/commit.md
Normal file
86
commands/commit.md
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
description: Create a commit with an auto-generated conventional commit message. Analyzes staged changes and proposes a message for approval.
|
||||
argument-hint:
|
||||
---
|
||||
|
||||
# Commit Changes
|
||||
|
||||
## Process
|
||||
|
||||
1. **Check for staged changes**:
|
||||
```bash
|
||||
git diff --staged --stat
|
||||
```
|
||||
|
||||
If no staged changes, inform the user and suggest staging files first:
|
||||
- Show unstaged changes with `git status`
|
||||
- Ask if they want to stage all changes (`git add -A`) or specific files
|
||||
|
||||
2. **Analyze staged changes**:
|
||||
```bash
|
||||
git diff --staged
|
||||
```
|
||||
|
||||
Examine the diff to understand:
|
||||
- What files were changed, added, or deleted
|
||||
- The nature of the changes (new feature, bug fix, refactor, docs, etc.)
|
||||
- Key details worth mentioning
|
||||
|
||||
3. **Generate commit message**:
|
||||
|
||||
Create a conventional commit message following this format:
|
||||
```
|
||||
<type>(<scope>): <description>
|
||||
|
||||
[optional body with more details]
|
||||
|
||||
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
||||
```
|
||||
|
||||
**Types:**
|
||||
- `feat`: New feature or capability
|
||||
- `fix`: Bug fix
|
||||
- `refactor`: Code restructuring without behavior change
|
||||
- `docs`: Documentation changes
|
||||
- `style`: Formatting, whitespace (no code change)
|
||||
- `test`: Adding or updating tests
|
||||
- `chore`: Maintenance tasks, dependencies, config
|
||||
|
||||
**Scope:** The component or area affected (optional, use when helpful)
|
||||
|
||||
**Description:**
|
||||
- Imperative mood ("add" not "added")
|
||||
- Lowercase first letter
|
||||
- No period at the end
|
||||
- Focus on the "why" when the "what" is obvious
|
||||
|
||||
4. **Present message for approval**:
|
||||
|
||||
Show the proposed message and ask the user to:
|
||||
- **Approve**: Use the message as-is
|
||||
- **Edit**: Let them modify the message
|
||||
- **Regenerate**: Create a new message with different focus
|
||||
|
||||
5. **Create the commit**:
|
||||
|
||||
Once approved, execute:
|
||||
```bash
|
||||
git commit -m "$(cat <<'EOF'
|
||||
<approved message>
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
6. **Confirm success**:
|
||||
|
||||
Show the commit result and suggest next steps:
|
||||
- Push to remote: `git push`
|
||||
- Continue working and commit more changes
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Only commits what's staged (respects partial staging)
|
||||
- Never auto-commits without user approval
|
||||
- Keep descriptions concise (50 chars or less for first line)
|
||||
- Include body for non-obvious changes
|
||||
- Always include Co-Authored-By attribution
|
||||
Reference in New Issue
Block a user