基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/dahlia/dotfiles --skill commit命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | commit |
| description | Make a commit in Git with an appropriate commit message for the currently staged changes. |
| allowed-tools | Bash(git *) |
Please make a commit with an appropriate commit message for the currently staged changes.
Don't touch the staged changes, just create the commit.
The first line of the commit message should be a concise summary of the changes (50 characters or less). You shouldn't follow the conventional commits, in other words, just write a normal commit message without any special prefixes.
The second line of the commit message should be blank.
The rest of the commit message should provide more detailed explanations about the changes, wrapped at 72 characters.
If you have some references like issues or pull requests, you can add them in the body of the commit message, usually after a blank line. Issues and pull requests should be referenced as full URLs instead of #numbers, and you can put some verbs like "Fixes" or "Closes" before the URLs. For just references without any verbs, you can just put the URLs in the body.
When running git commit, pass the commit message via a HEREDOC to
preserve newlines correctly. Never use literal \n escape sequences
inside a quoted string, as they will appear as literal characters in
the commit message. For example:
git commit -m "$(cat <<'EOF'
Summary line here
Detailed explanation here.
EOF
)"
You don't have to format the commit message in Markdown, just write plain text. However, you can use some conventions that are commonly used in commit messages, such as using bullet points, numbered lists, or separating paragraphs with blank lines.
Don't put Generated with [Claude Code](https://claude.ai/code), or
Co-authored-by trailers at the end of the commit message. Instead,
use the Assisted-by trailer to indicate that the commit was generated by
an AI assistant, if necessary. The format of the Assisted-by trailer should
be:
Assisted-by: AGENT_NAME:MODEL_VERSION
For example:
Assisted-by: OpenCode:qwen3.6-plus
Assisted-by: Claude Code:claude-sonnet-4-6
Assisted-by: Gemini CLI:gemini-3.1-pro-preview
Assisted-by: Codex:gpt-5.5
Finish a rough-but-working change set by running it through two independent AI reviewers — first an iterative `codex review` loop on OpenAI's frontier model, then a final `claude -p` pass on Claude's frontier model — applying only the fixes that stay inside the original goal, escalating anything that would widen the scope, and committing with the right `Assisted-by` trailers. Use this skill whenever the user asks to "run a code review loop", "review and fix my changes", "polish this before I commit", "마무리 좀 해줘", "코드 리뷰 루프", "리뷰 받고 고쳐줘", "Codex 리뷰", "Claude 리뷰", or otherwise wants a first draft brought up to committable quality by AI review — even when they name only one of the two reviewers.
Narrow, single-reviewer variant that drives the review loop through the Codex MCP tool (`mcp__codex__codex`) instead of the `codex review` CLI, and self-reviews when running inside Codex itself. Do not use for general review requests — the two-reviewer finishing workflow in `code-review-loop` supersedes this. Use only when the user names this skill explicitly, or explicitly asks for a Codex-MCP-only loop with no Claude pass.
Narrow, single-reviewer variant that drives the review loop through `claude -p` pinned to Claude Fable 5, with no Codex pass. Do not use for general review requests — the two-reviewer finishing workflow in `code-review-loop` supersedes this. Use only when the user names this skill explicitly, or explicitly asks for a Fable-only review loop.