Verified:GitHub

commit

Stage reviewed changes by name and write structured git commit messages.

1|Updated Apr 24, 2026

Search Tags:#git #code review #version control #commit #hooks #staging #commit message

One-click install

npx skills add https://github.com/kreek/consult --skill commit-kreek

Or copy as Structured Prompt for Agent▼

Please help me install this Agent Skill.
Skill: commit
Source: https://github.com/kreek/consult/tree/main/plugin/skills/commit
Command: npx skills add https://github.com/kreek/consult --skill commit-kreek

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Dirty working trees often mix unrelated changes, leading to bloated commits that cannot be reverted cleanly and vague messages that hide intent. This Skill enforces a packaging standard so only the reviewed slice is staged, grouped by behavior, with a clear subject and current proof. ## Core Features & Use Cases - Behavior-based commit splitting: Groups changes so one behavior can be reverted without dragging unrelated work, deferring unrelated dirty files explicitly. - Safe staging discipline: Stages only named files or approved pathspecs, never `git add .` in a messy tree, and confirms the staged diff matches the reviewed slice. - Message and proof standards: Writes subjects that complete "When applied, this commit will ...", keeps bodies to 2-3 short paragraphs, verifies proof is current, and never skips hooks. - Use Case: After finishing a reviewed feature, ask the agent to commit only that slice; it stages the named files, confirms the diff, checks test proof, and writes a clean commit while leaving unrelated changes untouched. ## Quick Start Use the commit skill to stage only the reviewed authentication changes and write a proper commit message for them.

Frequently Asked Questions about commit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I split a messy working tree into logical git commits?▼

Group changes by behavior so each commit can be reverted independently, then stage only the named files for one slice at a time. Unrelated dirty or untracked files stay unstaged and are explicitly named as deferred.

How should I write a good git commit message?▼

Write the subject so it completes "When applied, this commit will ...". Add a body only when the change needs context, limited to at most 2-3 short paragraphs.

Is it safe to use git add . when committing?▼

No, not in a messy tree. Stage only named files or approved pathspecs for the reviewed slice and confirm the staged diff matches. The only exception is a fresh scaffold where every file belongs.

Can I skip git hooks to commit faster?▼

No. Hooks must never be skipped; run the hook, or fix and report whatever blocks it. There is no accepted exception to this rule.

When should I not use this commit skill?▼

Use git-workflow for branches, conflicts, rebases, and recovery; code-review before committing non-trivial changes; and release for versions, changelogs, tags, and publishing.