From oh-my-claude
Manages git commit workflows: checks status and diffs, stages changes selectively, generates and validates conventional commit messages, then executes commits.
npx claudepluginhub techdufus/oh-my-claude --plugin oh-my-claudeThis skill is limited to using the following tools:
This skill MUST be invoked whenever you are about to create a git commit. It handles the complete workflow and enforces commit message standards.
Generates conventional commit messages from git diffs by analyzing changes for type, scope, and subject. Validates messages against spec and executes git commits after confirmation.
Manages Git commit workflow using Conventional Commits format with safety protocols. Creates, validates, executes commits; handles hooks, PRs, and safety checks before operations.
Creates conventional git commits with validation, branch safety checks, local Python/JS linting/formatting/typechecking, change review, and agent attribution. Use for safe commits.
Share bugs, ideas, or general feedback.
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 Task() 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.