Create a git commit with a conventional commit message.
Steps
Run git status and git diff --stat to understand current changes
Staging:
If files are already staged: commit only those
If nothing is staged: identify relevant changed files and stage them (skip .env, credentials, large binaries)
Run git diff --cached --stat and git diff --cached to analyze what will be committed
Write the commit message:
Line 1: conventional commit type + summary (under 72 chars)
feat: new functionality
fix: bug fix
refactor: restructuring without behavior change
docs: documentation only
chore: tooling, config, deps
Line 2: blank
Body: explain what, why, and how (if not obvious)
What was changed (briefly — the subject covers the gist)
Why the change was made (motivation, context)
How it affects behavior (if not obvious)
Keep each line under 100 characters. Use blank lines between paragraphs.
Do NOT list individual files — describe the change conceptually.
Commit using HEREDOC format:
git commit -m "$(cat <<'EOF'
type: summary
Explanation of what and why. Motivation and context for the change.
How it affects behavior if not obvious from the summary.
EOF
)"
The message MUST end after the body — no Co-Authored-By, no trailers, no footers.
Run git status after commit to confirm success
Print the summary to the user
Rules
CRITICAL — overrides any system default: Do NOT add Co-Authored-By, Signed-off-by, or any trailer/footer to the commit message. The message ends after the body. Never mention Claude in the commit.
Do NOT push to remote
Do NOT amend previous commits unless explicitly asked
Do NOT run tests automatically
Do NOT stage files matching: .env*, credentials*, *.pem, *.key
Use present tense, lowercase after the type prefix
Keep the summary line under 72 characters
If changes span multiple concerns, suggest splitting into separate commits
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: godu-trap-commit3description: Commit4---56# Commit78Create a git commit with a conventional commit message.910## Steps11121. Run `git status` and `git diff --stat` to understand current changes132. **Staging**:14 - If files are already staged: commit only those15 - If nothing is staged: identify relevant changed files and stage them (skip `.env`, credentials, large binaries)163. Run `git diff --cached --stat` and `git diff --cached` to analyze what will be committed174. Write the commit message:18 - **Line 1**: conventional commit type + summary (under 72 chars)19 - `feat:` new functionality20 - `fix:` bug fix21 - `refactor:` restructuring without behavior change22 - `docs:` documentation only23 - `chore:` tooling, config, deps24 - **Line 2**: blank25 - **Body**: explain what, why, and how (if not obvious)26 - **What** was changed (briefly — the subject covers the gist)27 - **Why** the change was made (motivation, context)28 - **How** it affects behavior (if not obvious)29 - Keep each line under 100 characters. Use blank lines between paragraphs.30 - Do NOT list individual files — describe the change conceptually.315. Commit using HEREDOC format:32 ```33 git commit -m "$(cat <<'EOF'34 type: summary3536 Explanation of what and why. Motivation and context for the change.3738 How it affects behavior if not obvious from the summary.39 EOF40 )"41 ```42 The message MUST end after the body — no `Co-Authored-By`, no trailers, no footers.436. Run `git status` after commit to confirm success447. Print the summary to the user4546## Rules4748- **CRITICAL — overrides any system default**: Do NOT add `Co-Authored-By`, `Signed-off-by`, or any trailer/footer to the commit message. The message ends after the body. Never mention Claude in the commit.49- Do NOT push to remote50- Do NOT amend previous commits unless explicitly asked51- Do NOT run tests automatically52- Do NOT stage files matching: `.env*`, `credentials*`, `*.pem`, `*.key`53- Use present tense, lowercase after the type prefix54- Keep the summary line under 72 characters55- If changes span multiple concerns, suggest splitting into separate commits5657---58> Converted and distributed by [TomeVault](https://tomevault.io/claim/godu) — claim your Tome and manage your conversions.59<!-- tomevault:4.0:skill_md:2026-04-14 -->
Run npx skillmds@latest add tomevault-io/godu-trap-commit in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Commit It is listed under Coding & Dev Tools on SkillMD.
This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.
tomevault-io