Skip to main content

commit-work

Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits.

Ir para a instalação

Informações da origem

Repositório
tomevault-io/claude-code-plugins
Última atividade na origem
6 de abril de 2026 às 08:16
Idioma detectado do SKILL.md
inglês
Estrelas
3
Forks
2

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
name
commit-work
description
Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits.
# Commit work ## Goal Make commits that are easy to review and safe to ship: - only intended changes are included - commits are logically scoped (split when needed) - commit messages describe what changed and why ## Inputs to ask for (if missing) - Single commit or multiple commits? (If unsure: default to multiple small commits when there are unrelated changes.) - Commit style: Conventional Commits are required. - Any rules: max subject length, required scopes. ## Workflow (checklist) 1) Inspect the working tree before staging - `git status` - `git diff` (unstaged) - If many changes: `git diff --stat` 2) Decide commit boundaries (split if needed) - Split by: feature vs refactor, backend vs frontend, formatting vs logic, tests vs prod code, dependency bumps vs behavior changes. - If changes are mixed in one file, plan to use patch staging. 3) Stage only what belongs in the next commit - Prefer patch staging for mixed changes: `git add -p` - To unstage a hunk/file: `git restore --staged -p` or `git restore --staged <path>` 4) Review what will actually be committed - `git diff --cached` - Sanity checks: - no secrets or tokens - no accidental debug logging - no unrelated formatting churn 5) Describe the staged change in 1-2 sentences (before writing the message) - "What changed?" + "Why?" - If you cannot describe it cleanly, the commit is probably too big or mixed; go back to step 2. 6) Write the commit message - Use Conventional Commits (required): - `type(scope): short summary` - blank line - body (what/why, not implementation diary) - footer (BREAKING CHANGE) if needed - Prefer an editor for multi-line messages: `git commit -v` - Use `references/commit-message-template.md` if helpful. 7) Run the smallest relevant verification - Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on. 8) Repeat for the next commit until the working tree is clean ## Deliverable Provide: - the final commit message(s) - a short summary per commit (what/why) - the commands used to stage/review (at minimum: `git diff --cached`, plus any tests run) --- > Converted and distributed by [TomeVault](https://tomevault.io) | [Claim this content](https://tomevault.io/claim/davila7/claude-code-templates) <!-- tomevault:2.0:skill_md:2026-04-05 -->
Ver no GitHub