메뉴
Create focused, atomic git commits following Conventional Commits v1.0.0. Each commit is a single logical change with a rationale body explaining why. Use when the user says "commit", "make a commit", or wants to commit changes.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | commit |
| description | Create focused, atomic git commits following Conventional Commits v1.0.0. Each commit is a single logical change with a rationale body explaining why. Use when the user says "commit", "make a commit", or wants to commit changes. |
| user-invocable | true |
| disable-model-invocation | false |
| allowed-tools | ["Bash","Read","Grep","Glob"] |
Create focused, independent VCS commits that follow Conventional Commits v1.0.0. Every commit body serves as a durable decision record explaining why changes were made, so humans and LLMs reviewing history can understand rationale.
Inspect the working tree. Run git status (never -uall) and
git diff (staged + unstaged). Read recent git log --format='%B---' -5
to stay consistent with existing style and scope conventions.
Partition into atomic units. Each commit must be a single, self-contained logical change. If the working tree contains multiple independent changes, split them into separate commits automatically — one per logical unit. A commit is atomic when it answers exactly one "why."
Stage precisely. Use git add <path>… for each commit — never
git add -A or git add .. Never stage files that look like secrets
(.env, credentials.*, tokens, private keys). Warn the user and refuse
if detected.
Write the commit message using the format below.
Verify. Run git status after each commit to confirm success.
<type>(<scope>): <subject>
<body>
[<footer(s)>]
| Field | Rules |
|---|---|
<type> | One of: feat, fix, refactor, perf, test, docs, style, build, ci, chore, revert |
<scope> | Always required. Use the narrowest accurate scope for the change. Freeform — match the project's existing scope conventions when present. For cross-cutting changes, use repo. |
<subject> | Imperative mood, lowercase, no period, 50 chars max. Describe what changed. |
| Breaking | Append ! after scope: feat(api)!: remove legacy endpoint and add a BREAKING CHANGE: footer. |
The body is a micro decision record. It answers why, not what — the diff shows what. Write it so a developer or an LLM summarizing history can understand the motivation without reading the code.
Structure as concise prose following this pattern:
Keep it to 1-4 wrapped lines. Hard-wrap at 72 characters. Use plain prose with causal connectives ("because", "instead of", "despite"), not bullet lists — structured prose is easier for LLMs to summarize.
Trivial opt-out: A body may be omitted only when ALL of these hold: the subject fully communicates intent, the diff is self-explanatory, and there is no non-obvious motivation. Examples: typo fixes, single dependency additions with obvious purpose, version bumps.
When in doubt, include a body.
Use git-trailer format. Only include footers when applicable — no AI attribution trailers.
| Trailer | When |
|---|---|
BREAKING CHANGE: <description> | Required for any breaking change. |
Refs: <issue or URL> | When related to a tracked issue. |
feat(auth): replace session tokens with JWT
Cookie-based sessions required server-side state that complicated
horizontal scaling. JWTs are stateless and let each service verify
independently, at the cost of slightly larger payloads and no
server-side revocation without a denylist.
When the working tree contains multiple independent changes, split them into separate atomic commits automatically without asking for confirmation. Apply these heuristics:
If a pre-commit hook fails:
--amend — the commit did not happen, so amending would
modify the previous unrelated commit.Always use a heredoc to preserve formatting:
git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>
<body>
<footer(s)>
EOF
)"
git push unless the user explicitly asks.--no-verify or --no-gpg-sign unless the user explicitly asks.--amend unless the user explicitly asks.main/master.