| name | git-hygiene |
| description | Project-agnostic skill for git commit hygiene, linking tasks to commits, and maintaining clean repository state. |
Git Hygiene Skill
Core Principle
Never leave uncommitted files after task completion.
- Each task = one commit (clear traceability)
- Commits link to tasks via task ID references
- Clean repository state between sessions
- Atomic changes that can be reviewed and reverted independently
Commit Message Format
Standard Format:
[task-id] Brief description (imperative mood, <70 chars)
Optional longer explanation if needed:
- Why this change was made
- What problems it solves
- Any breaking changes or important context
Examples:
Good:
[task-38.1] Archive CLAUDE.md before refactoring
Preserving original documentation structure before migration to new format.
[task-12.3] Add user authentication middleware
Implements JWT-based auth for protected routes. Middleware validates tokens
and attaches user context to request object.
[task-5.2] Fix paragraph spacing in essay typography
Bad (avoid):
Updated files # No task reference, vague
[task-12.3] Added some auth stuff # Not imperative, unclear
Fixed bug # No task reference or specificity
Imperative Mood Guide:
- ✅ "Add", "Fix", "Update", "Remove", "Refactor"
- ❌ "Added", "Fixed", "Updated", "Removed", "Refactored"
- Think: "This commit will [your message]"
When to Commit
Commit Immediately After:
- Task Completion - As soon as work is done and verified
- Subagent Work Approval - After reviewing subagent output (don't leave their changes uncommitted)
- Significant Checkpoint - Natural breakpoint in large task (still reference same task ID)
Before:
- Switching Tasks - Never leave Task A uncommitted when starting Task B
- Ending Session - Repository should be clean for next session
- Creating PR - Ensure all work is committed before opening pull request
Never:
- Batch multiple unrelated tasks into one commit
- Leave work uncommitted overnight or between sessions
- Commit mid-task unless it's a natural checkpoint
Linking Commits to Tasks
After every commit, update the task with commit reference:
git add [files]
git commit -m "[task-38.1] Archive CLAUDE.md before refactoring"
git log -1 --format="%H %s"
Task Note Format:
✅ Committed: abc1234 - [task-38.1] Archive CLAUDE.md before refactoring
Why This Matters:
- Traceability: Find code changes from task descriptions
- Debugging: Understand why changes were made
- Handoff: Next session knows what's been completed
- Audit: Track progress and decision history
Pre-Commit Checklist
ALWAYS verify before committing:
git status
git diff --staged
git add path/to/subdir/CLAUDE.md
git commit -m "[task-id] Description"
Files to INCLUDE in Commits:
- Implementation files (code, markdown, config)
- CLAUDE.md updates (if subdirectory work) - Critical for project memory
- Test files (if tests added/modified)
- Documentation updates related to the work
Files to NEVER Commit:
.env, .env.local, .env.production
credentials.json, secrets.yaml, config.private.*
- API keys, tokens, passwords (even in comments)
- Large binary files without LFS
node_modules/, __pycache__/, build artifacts (should be in .gitignore)
If User Requests Committing Secrets:
- Warn explicitly about security risk
- Suggest alternatives (environment variables, secret management)
- Only proceed if user confirms understanding of risk
Branch Strategy
Small Projects / Solo Work:
- Main branch commits - Direct to main for atomic changes
- Fast iteration, low overhead
- Suitable when no team review needed
Team Projects / Large Features:
- Feature branches -
feature/task-38-refactor-claude-md
- Pull request workflow - Review before merge
- Branch naming:
feature/task-[id]-[brief-description]
Branch Commands:
git checkout -b feature/task-38-refactor-claude-md
git add [files]
git commit -m "[task-38.1] Archive CLAUDE.md before refactoring"
git push -u origin feature/task-38-refactor-claude-md
gh pr create --title "[task-38] Refactor CLAUDE.md structure" --body "..."
Never Do (Critical Safety Rules)
Destructive Operations:
- ❌
git push --force (unless user explicitly requests and understands risk)
- ❌
git push --force to main/master (warn user even if requested)
- ❌
git reset --hard without confirming uncommitted work is backed up
- ❌
git clean -fd without user confirmation
Security:
- ❌ Commit files with secrets, credentials, API keys
- ❌ Commit sensitive customer data or PII
- ❌ Override .gitignore to force-add sensitive files
Workflow:
- ❌ Leave work uncommitted between sessions (creates confusion)
- ❌ Batch unrelated tasks into single commit (breaks traceability)
- ❌ Skip task-commit linking (loses context)
- ❌ Use
git commit --amend unless user explicitly requests (can cause confusion with remotes)
Git Config:
- ❌ Modify git config (user.name, user.email) without explicit user request
- ❌ Skip commit hooks (--no-verify) unless user explicitly requests
Troubleshooting Common Issues
Uncommitted Work Before Switching Tasks:
git add [files]
git commit -m "[task-X] Brief description"
git stash save "WIP: task-X incomplete work"
Committed to Wrong Branch:
git reset HEAD~1
git stash
git checkout correct-branch
git stash pop
git commit -m "[task-id] Description"
Accidentally Staged Secrets:
git reset HEAD .env
git reset HEAD~1
git add [files]
git commit -m "[task-id] Description"
Quality Verification
Before Marking Task Complete:
- ✅ Work committed with proper task reference
- ✅ Commit message follows format (imperative mood, <70 chars)
- ✅ Task updated with commit hash in notes
- ✅ CLAUDE.md updated and committed (if subdirectory work)
- ✅
git status shows clean working directory
- ✅ No secrets or credentials in committed files
- ✅ Tests pass (if applicable)
- ✅ Linting passes (if applicable)
Session End Checklist:
git status
git log --oneline -5
git push
Integration with Task Management
Task Creation → Implementation → Commit → Link:
- Create task with clear description and acceptance criteria
- Mark task in progress when starting work
- Implement changes following task requirements
- Commit with task reference in message
- Update task notes with commit hash
- Mark task complete after verification
Example Workflow:
git add src/search.js tests/search.test.js
git commit -m "[task-42] Add search functionality
Implements full-text search with fuzzy matching and filtering."
This creates complete traceability: Task → Code → Commit → Verification.