How do I install the Commit With Context skill?

Run npx skillmds@latest add kenryu42/commit-with-context in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Commit With Context safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Commit With Context?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Commit With Context free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Commit With Context?

kenryu42 (@kenryu42) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Commit With Context by kenryu42 — Agent Skill

Name: Commit With Context
Author: kenryu42

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.

kenryu42 f4dc1ae 2 files · 3.2 KB Updated Sep 17, 2026

File contents

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.

---name: commit-with-contextdescription: 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.---## 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 messageUse a Conventional Commit subject in imperative form:```texttype(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:```textWhy:- 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.

Frequently asked questions