1  ---
  2  description: Stage all changes, run pre-commit hooks, fix failures, and create conventional commit with emoji
  3  argument-hint: [all | staged | amend | split | dry-run] [message]
  4  allowed-tools: Read, Edit, Write, Bash, Grep, Glob, AskUserQuestion, Task
  5  model: sonnet
  6  ---
  7  
  8  <objective>
  9  Create a well-formatted git commit with conventional commit messages and emoji.
 10  
 11  **Modes:**
 12  
 13  - *(no args)* or `all` - Stage all changes and commit (default)
 14  - `staged` - Commit only already-staged files (skip `git add -A`)
 15  - `amend` - Amend the previous commit (with safety checks)
 16  - `split` - Interactive mode to split changes into multiple commits
 17  - `dry-run` - Preview what would be committed without committing
 18  
 19  **Optional message:** Provide a commit message to skip auto-generation.
 20  
 21  **Examples:**
 22  
 23  - `/commit` - Stage all, generate message, commit
 24  - `/commit staged` - Commit only staged files
 25  - `/commit staged "fix: typo"` - Commit staged with custom message
 26  - `/commit dry-run` - Preview without committing
 27  - `/commit split` - Guide through splitting changes
 28  </objective>
 29  
 30  <context>
 31  Git status: !`git status --short`
 32  Recent commits (for style matching): !`git log --oneline -5`
 33  Pre-commit config exists: !`test -f .pre-commit-config.yaml && echo "yes" || echo "no"`
 34  Staged files: !`git diff --cached --name-only`
 35  </context>
 36  
 37  <process>
 38  
 39  ## Mode Detection
 40  
 41  Parse `$ARGUMENTS` to determine mode and optional message:
 42  
 43  1. **If empty or "all"**: Default mode - stage all, commit
 44  2. **If "staged"**: Skip staging, commit only what's already staged
 45  3. **If "amend"**: Amend previous commit (go to Amend Mode)
 46  4. **If "split"**: Interactive splitting (go to Split Mode)
 47  5. **If "dry-run"**: Preview only, no commit (go to Dry-Run Mode)
 48  6. **Remaining args**: Treat as custom commit message
 49  
 50  ---
 51  
 52  ## Default Mode (all)
 53  
 54  1. **Stage all changes**
 55     - Run `git add -A` to stage all modified, new, and deleted files
 56  
 57  ## Staged Mode
 58  
 59  1. **Verify staged files exist**
 60     - Run `git diff --cached --name-only`
 61     - If empty, report "No staged files" and exit
 62     - Do NOT run `git add -A` - use existing staged files only
 63  
 64  2. **Check for pre-commit hooks**
 65     - If `.pre-commit-config.yaml` exists, run `pre-commit run --all-files`
 66     - If pre-commit is not installed, skip this step
 67  
 68  3. **Handle pre-commit failures**
 69     - If pre-commit fails, spawn a **Haiku subagent** to fix simple issues:
 70  
 71     ```
 72     Task tool with:
 73     - subagent_type: "general-purpose"
 74     - model: "haiku"
 75     - prompt: "Fix pre-commit failures.
 76  
 77       **Errors:**
 78       {paste pre-commit error output}
 79  
 80       **Instructions:**
 81       1. Read failing files
 82       2. Fix formatting, linting, markdown, whitespace issues
 83       3. For security/architectural issues: return as 'escalated'
 84  
 85       **Return JSON:**
 86       {\"fixed\": [\"file1.md\", ...], \"escalated\": [\"security issue in X\", ...]}"
 87     ```
 88  
 89     - If subagent returns escalated issues, spawn **Sonnet subagent**:
 90  
 91     ```
 92     Task tool with:
 93     - subagent_type: "general-purpose"
 94     - model: "sonnet"
 95     - prompt: "Fix complex pre-commit issues requiring reasoning.
 96  
 97       **Escalated issues:**
 98       {paste escalated issues}
 99  
100       **Instructions:**
101       1. Analyze root cause
102       2. Implement fix with explanation
103  
104       **Return:** Summary of changes and reasoning"
105     ```
106  
107     - After fixing, do NOT stage the fixes yet
108  
109  4. **User approval for agent changes**
110     - If any files were modified by pre-commit or by fixing failures:
111       - Run `git diff` to show unstaged changes (these are the agent's fixes)
112       - Use AskUserQuestion to ask user to review the diff
113       - Options: "Approve changes" or "Reject and abort"
114     - If rejected, run `git checkout -- .` to discard fixes and abort
115  
116  5. **Stage fixes and analyze changes**
117     - Run `git add -A` to stage all fixes
118     - Run `git diff --stat --cached` for overview
119     - **For large diffs (>300 lines)**, spawn Haiku subagent to analyze:
120  
121     ```
122     Task tool with:
123     - subagent_type: "general-purpose"
124     - model: "haiku"
125     - prompt: "Analyze staged changes and recommend commit message.
126  
127       **Staged files:**
128       {paste git diff --stat --cached output}
129  
130       **Recent commits (for style):**
131       {paste git log --oneline -5 output}
132  
133       **Instructions:**
134       1. Read key changed files to understand scope
135       2. Summarize the nature of changes (feature, fix, refactor, etc.)
136       3. Match project commit style from recent commits
137       4. Consider if changes should be split
138  
139       **Return:**
140       - Recommended commit message: <emoji> <type>: <description>
141       - Summary of changes (2-3 bullet points)
142       - Split recommendation: yes/no with reasoning"
143     ```
144  
145     - For small diffs: analyze directly without subagent
146  
147  6. **Match project commit style**
148     - Use subagent's analysis or analyze recent commits for: language, emoji usage, format conventions
149     - Follow the existing style (don't impose a standard)
150  
151  7. **Generate commit message**
152     - Use subagent's recommendation or generate based on analysis
153     - Use emoji conventional commit format: `<emoji> <type>: <description>`
154     - First line < 72 characters, imperative mood, present tense
155     - Focus on WHAT changed and WHY, not HOW
156     - For complex changes, use multi-line format with bullet points
157     - Consider if changes should be split into multiple commits
158  
159  8. **Create the commit**
160     - Run `git commit -m "<message>"` using HEREDOC for proper formatting
161     - Verify commit was created successfully with `git log -1`
162  
163  ---
164  
165  ## Amend Mode
166  
167  **Safety checks before amending:**
168  
169  1. Verify HEAD commit was made by user (not a merge commit)
170  2. Verify commit has NOT been pushed to remote: `git status` shows "Your branch is ahead"
171  3. If pushed, WARN and ask for confirmation (requires force push)
172  
173  **Process:**
174  
175  1. Stage changes (all or staged-only based on additional args)
176  2. Run pre-commit hooks
177  3. Show diff of what will be amended
178  4. Use `AskUserQuestion` for confirmation
179  5. Run `git commit --amend` (with `-m` if message provided, otherwise keep existing)
180  6. Verify with `git log -1`
181  
182  ---
183  
184  ## Split Mode
185  
186  Guide user through splitting changes into multiple logical commits.
187  
188  1. **Analyze changes**
189     - Run `git status` to see all changes
190     - Categorize by: file type, concern area, change type (feat/fix/refactor)
191  
192  2. **Propose split strategy**
193     - Suggest how to group changes into separate commits
194     - Example: "I see 3 logical groups: config changes, new feature, test updates"
195  
196  3. **Interactive staging**
197     - For each group, guide user through:
198       - `git add <specific-files>` or `git add -p` for partial staging
199       - Generate commit message for that group
200       - Create commit
201     - Repeat until all changes committed
202  
203  4. **Verify**
204     - Show `git log --oneline -n` for the new commits
205     - Confirm all changes are committed
206  
207  ---
208  
209  ## Dry-Run Mode
210  
211  Preview what would be committed without actually committing.
212  
213  1. **Stage changes** (unless `staged` also specified)
214     - Run `git add -A` to stage all
215  
216  2. **Run pre-commit hooks**
217     - Show what would pass/fail
218     - Do NOT fix failures (just report)
219  
220  3. **Show preview**
221  
222     ```
223     ## Dry-Run Preview
224  
225     **Files to commit:**
226     {git diff --stat --cached}
227  
228     **Proposed commit message:**
229     <emoji> <type>: <description>
230  
231     **Pre-commit status:** PASS / FAIL (details)
232  
233     Run `/commit` to actually commit these changes.
234     ```
235  
236  4. **Unstage if we staged**
237     - If mode was `dry-run` (not `staged dry-run`), run `git reset HEAD` to unstage
238  
239  </process>
240  
241  <commit_types>
242  
243  - ✨ `feat`: New feature
244  - 🐛 `fix`: Bug fix
245  - 📝 `docs`: Documentation
246  - 💄 `style`: Formatting/style
247  - ♻️ `refactor`: Code refactoring
248  - ⚡️ `perf`: Performance improvements
249  - ✅ `test`: Tests
250  - 🔧 `chore`: Tooling, configuration
251  - 🚀 `ci`: CI/CD improvements
252  - 🚨 `fix`: Fix compiler/linter warnings
253  - 🔒️ `fix`: Fix security issues
254  - 🏗️ `refactor`: Architectural changes
255  - 🔥 `fix`: Remove code or files
256  - 🎨 `style`: Improve structure/format
257  - 💚 `fix`: Fix CI build
258  - ✏️ `fix`: Fix typos
259  </commit_types>
260  
261  <splitting_guidance>
262  Consider splitting commits when changes touch:
263  
264  - Different concerns (unrelated parts of codebase)
265  - Different types (mixing features, fixes, refactoring)
266  - Different file patterns (source vs docs vs config)
267  - Large changes that would be clearer if broken down
268  
269  If splitting is needed, guide the user through selective staging with `git add -p` or file-by-file staging.
270  </splitting_guidance>
271  
272  <grep_strategy>
273  Grep is faster than reading entire files. Use it to quickly assess impact before deciding which files to read in detail.
274  
275  **Patterns for analyzing changes:**
276  
277  - Find function/method calls: `grep -n "function_name("`
278  - Count occurrences to gauge scope: `grep -c "pattern" file`
279  - Get context around matches: `grep -C 3 "function_name"`
280  - Find all files with pattern: `grep -l "pattern" --include="*.py"`
281  
282  **When to use grep vs full read:**
283  
284  - Use grep first to identify which files have significant changes
285  - Read full file only when grep shows complex modifications
286  - For simple additions/deletions, grep context is often sufficient
287  - Prioritize reading files with highest match counts (most impactful)
288  </grep_strategy>
289  
290  <success_criteria>
291  
292  - All files staged appropriately
293  - Pre-commit hooks pass (if present)
294  - User approved any agent-made changes
295  - Commit message follows project conventions
296  - Commit message uses emoji conventional commit format
297  - Commit created successfully
298  - No uncommitted changes remain (unless intentionally excluded)
299  </success_criteria>
300  
301  <verification>
302  After commit, verify:
303  - `git status` shows clean working directory
304  - `git log -1 --stat` shows expected changes
305  - Commit message is properly formatted
306  </verification>