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