40 lines
1.5 KiB
Plaintext
40 lines
1.5 KiB
Plaintext
---
|
|
description:
|
|
globs:
|
|
alwaysApply: true
|
|
---
|
|
# Git Workflow Rules
|
|
|
|
## Zero Autonomy on Git Operations
|
|
- NEVER stage, commit, or push code without explicit user instruction
|
|
- NEVER assume permission to perform git operations
|
|
- If asked about git status, only provide information - do not take action
|
|
|
|
## Commit Protocol (When Explicitly Asked)
|
|
When user requests a commit, follow this exact sequence:
|
|
|
|
1. **Review Phase**:
|
|
- List ALL modified files with their status (M/A/D)
|
|
- List ALL added files that will be staged
|
|
- List ALL deleted files
|
|
- Check for any files that should be included but aren't staged
|
|
|
|
2. **Summary Phase**:
|
|
- Generate commit title (≤50 characters, imperative mood)
|
|
- Create detailed bulleted summary including:
|
|
- Which files were changed and how
|
|
- What logic was modified/added/removed
|
|
- Impact of changes on functionality
|
|
- Purpose statement (e.g., "Fix race condition" → "Patches race condition in user authentication flow")
|
|
|
|
3. **Confirmation Phase**:
|
|
- Present the complete commit message for approval
|
|
- Show exactly what will be committed
|
|
- Wait for explicit confirmation before executing
|
|
- If user rejects, ask for specific changes to the commit message
|
|
|
|
## Git Safety Rules
|
|
- If no changes detected when asked to commit: "No changes detected. Aborting as per Git rules."
|
|
- If conflicts exist, report them but do not resolve without instruction
|
|
- Never force push or use destructive git operations
|
|
- Always use conventional commit format when generating messages |