# Commit With Context

> Create a coherent Conventional Commit with concise, high-signal context. Use when the user explicitly asks to commit current work or invokes $commit-with-context. Keep unrelated changes out and avoid splitting one task into artificial micro-commits.

- Skill: `kenryu42/commit-with-context` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kenryu42/commit-with-context`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kenryu42/commit-with-context/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: kenryu42 (https://skillmd.com/u/kenryu42)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kenryu42/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:

```text
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:

```text
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.