git-commit - SKILL.md Agent Skill

name: git-commit description: Autonomously analyzes working tree changes, groups files into logical coherent commits, and creates commits following the Commitizen convention argument-hint: [optional commit scope hint] disable-model-invocation: false user-invocable: true allowed-tools: Bash(git add:), Bash(git commit:), Bash(git status:), Bash(git diff:), Bash(git log:*) model: haiku context: fork agent: general-purpose hooks: PreToolUse: - matcher: "Bash" hooks: - type: command command: "./hooks/block-git-add-all.py" timeout: 10 async: false statusMessage: "Validating git command..." once: false - type: command command: "./hooks/block-sensitive-files.py" timeout: 10 async: false statusMessage: "Checking for sensitive files..." once: false - type: command command: "./hooks/block-debug-artifacts.py" timeout: 10 async: false statusMessage: "Checking for debug artifacts..." once: false - type: command command: "./hooks/block-large-files.py" timeout: 10 async: false statusMessage: "Checking for large files..." once: false - type: command command: "./hooks/block-merge-conflicts.py" timeout: 10 async: false statusMessage: "Checking for merge conflict markers..." once: false

Purpose

Fully autonomous skill that analyzes all working tree changes, groups files into logical coherent commits, stages them individually, and creates clean Commitizen-formatted commit messages — without any user interaction.

Context

echo "=== Git Status ==="
git status --short

echo -e "\n=== Unstaged Changes ==="
git diff --stat

echo -e "\n=== Staged Changes ==="
git diff --cached --stat

echo -e "\n=== Recent Commits ==="
git log --oneline -10

Instructions

Workflow

Analyze all changes — review staged, unstaged, and untracked files from the context above
Group files into logical coherent commits — related changes belong together:
- Feature code + its tests + its migration → single commit
- Dependency updates (lockfiles, package manifests) → separate commit
- Documentation changes → separate commit
- Config/tooling changes → separate commit
- Unrelated bug fixes → separate commits
For each group, in dependency order (deps first, then features, then docs):
- Stage specific files: git add <file1> <file2> ... — never use git add ., git add -A, or git add --all
- Craft a Commitizen-formatted commit message (see format below)
- Execute commit using a HEREDOC:
```
git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>

<body>

<footer>
EOF
)"
```
- Verify with git log --oneline -1
Output the final report (see Report section)

If the user provided a scope hint argument, use it to guide scope selection across commits.

Commitizen Format

Types

Type	When to use
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Formatting, semicolons, etc. (no logic change)
`refactor`	Code change that neither fixes nor adds
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependency changes
`ci`	CI configuration changes
`chore`	Other changes that don't modify src or test
`revert`	Reverts a previous commit

Message Rules

Subject line: imperative mood, lowercase, no period, ≤72 characters
Scope: the module, component, or area affected (e.g., auth, api, cli)
Body: explain what and why, not how — wrap at 80 characters
Footer: BREAKING CHANGE: <description> for breaking changes, Closes #N for issue references

Guardrails

Condition	Action
Sensitive files (`.env`, `.pem`, `.key`, `credentials`, `secret`)	Skip the file, warn in report
Large binary files (>5MB)	Skip the file, warn in report
Merge conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) in any file	Abort entirely, report conflicted files
Debug artifacts (`.log`, `tmp_`, `.tmp`, `debug_`)	Skip the file, warn in report
Grouping is ambiguous	Prefer smaller, atomic commits
Purpose of a change is unclear	Use `chore` type
Files are already staged	Respect the existing staging — commit staged files first as their own logical group
No changes detected	Exit gracefully with message "Nothing to commit"

Cookbook

IF: All changes belong to a single feature
THEN: Create one `feat(scope): ...` commit
EXAMPLE: New API endpoint + handler + test + migration → single feat commit

IF: Changes span multiple concerns (feature + dependency update + docs)
THEN: Split into separate commits in order: deps → feature → docs
EXAMPLE: package.json update → new component + test → README update

IF: Only test files changed
THEN: Use `test(scope): ...` type
EXAMPLE: test(auth): add unit tests for login flow

IF: A file contains merge conflict markers
THEN: Abort entirely and report the conflicted files
EXAMPLE: "Cannot commit: unresolved conflicts in src/auth.ts"

IF: Sensitive files detected in changes
THEN: Skip them, commit everything else, warn at end
EXAMPLE: ".env.local skipped — contains sensitive data"

IF: Only config or tooling files changed (linter, formatter, tsconfig, etc.)
THEN: Use `chore(scope): ...` type
EXAMPLE: chore(lint): update eslint configuration

IF: Already-staged files exist alongside unstaged changes
THEN: Commit the staged files first as their own group, then process remaining
EXAMPLE: Staged migration committed first → then unstaged feature code

Report

After all commits are created, output a summary:

Commits created: total count
Commit log: git log --oneline -N showing all new commits (where N = number of commits created)
Skipped files: list each skipped file with the reason (sensitive, binary, debug artifact)
Warnings: any additional notes (e.g., "1 sensitive file excluded", "large binary skipped")