C
commit-work
by @softaworksv1.0.0
4.0(0)
创建高质量的Git提交,包括审查和暂存预期更改,确保提交信息清晰准确。
安装方式
npx skills add softaworks/agent-toolkit --skill commit-workcompare_arrows
Before / After 效果对比
1 组使用前
过去,我常常在提交代码时直接使用简单的提交信息,或者一次性提交大量不相关的更改,导致Git历史记录混乱,难以追溯问题,也给代码审查和版本回溯带来了巨大困难。
使用后
现在,通过规范化的提交工作流,我能清晰地审查和暂存预期的更改,并撰写有意义的提交信息,确保每次提交都是原子性的高质量变更,极大地提升了代码库的可维护性和团队协作效率。
description 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)
- Inspect the working tree before staging
git statusgit diff(unstaged)- If many changes:
git diff --stat
- 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.
- 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 -porgit restore --staged <path>
- Prefer patch staging for mixed changes:
- Review what will actually be committed
git diff --cached- Sanity checks:
- no secrets or tokens
- no accidental debug logging
- no unrelated formatting churn
- 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.
- 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.mdif helpful.
- Use Conventional Commits (required):
- Run the smallest relevant verification
- Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on.
- 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)
forum用户评价 (0)
发表评价
效果
易用性
文档
兼容性
暂无评价,来写第一条吧
统计数据
安装量3.4K
评分4.0 / 5.0
版本1.0.0
更新日期2026年3月16日
对比案例1 组
用户评分
4.0(0)
5
0%
4
0%
3
0%
2
0%
1
0%
为此 Skill 评分
0.0
兼容平台
🔧Claude Code
🔧OpenClaw
🔧OpenCode
🔧Codex
🔧Gemini CLI
🔧GitHub Copilot
🔧Amp
🔧Kimi CLI
时间线
创建2026年3月16日
最后更新2026年3月16日