home / skills / fusengine / agents / commit-detection

This skill detects the optimal commit type from git changes to streamline messaging and versioning.

npx playbooks add skill fusengine/agents --skill commit-detection

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.5 KB
---
name: commit-detection
description: Detects optimal commit type from git changes. Use when analyzing commits, determining commit type, or before committing.
allowed-tools: Bash, Read, Grep
---

# Commit Type Detection Skill

Expert knowledge for detecting the optimal conventional commit type.

## Detection Algorithm

### Step 1: Gather Data

```bash
# 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 |
|------|------|
| `feat` | New functionality |
| `fix` | Bug correction |
| `docs` | Documentation only |
| `style` | Formatting only |
| `refactor` | Code restructure |
| `perf` | Performance |
| `test` | Tests only |
| `build` | Build/deps |
| `ci` | CI/CD config |
| `chore` | Maintenance |

## 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
```

Overview

This skill detects the optimal conventional commit type from Git changes to produce consistent, actionable commit messages. It analyzes file lists, diffs, keywords, and file categories to map changes to commit types like feat, fix, docs, or chore. The output includes an inferred scope when possible to improve commit clarity.

How this skill works

The skill gathers modified, staged, and new files plus diff statistics to inspect change content. It categorizes files (docs, test, config, ci, build, style, src) and searches diffs for keywords such as fix, bug, optimize, or formatting indicators. A rule set maps file categories and keywords to conventional commit types and extracts a scope from primary directory paths. If rules are ambiguous, it falls back to a smart analysis mode for a more contextual decision.

When to use it

  • Before creating a commit to determine the correct conventional commit type and scope.
  • When reviewing a pull request to label changes consistently.
  • As part of CI checks to validate commit message categories.
  • When enforcing a commit convention across a team or repository.
  • During automated changelog generation to classify entries.

Best practices

  • Run the detection on both staged and unstaged changes to capture full context.
  • Prefer the most specific rule match (e.g., docs-only over chore) to avoid misclassification.
  • Extract scope from the primary directory path to keep commit messages focused and discoverable.
  • Treat formatting-only diffs as style and avoid combining format changes with functional edits in one commit.
  • When in doubt, use the smart analysis fallback to evaluate intent across files and diffs.

Example use cases

  • README.md edited alone → docs commit to update project documentation.
  • src/api/auth.ts changed with 'fix login bug' in diff → fix commit with scope 'auth'.
  • New UI component plus tests added → feat commit with scope derived from src/components.
  • Only CI configuration files changed → ci commit to document pipeline updates.
  • Whitespace/semicolon formatting across files → style commit to isolate formatting changes.

FAQ

How does the skill decide scope?

It extracts the primary directory or filename from the path (e.g., src/api/auth.ts → auth or api) and uses that as the commit scope when meaningful.

What if a change touches docs and code?

If code changes include new functionality or bug fixes, the skill prioritizes feat or fix. If changes are strictly documentation, it returns docs; mixed changes favor the primary functional change.