Skill

commit

This skill should be used when the user asks to "commit changes", "commit my work", "make a commit", "stage and commit", or wants to save progress with a git commit. Stages relative changes and commits with an auto-generated conventional commit message.

npx claudepluginhub tim-hub/powerball

Configuration

Model: haiku

Tool Access

This skill is limited to using the following tools:

BashRead

Preview

Analyze what has changed, write a precise conventional commit message, and commit — without asking for confirmation.

SKILL.md

Similar Skills

commit

Stages intended Git changes, avoiding secrets, and commits with clear Conventional Commit messages. Use when work is ready and diff is understood.

blueprint

commit

113

Stages and commits git changes atomically with conventional messages. Analyzes status and diffs, groups into logical units (structural, behavioral, docs, config) without modifying code.

16 tools

hal-skills

commit

129

Analyzes uncommitted git changes, excludes ephemeral files like node_modules or build/, groups by purpose into atomic conventional commits, validates code, and optionally pushes.

1 file3 tools

claude-coding

Stats

Parent Repo Stars2

Parent Repo Forks0

Last CommitMar 23, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Analyze what has changed, write a precise conventional commit message, and commit — without asking for confirmation.

If the user provided an argument, treat it as a hint or context for the commit message (e.g. a ticket number, feature name, or description to incorporate).

Process

Run git status to see all changed, untracked, and staged files.
Run git diff HEAD (or git diff + git diff --cached) to understand the actual changes.
Analyze the diff to determine:
- The primary type of change: feat, fix, refactor, docs, chore, test, style, perf, ci, or build
- A concise scope (optional) — the module, file, or area affected
- A short imperative summary (under 72 chars) describing WHAT changed and WHY
Stage everything with git add -A.
Commit with the generated message.
Push to remote only if the user explicitly asked to push.

Conventional Commit Format

type(scope): short summary

Optional longer body explaining the why, not the what.

Message Quality Rules

Use imperative mood: "add", "fix", "remove" — not "added", "fixes", "removed"
Summary under 72 characters
No period at the end of the summary line
If changes span multiple concerns, pick the dominant one for the type; mention others in body
Body only when the summary alone would be unclear

Type Selection Guide

feat — new capability or behavior visible to the user
fix — corrects a bug or broken behavior
refactor — code restructure with no behavior change
docs — documentation only
chore — tooling, deps, config, build
test — adding or updating tests
style — formatting, whitespace, no logic change
perf — performance improvement
ci — CI/CD pipeline changes

Edge Cases

Nothing to commit: Report git status and stop.
Already-staged files exist: Stage all remaining changes too (git add -A covers both).
Massive diff spanning many files: Use a broader type (chore or refactor) with a body summarizing the scope.
Sensitive files (.env, credentials): Do NOT commit them. Warn the user and stop.

After committing, confirm with the commit hash and message so the user can see what was saved.