菜单
Creates atomic Conventional Commits. Use when committing code changes, splitting hunks into revertable units, or writing detailed commit messages.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | commit |
| description | Creates atomic Conventional Commits. Use when committing code changes, splitting hunks into revertable units, or writing detailed commit messages. |
Arguments:
You are an expert git commit architect creating fine-grained, independently revertable commits following Conventional Commits specification.
Before committing, inspect the current state:
git status --short
git diff HEAD
git log --oneline -10
Revertability First: Each commit must be revertable independently without breaking other functionality. Prefer smaller, granular commits over large groupings. Split by hunks within files, not just entire files.
PR branches are normally squash-merged, so do not compress review work with git commit --amend by default. Keep review fixes as small follow-up commits that can be reverted independently. Amend only for unpublished local mistakes or when the user explicitly asks.
Tiny commits are expected. A single review comment, one wording correction, one reference-file extraction, one symlink sync, or one generated formatting pass can each be its own commit when independently revertable.
Tiny does not mean incomplete. For moves, renames, or extractions, one commit must include both sides of the operation: remove or update the old location, add the new location, update references, and sync generated links if required. Never commit only the destination of a move while leaving the source/reference cleanup for a later commit.
For concrete good and bad examples, read references/revertable-commits.md.
git diff <file>git apply --cached -v <patch>git show HEADNEVER use git add -p or git add --interactive - Claude Code cannot handle interactive commands.
Use git apply --cached -v to stage precise non-interactive patches. Read references/git-apply.md when a patch fails, needs whitespace handling, or must be staged without touching unrelated hunks.
Use standard git history commands to understand intent before committing. Prefer targeted commands such as git log --follow -- <file>, git show <commit> -- <file>, and git blame <file>. Match the repository's existing commit granularity, scopes, and explanation style.
<type>(<scope>): <subject>
<body>
<footer>
Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
Body should explain:
chore(xxx): format or just chore: formatAfter all commits are complete, push to remote. Let repository git hooks run; if pre-commit or pre-push runs format, sync, lint, typecheck, or tests, treat those hooks as part of the normal validation path and fix any failures in a new small commit.
Read references/push.md for the exact upstream check and push commands.
Run a code review using Codex CLI. Use when the user wants a code review of uncommitted changes, a specific commit, or changes against a base branch.
Guides execute-inspect-adjust development and t-wada Red-Green-Refactor TDD. Use for exploratory implementation or when stable behaviour needs an executable test-first contract.
Prevents and handles GitHub API rate limits with gh-nix. Use when Nix, flakes, nixpkgs commands, or comma may fetch GitHub-backed inputs.
Manages worktree lifecycle operations through git-wt without replacing an existing linked worktree. Use when creating, switching, listing, renaming, or deleting worktrees.
Runs the full PR workflow — creates a feature branch, commits, pushes, and opens the pull request. Use when the user asks to create or open a PR ("create a PR", "push this up and open a PR").
Resolves missing CLI tools. Use when a command is unavailable, a shell reports command not found, or a tool must be run without installing it globally.