菜单
Use when the user asks to "commit", "create a commit", "git commit", "stage and commit", or invokes /skill:commit. Creates git commits following the gitmoji convention.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | commit |
| description | Use when the user asks to "commit", "create a commit", "git commit", "stage and commit", or invokes /skill:commit. Creates git commits following the gitmoji convention. |
Goal: Analyze staged or unstaged git changes and create a commit following the gitmoji convention.
If the user invoked this skill via /skill:commit <args>, pi will have appended their arguments as a User: message after this skill's content — read those arguments as additional context or instructions for the commit.
Format: <gitmoji> <type>: <description>
| Gitmoji | Type | Use Case |
|---|---|---|
| ✨ | feat | New feature |
| 🐛 | fix | Bug fix |
| ♻️ | refactor | Code refactoring |
| ✅ | test | Adding or updating tests |
| 📝 | docs | Documentation changes |
| 🔥 | remove | Removing code or files |
| 🔧 | chore | Configuration/tooling |
If the project defines its own git workflow (e.g.
agent_docs/git-workflow.md,CONTRIBUTING.md, or rules insideAGENTS.md), follow that instead of the table above.
Use verification-before-completion before creating a commit unless the user explicitly requested a commit-only/no-verify workflow. Run the relevant fresh verification command(s), read the output, and include the evidence in the commit confirmation prompt.
Run these commands (a single bash call with && is fine):
git status — check for staged and unstaged changesgit diff --cached — view staged changesgit diff — view unstaged changesgit log --oneline -5 — recent commits for style referenceIf no changes are staged AND none are unstaged, stop and tell the user there's nothing to commit.
If nothing is staged but there are unstaged changes, ask the user which files to stage (or whether to stage everything modified).
Based on the diff analysis:
If changes span multiple logical concerns, suggest splitting into separate commits before proceeding.
Use a single user_select call as the confirmation step. Do not send a separate plain-text confirmation message before the tool call.
Put the proposed commit message and file list directly in the tool prompt, then ask for the decision. Do not run git commit until the tool returns.
Call it like this (set allowCustom: true so the user can type free-form edit instructions):
{
"question": "Proposed commit:\n\n <gitmoji> <type>: <description>\n\nFiles to be committed:\n - path/to/file1\n - path/to/file2\n\nCommit with this message and file list?",
"options": [
{ "label": "Commit as-is" },
{ "label": "Edit the message" },
{ "label": "Edit the file selection" },
{ "label": "Cancel" }
],
"allowCustom": true
}
Handle the result based on the answer field returned by the tool:
Commit as-is → proceed to Step 4.Edit the message → ask the user for the new message via a follow-up prompt (plain message, or another user_select call if you have concrete alternatives), then re-run Step 3 with the updated message.Edit the file selection → ask which files to include or exclude, restage accordingly, regenerate the diff summary, and re-run Step 3.Cancel → abort. Do not stage or commit anything. Confirm to the user that nothing was committed.wasCustom: true) → treat the typed text as edit instructions (e.g. "change feat to fix"), apply them, and re-run Step 3.answer: null, cancelled: true, e.g. user pressed Esc) → abort like Cancel.Always re-confirm after any edit — never auto-commit a modified proposal.
Stage files if not already staged. Always use specific filenames (git add path/to/file). Never use git add -A or git add . unless the user explicitly requested it.
Create the commit using a HEREDOC for proper formatting:
git commit -m "$(cat <<'EOF'
<gitmoji> <type>: <description>
EOF
)"
Run git status afterwards to verify success.
If pre-commit hooks fail:
--no-verify unless the user explicitly requests it-i)--no-verify or --no-gpg-sign unless explicitly askedgit log --oneline -20 if unsure)Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use after completing an implementation task or major feature, and before claiming ready/merge, to verify the work meets requirements via a focused reviewer subagent.
Use after an implementation plan exists and it contains independent tasks that can be delegated to fresh subagents in the current session.
Use after planning/brainstorming when implementation begins for any feature or bugfix, before writing production code; requires tests first and red-green verification.
Use after an approved design/spec or clear requirements exist and before implementing a multi-step task; creates a task-by-task implementation plan before code changes.
Use after making code changes, before committing, or when the user asks to "simplify", "clean up", or "review" recent edits — runs three parallel review agents (reuse, quality, efficiency) over the diff and fixes the findings.