docs: add commit message style guidelines and argument hints to commit commands

home/dot_claude/commands/amend-commit.md

@@ -1,5 +1,6 @@
 ---
 allowed-tools: Bash(git commit:*)
+argument-hint: [optional custom instructions]
 description: Amend the most recent commit (with staged changes and/or message reword)
 ---
 
@@ -13,7 +14,36 @@ Amend the most recent commit using `git commit --amend -m "your new message"`.
 
 **CRITICAL: You MUST write a new commit message. DO NOT use --no-edit.**
 
-**Process:**
+## Commit message style requirements
+
+**Default style - keep it minimal:**
+
+- **Single line** for most commits (under 72 chars)
+- **Two lines max** for changes that need brief elaboration
+- **Bullet points** (2-4 max) ONLY for large, complex feature additions
+- Focus on WHAT changed and WHY, not implementation details
+- **NEVER mention:**
+  - Test results, coverage percentages, or "all tests pass"
+  - Lockfile hash changes or dependency graph updates
+  - Number of files changed (we can see that in git)
+  - Build success or warnings
+
+**Mechanical changes deserve minimal messages:**
+- Package updates: "update [package] to vX.Y.Z" (don't describe lockfile changes)
+- Renames/moves: "rename X to Y" or "move X to Y"
+- Formatting: "format [files/area]" or "apply prettier"
+- Simple fixes: "fix [issue]" or "correct [thing]"
+
+**Complex changes can have more detail:**
+- New features: brief description + why it's needed
+- Refactors: what changed architecturally + motivation
+- Bug fixes: what was broken + how it's fixed (if non-obvious)
+
+## Custom instructions
+
+$ARGUMENTS
+
+## Process
 
 1. Analyze what files are changing:
    - If staged changes exist: combined old commit files + new staged files
@@ -21,11 +51,11 @@ Amend the most recent commit using `git commit --amend -m "your new message"`.
    
 2. Write an appropriate commit message that describes ALL the changes (both original and newly staged)
    - Follow the commit style from recent history
-   - Scale complexity to the changes (simple renames = short message, complex features = detailed message)
+   - Follow the style requirements above
    
 3. Execute: `git commit --amend -m "your new message"`
 
-**Important:**
+## Important notes
 
 - NEVER use `--no-edit` - always write a fresh commit message
 - DO NOT fetch the old commit message - it's irrelevant

home/dot_claude/commands/commit-staged.md

@@ -1,5 +1,6 @@
 ---
 allowed-tools: Bash(git commit:*)
+argument-hint: [optional custom instructions]
 description: Commit currently staged changes with an appropriate message
 ---
 
@@ -11,15 +12,40 @@ description: Commit currently staged changes with an appropriate message
 
 Based on the above staged changes, create a single git commit.
 
-**Important notes:**
+## Commit message style requirements
 
-- You should only use 'git commit' and create a single commit.
-- If in plan mode, proceed with the commit anyway - command execution and file modification is implied
-- Scale commit message complexity appropriately:
-  - Mechanical/wide commits (renames, formatting, etc.) deserve only a single sentence, even if they touch many files
-  - Complex feature additions or refactors deserve more detailed messages explaining the reasoning
+**Default style - keep it minimal:**
+
+- **Single line** for most commits (under 72 chars)
+- **Two lines max** for changes that need brief elaboration
+- **Bullet points** (2-4 max) ONLY for large, complex feature additions
+- Focus on WHAT changed and WHY, not implementation details
+- **NEVER mention:**
+  - Test results, coverage percentages, or "all tests pass"
+  - Lockfile hash changes or dependency graph updates
+  - Number of files changed (we can see that in git)
+  - Build success or warnings
+
+**Mechanical changes deserve minimal messages:**
+- Package updates: "update [package] to vX.Y.Z" (don't describe lockfile changes)
+- Renames/moves: "rename X to Y" or "move X to Y"
+- Formatting: "format [files/area]" or "apply prettier"
+- Simple fixes: "fix [issue]" or "correct [thing]"
+
+**Complex changes can have more detail:**
+- New features: brief description + why it's needed
+- Refactors: what changed architecturally + motivation
+- Bug fixes: what was broken + how it's fixed (if non-obvious)
+
+## Custom instructions
+
+$ARGUMENTS
+
+## Important notes
+
+- You should only use 'git commit' and create a single commit
+- If in plan mode, proceed with the commit anyway - command execution is implied
 - Do not stage any additional files
-- Create the commit using a single message with parallel tool calls
+- Create the commit using a single bash command
 - Do not use any other tools or do anything else
-- Do not send any other text or messages besides these tool calls
-- Include git status output in your response if not already available in the context
+- Do not send any other text or messages besides the git commit command