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.

跳到安装

来源信息

仓库
tomevault-io/claude-code-plugins
最近来源活动
2026年4月6日 08:16
检测到的 SKILL.md 语言
英语
星标
3
分支
2

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
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 -->
在 GitHub 查看