commit-detection
npx machina-cli add skill fusengine/agents/commit-detection --openclawCommit Type Detection Skill
Expert knowledge for detecting the optimal conventional commit type.
Detection Algorithm
Step 1: Gather Data
# Get modified files
git diff --name-only
git diff --staged --name-only
# Get change statistics
git diff --stat
git diff --staged --stat
# Check for keywords in diff
git diff | grep -i "fix\|bug\|error" | head -5
Step 2: Categorize Files
| Category | File Patterns |
|---|---|
| docs | *.md, *.txt, *.rst, README*, CHANGELOG* |
| test | *.test.*, *.spec.*, __tests__/*, test/* |
| config | *.json, *.yml, *.yaml, *.toml, .*rc |
| ci | .github/*, .gitlab-ci.yml, Jenkinsfile |
| build | package.json, Makefile, webpack.*, vite.* |
| style | Only whitespace, formatting changes |
| src | *.ts, *.js, *.py, *.go, *.rs, etc. |
Step 3: Apply Rules
IF only docs files changed:
→ docs
IF only test files changed:
→ test
IF only config/build files changed:
→ chore
IF only CI files changed:
→ ci
IF diff contains "fix", "bug", "error", "issue", "resolve":
→ fix
IF new files added with business logic:
→ feat
IF files renamed/moved without logic change:
→ refactor
IF performance keywords ("optimize", "perf", "speed", "cache"):
→ perf
IF formatting only (whitespace, semicolons):
→ style
DEFAULT:
→ Use /commit-pro:commit for smart analysis
Step 4: Determine Scope
Extract scope from primary directory:
src/components/Button.tsx → ui or button
src/api/auth.ts → auth
lib/utils/date.ts → utils
server/routes/user.ts → user
Quick Reference
| Type | When | Version Bump |
|---|---|---|
feat | New functionality | PATCH |
fix | Bug correction | PATCH |
docs | Documentation only | PATCH |
style | Formatting only | PATCH |
refactor | Code restructure | PATCH |
perf | Performance | PATCH |
test | Tests only | PATCH |
build | Build/deps | PATCH |
ci | CI/CD config | PATCH |
chore | Maintenance | PATCH |
MINOR/MAJOR bumps are manual user decisions, never automatic.
Post-Commit Actions
See the post-commit skill for universal CHANGELOG, version bump, and tag logic (works for all repos).
Examples
Example 1: Only README changed
Files: README.md
→ /commit-pro:docs
Example 2: New component + test
Files: src/Button.tsx, src/Button.test.tsx
→ /commit-pro:feat (primary is new feature)
Example 3: Fix in existing file
Files: src/api/auth.ts
Diff contains: "fix login bug"
→ /commit-pro:fix
Source
git clone https://github.com/fusengine/agents/blob/main/plugins/commit-pro/skills/commit-detection/SKILL.mdView on GitHub Overview
This skill analyzes git changes to pick the best conventional commit type. It gathers diff data, categorizes files by pattern, and applies rules to determine whether a change is feat, fix, docs, style, refactor, perf, test, build, ci, or chore. It helps maintain a clean, consistent history before committing.
How This Skill Works
Technically, it collects data using git diff and git diff --stat, then classifies files by patterns (docs, test, config, ci, build, style, src). It applies conditional rules based on keywords like fix/bug/error and the presence of new business-logic files to select the appropriate commit type, defaulting to a smart analysis path if no clear match. Scope can be inferred from primary directories to aid message clarity.
When to Use It
- When analyzing what a set of changes should be labeled as in a conventional commit.
- When determining the commit type before making a commit to ensure consistent history.
- During code review to quickly summarize the nature of changes for the team.
- Before releasing or tagging to align release notes with the commit types.
- When auditing commit history to assign or validate classification retroactively.
Quick Start
- Step 1: Gather data with git diff --name-only, git diff --stat, and grep for keywords.
- Step 2: Categorize changed files by patterns (docs, test, config, src, etc.) and apply rules to pick a type.
- Step 3: Use the suggested type in your commit message or defer to /commit-pro:commit for smart analysis.
Best Practices
- Run the detection before committing to ensure the message aligns with the actual change.
- Keep file-pattern awareness: docs vs. code vs. config to improve type accuracy.
- Watch for keywords like fix, bug, error in diffs to trigger fix/feat distinctions.
- If new files add business logic, favor feat to reflect new functionality.
- When unclear, fall back to the smart default path (/commit-pro:commit) and review manually.
Example Use Cases
- Files: README.md → /commit-pro:docs
- Files: src/Button.tsx, src/Button.test.tsx → /commit-pro:feat (primary is new feature)
- Files: src/api/auth.ts Diff contains: "fix login bug" → /commit-pro:fix
- Files: tests/__tests__/auth.test.ts → /commit-pro:test
- Files: .github/workflows/ci.yml → /commit-pro:ci
