playbooks

home / skills / vadimcomanescu / codex-skills / git-commit-helper

git-commit-helper skill

/skills/.experimental/devtools/git-commit-helper

This skill helps craft clear, conventional commits by summarizing changes, applying prefixes, and documenting intent and scope.

npx playbooks add skill vadimcomanescu/codex-skills --skill git-commit-helper

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
672 B
---
name: git-commit-helper
description: Help craft clear, conventional commits. Use when preparing commit messages, organizing changes into commits, or documenting intent and scope for code changes.
---

# Git Commit Helper

Create concise, high-signal commits that explain intent and scope.

## Quick Start
1) Summarize the change and split unrelated edits.
2) Choose a conventional commit prefix if applicable.
3) Write a short subject + optional body describing why.

## Guardrails
- One logical change per commit.
- Avoid noisy “WIP” messages unless asked.
- Mention user-visible impact when relevant.

## References
- Extended examples: `references/examples.md`

Overview

This skill helps you craft clear, conventional commit messages and organize changes into focused commits. It guides subject and body composition, suggests conventional prefixes, and enforces one logical change per commit. Use it to improve project history clarity and make reviews faster.

How this skill works

The skill analyzes your staged changes and the described intent, then proposes a short subject line and optional body that follow conventional commit style. It suggests how to split unrelated edits into separate commits and highlights user-visible impacts to include. It also flags noisy or vague messages like “WIP” and offers cleaner alternatives.

When to use it

  • Preparing a commit message before running git commit
  • Splitting a large change into multiple logical commits
  • Documenting the scope and intent for code reviewers
  • Cleaning up messages during an interactive rebase
  • Ensuring commits follow a conventional prefix or project convention

Best practices

  • Limit each commit to a single logical change and split unrelated edits
  • Start the subject with a concise verb phrase and, if relevant, a conventional prefix (feat:, fix:, docs:, chore:, refactor:)
  • Keep the subject under 50 characters and capitalize only the first word when appropriate
  • Include a short body when the why or scope isn’t obvious; mention user-facing impact if applicable
  • Avoid placeholders like “WIP” or “temp”; be specific about intent

Example use cases

  • Turn a multi-file refactor into a series of commits: refactor, fix tests, update docs
  • Create a bug-fix commit with prefix fix: and a body explaining root cause and test added
  • Prepare a feature commit with feat: and a brief summary of user-visible changes
  • Document a configuration or build change with chore: and notes on environment impact
  • Refine vague commit messages during an interactive rebase into clear, reviewable entries

FAQ

Should every commit use a conventional prefix?

Use conventional prefixes when your project follows that convention; otherwise prioritize clarity. Prefixes help tooling and release automation when present.

How do I decide commit scope versus body?

Keep the subject focused on what changed; use the body to explain why, implementation notes, and any migration or rollout instructions.