Autonomous Git Commit

---

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

1. Analyze all changes — review staged, unstaged, and untracked files from the context above
2. 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
3. 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
4. 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:

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