smart-commit
Smart Commit enforces code quality before creating Git commits by running linters, type checkers, and tests on affected files, scanning staged changes for debugging statements and untracked issues, and generating conventional commit messages. Use this when ready to commit changes after development work.
git clone --depth 1 https://github.com/rohitg00/pro-workflow /tmp/smart-commit && cp -r /tmp/smart-commit/skills/smart-commit ~/.claude/skills/smart-commitSKILL.md
# Smart Commit
## Trigger
Use when saying "commit", "save changes", or ready to commit after making changes.
## Workflow
1. Check current state and identify what to commit.
2. Run quality gates (lint, typecheck, tests on affected files).
3. Scan staged changes for issues.
4. Draft a conventional commit message from the diff.
5. Stage specific files, create the commit.
6. Prompt for learnings from this change.
## Commands
```bash
git status
git diff --stat
npm run lint 2>&1 | tail -5
npm run typecheck 2>&1 | tail -5
npm test -- --changed --passWithNoTests 2>&1 | tail -10
git add <specific files>
git commit -m "<type>(<scope>): <summary>"
```
## Code Review Scan
Before committing, check staged changes in **production code** (not test files) for:
- `console.log` / `debugger` statements (suppressed in test files — see Review Suppressions)
- TODO/FIXME/HACK comments without ticket references (e.g., `TODO(JIRA-123)` is fine)
- Hardcoded secrets or API keys
- Leftover test-only code
Flag any issues before proceeding.
## Commit Message Format
```
<type>(<scope>): <short summary>
<body - what changed and why>
```
**Types:** feat, fix, refactor, test, docs, chore, perf, ci, style
## Guardrails
- Never skip quality gates unless user explicitly says to.
- Stage specific files by name. Never `git add -A` or `git add .`.
- Summary under 72 characters. Body explains *why*, not *what*.
- No generic messages ("fix bug", "update code").
- Reference issue numbers when applicable.
## Output
- Quality gate results (pass/fail)
- Issues found in staged changes
- Suggested commit message
- Commit hash after committing
- Prompt: any learnings to capture?
## Review Suppressions
Do NOT flag these during the pre-commit scan. They add noise without catching real bugs:
- Threshold, config value, or feature flag changes (limits, timeouts, retry counts)
- Import reordering that does not change runtime behavior
- Whitespace-only or formatting-only changes
- Adding or removing `console.log` in test files
- TODO/FIXME comments (tracked separately in issue trackers)
- Variable or parameter renames that do not change behaviorAnalyzes and optimizes context window usage across sessions. Use when context feels bloated, sessions run slow, or approaching compaction limits.
Analyze session token usage and cost patterns. Identify expensive operations and recommend optimizations. Use to understand and reduce session costs.
Specialized debugging agent. Use when facing hard bugs, test failures, or runtime errors that need systematic investigation.
Multi-phase development agent. Research > Plan > Implement with validation gates. Use PROACTIVELY when building features that touch >5 files or require architecture decisions.
Analyze permission denial patterns and generate optimized alwaysAllow/alwaysDeny rules. Use when permission prompts slow down workflow.
Break down complex tasks into implementation plans before writing code. Use when task touches >5 files, requires architecture decisions, or has unclear requirements.
Code review specialist that verifies every finding against actual code before reporting. Use before committing, for PR reviews, or after major changes.
Confidence-gated exploration that assesses readiness before implementation. Scores 0-100 across five dimensions and gives GO/HOLD verdict.