Skill

commit

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

Git

git-workflow

npx claudepluginhub owainlewis/blueprint --plugin blueprint

Tool Access

This skill uses the workspace's default tool permissions.

Preview

- The current work is ready to record in git

SKILL.md

Similar Skills

commit

Stages files safely avoiding sensitive ones, infers conventional commit type from git diff, drafts message with scope, and executes after confirmation. Use anytime like post-planning or mid-TDD.

dev-pipeline

commit-workflow

573

Guides git commit workflow: analyzes staged files, generates conventional messages (feat/fix/etc.), updates README for features/setup changes, ignores unstaged.

github-dev

git-commit

13.2k

Creates git commits with clear messages from working tree changes, following repo conventions or conventional commits. Handles clean trees and detached HEAD.

compound-engineering

Stats

Stars79

Forks18

Last CommitApr 20, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Commit

When to use

The current work is ready to record in git

The diff is understood and intentionally scoped

Process

Inspect git status, git diff, and git diff --cached.

Read recent commit messages so the new commit fits the repo.

If there is nothing worth committing, stop.

Stage only the intended files. Never stage secrets.

Use the user's message if provided. Otherwise write a Conventional Commit message:

Format: type(scope): subject
Common types: feat, fix, refactor, test, docs, chore
Keep the subject short, specific, and in imperative mood
Use the body for why the change exists, important context, and migrations or follow-up work
Good examples: feat(auth): add GitHub OAuth login, fix(api): handle empty embedding results

Create the commit and report the hash and message.

Verification

The staged changes match the intended scope

The commit exists

git status confirms the expected result

Rules

If the change breaks a contract or requires migration, note it clearly in the commit message body.

If there is nothing to commit or the diff is not understood, stop.

Prefer staging specific files over broad adds.

Do not commit .env, credentials, or keys.

The subject should say what changed. The body should explain why.

Commit

When to use

The current work is ready to record in git
The diff is understood and intentionally scoped

Process

Inspect git status, git diff, and git diff --cached.
Read recent commit messages so the new commit fits the repo.
If there is nothing worth committing, stop.
Stage only the intended files. Never stage secrets.
Use the user's message if provided. Otherwise write a Conventional Commit message:
- Format: type(scope): subject
- Common types: feat, fix, refactor, test, docs, chore
- Keep the subject short, specific, and in imperative mood
- Use the body for why the change exists, important context, and migrations or follow-up work
- Good examples: feat(auth): add GitHub OAuth login, fix(api): handle empty embedding results
Create the commit and report the hash and message.

Verification

The staged changes match the intended scope
The commit exists
git status confirms the expected result

Rules

If the change breaks a contract or requires migration, note it clearly in the commit message body.
If there is nothing to commit or the diff is not understood, stop.
Prefer staging specific files over broad adds.
Do not commit .env, credentials, or keys.
The subject should say what changed. The body should explain why.