// MUST be used for ANY git workflow that involves committing code. This includes explicit commit requests AND implicit ones like 'ship it', 'wrap it up', or finishing implementation work. Handles staging, message generation, validation, and commit execution with conventional commit format.
| name | git-commit-validator |
| description | MUST be used for ANY git workflow that involves committing code. This includes explicit commit requests AND implicit ones like 'ship it', 'wrap it up', or finishing implementation work. Handles staging, message generation, validation, and commit execution with conventional commit format. |
| allowed-tools | ["Bash(git status:*)","Bash(git diff:*)","Bash(git add:*)","Bash(git log:*)","Read","Grep"] |
This skill MUST be invoked whenever you are about to create a git commit. It handles the complete workflow and enforces commit message standards.
Auto-invoke this skill when the user implies code should be committed:
| Category | Trigger Phrases |
|---|---|
| Explicit commit | "commit", "make a commit", "commit this" |
| Ship intent | "ship it", "send it" |
| Finalization | "wrap it up", "finalize this", "we're done", "that's it" |
| After implementation | When you complete work and there are uncommitted changes |
Key insight: If the user's intent results in git commit being run, this skill MUST be used first.
Do NOT run git commit without this skill.
git status # See what's changed
git diff HEAD # See all changes (staged + unstaged)
git log --oneline -5 # Recent commit style reference
If git status --porcelain returns empty AND nothing is staged:
This prevents errors from running git commit with nothing staged.
Default behavior - stage all changes:
git add -A
If user specifies --staged - skip staging, use only what's already staged.
If user gives instructions - follow them:
Based on the diff, determine:
Message Format:
<type>[optional scope]: <description>
[body - required for non-trivial changes]
[optional footer - breaking changes, issue refs]
The body is NOT optional for most real work. Use this matrix:
| Change Type | Body Required? | Body Content |
|---|---|---|
| Typo fix, single-line change | No | Subject is sufficient |
| Config tweak, version bump | No | Subject is sufficient |
| Bug fix | YES | What caused it, how you fixed it |
| New feature | YES | What it does, why it's needed, key design choices |
| Refactor | YES | What changed structurally, why this approach |
| Multiple files changed | YES | What each area of change accomplishes |
| Breaking change | YES | What breaks, migration path |
| Performance improvement | YES | What was slow, what's faster, by how much |
Good body content includes:
Use bullet points when listing multiple changes:
- Add validation for email format
- Refactor user service to async
- Update tests for new behavior
Wrap at 72 characters - hard requirement for git tooling compatibility.
| Diff Size | Expected Message |
|---|---|
| 1-10 lines | Subject only (if truly trivial) |
| 10-50 lines | Subject + 1-2 sentence body |
| 50-200 lines | Subject + paragraph or bullets |
| 200+ lines | Subject + detailed body with sections |
When in doubt, write more. A detailed commit message is a gift to future developers (including yourself).
Validation runs automatically when you execute git commit. The commit_quality_enforcer hook intercepts the command and validates:
<type>[scope]: <description>If validation fails, the commit is blocked with a clear error message. Fix the issues and retry.
Use HEREDOC for proper formatting:
git commit -m "$(cat <<'EOF'
type: description here
EOF
)"
<type>[scope]: <description>| Type | Use For |
|---|---|
feat | New feature or capability |
fix | Bug fix |
docs | Documentation only |
refactor | Code restructuring (no behavior change) |
perf | Performance improvement |
test | Test additions/fixes |
chore | Maintenance, deps |
ci | CI/CD changes |
build | Build system changes |
style | Formatting (no logic change) |
revert | Reverting previous commit |
docs: fix typo in readme
chore: bump lodash to 4.17.21
fix(api): resolve timeout on large file uploads
Requests over 10MB were hitting the default 30s timeout.
Increased timeout to 5 minutes for upload endpoints and added
progress tracking to prevent connection drops.
feat(auth): add password reset via email
Users can now request a password reset link sent to their
registered email. Link expires after 1 hour.
- Add /auth/forgot-password endpoint
- Add /auth/reset-password endpoint with token validation
- Integrate SendGrid for transactional emails
- Add rate limiting (3 requests per hour per email)
refactor(database): migrate from callbacks to async/await
The callback-based database layer was causing pyramid-of-doom
issues and making error handling inconsistent across services.
Changes:
- Convert all db methods to return Promises
- Update 47 call sites across 12 service files
- Add connection pool management with proper cleanup
- Standardize error types (DbConnectionError, DbQueryError)
This unblocks the upcoming transaction support work.
feat(hooks): add pre-delegation context injection
Problem: Agents were receiving prompts without project context,
leading to inconsistent code style and missed conventions.
Solution: SessionStart hook now injects a delegation template
into Claude's context that gets included with every Agent() call.
Template includes:
- 7 sections covering task, context, expected output
- MUST DO / MUST NOT constraints
- Verification checklist
This standardizes agent output quality across all delegations.
Commit messages reflect intent and ownership of the change. AI attribution:
The human owns the commit. The tool is irrelevant.
Note: This skill handles COMMIT only. Push must be requested separately.
How to handle code review feedback with technical rigor. Use when receiving review comments from code-reviewer agent, PR reviews, or external feedback. Triggers on: 'review feedback', 'address review', 'fix review comments', 'code review response'.
Systematic TDD methodology for writing tests first. Use when implementing features or fixes with OMC_TDD_MODE enabled, when unsure how to structure tests, or when test-first discipline needs reinforcement. Triggers on: 'tdd', 'test first', 'test driven', 'red green refactor'.
Evidence-based verification methodology before claiming work is complete. Use when about to claim work is done, before committing, before creating PRs, or when verification-reminder hook fires. Triggers on: 'verify', 'verification', 'is it done', 'complete', 'ready to merge'.
Methodology for creating effective skills using TDD principles. Use when creating new skills, editing existing skills, or authoring plugin components. Triggers on: 'create skill', 'write skill', 'new skill', 'skill authoring'.
Systematic debugging methodology for diagnosing failures and root cause analysis. Triggers on: 2+ failed fix attempts, 'ultradebug', 'uld', debugging in circles, complex system failures, intermittent bugs.
Initialize or migrate to nested CLAUDE.md structure for progressive disclosure. Claude auto-loads CLAUDE.md from any directory it reads, enabling true contextual guidance. Triggers on: '/init-deep', 'deep init', 'initialize deeply', 'setup claude deeply', 'refactor claude.md', 'migrate claude.md', 'nested claude', 'progressive disclosure'.