1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43---
title: 'Git Commit Task'
read_only: true
type: 'command'
---
# Create new git commit task
- Takes all staged changes, suggests a commit message, ALWAYS asks for confirmation, and creates the commit ONLY after explicit approval
- This task is one of ONLY two places where committing is allowed (the other being commit-fast)
- Format of commit message depends on the affected files:
- For package changes: `package: Description of changes`
- For configuration files in root or specialized directories:
- ESLint config: `ESLint: Description of changes`
- TypeScript config: `TypeScript: Description of changes`
- Git-related files: `gitignore: Description of changes`
- Claude related files (e. g. CLAUDE.md or changes in .claude folder): `Claude: Description of changes`
- Other root configs: use an appropriate descriptor before the colon
- For functionality spanning multiple packages: use the functionality name as scope
- Golden rule: Use package names for package changes, otherwise use functionality/directory scope
- If 80% or more changes are focused on a single feature/functionality, mention only the main package(s) and ignore minor related changes
- Description should start with uppercase letter
- Description should be concise, professional, have a neutral tone, and explain what was changed and, if possible, why
- Commit messages should be based only on staged files
- Always provide at least 5 message options in a numbered list; I will choose one or request a different option
- When suggesting commit messages, use `git log -n 100 --oneline` to review the most recent commit messages for inspiration on format and style
- If there are no staged changes, abort the process with a message in red text: "No changes staged for commit. Aborting."
- NEVER ask about staging files - assume all files I want to commit are already staged
- NEVER use git add commands - you are forbidden from staging files yourself
- NEVER proceed with `git commit -m` without explicit confirmation from me first
- Only after I explicitly confirm or modify the commit message, proceed with `git commit -m "message"`
- If I tell you that you can push the changes, you can run `git push` directly without asking for permission
- Do NOT add Claude co-authorship footer to commits
- Read ONLY staged files
## Examples of Good Commit Messages
- components/Header: Fix username retrieval issues on initial render
- alerts: New notification module for system and maintenance type of alerts
- queue-payment-processing: Moved generateMonthlyStatementJob to queue from admin
- admin: New action for creating manual adjustments in user profile
- og_image: Add `OgImageGenerator` struct