kenryu42/agent-skills/commit-with-context

Context

• Current status: !git status --short
• Staged changes: !git diff --cached
• Unstaged changes: !git diff
• Current branch: !git branch --show-current
• Recent commit messages: !git log -5 --format='%h%n%s%n%b%n---'

Scope the commit

• Treat a non-empty index as the intended commit scope. Do not stage additional paths unless the user explicitly asks you to select changes from the worktree.
• When the index is empty, stage only paths that belong to the requested task after inspecting their contents, including relevant untracked files.
• Do not include unrelated or pre-existing changes. If the index mixes unrelated work, stop and report the conflict instead of silently restaging it.
• Do not modify source files while performing the commit workflow.

Choose commit boundaries

• Default to one commit for one coherent task.
• Keep implementation, tests, documentation, and migrations for the same behavior together.
• Split only when changes are unrelated, independently reversible, or independently useful for cherry-picking or backporting.
• Do not split a task merely by file type, implementation step, or diff size.
• When splitting is justified, ensure every commit is meaningful and valid on its own.

Write the message

Use a Conventional Commit subject in imperative form:

type(scope): concise summary

Follow the repository's established types and scopes. Use feat for a new feature and fix for a bug fix. Add issue references or BREAKING CHANGE footers when applicable.

For non-trivial changes, add a concise body:

Why:
- State the problem, motivation, or user-visible intent.
 
What:
- Summarize the important behavioral changes or design decisions.
 
Validation:
- List the exact verification commands that passed.

Keep the body high-signal:

• Prefer one Why bullet and one to four What bullets.
• Record important boundaries or deliberate omissions when they help future readers.
• Do not invent validation results. If verification was not run, say Not run and give the reason.
• Do not list changed files or narrate implementation details that are obvious from the diff.
• Do not repeat the subject in the body or add empty sections.
• Allow a subject-only commit for a trivial, self-explanatory mechanical change.

Commit and verify

• Create the commit with the exact subject and body you prepared.
• Do not bypass commit hooks. Read and respond to their complete output if they fail.
• Do not push or amend unless the user explicitly requests it.
• Verify the result with git status --short and git log -1 --format=fuller.
• Report the commit SHA, subject, and any remaining worktree changes.