commit-objectively

Commit Objectively

Generate a commit message from the diff alone, then execute the commit.

The message comes from the diff — not from what the user said, not from what you infer. This keeps the commit history accurate and reviewable without needing to remember conversation context.

<skill_directory> is the parent directory of this SKILL.md.

How it works

1. Gather context (first-time only): Ensure git fetch origin main has been run manually first, then run <skill_dir>/scripts/ctx.cmd (Windows) or <skill_dir>/scripts/ctx.sh (Unix) to see recent commit style. This script only needs to be run once per skill session; it does not need to be re-run for each commit.

1. Determine diff base: Use HEAD~1 by default, or the branch the user

specifies (e.g., origin/main, develop).

1. Stage changes: Add relevant files (git add), excluding private files

(.env*, *.key, node_modules/, target/, dist/, *.log). Unstage everything else. If the user names specific files, stage only those.

1. Read the diff: git diff --cached (or git diff HEAD / git diff <base>

if nothing is staged).

1. Write the commit message from the diff:

• Subject: objective summary of all changes, imperative mood
• Type/scope: follow project conventions from git log -10 --no-author;

fall back to Conventional Commits (feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert)

• Body: if the change isn't obvious from the subject, describe what changed

file by file — this helps reviewers without requiring background context

• Footer: BREAKING CHANGE: if the diff shows incompatible API changes;

reference issues if the branch name indicates one

1. Write to temporary file: Save the commit message to a temporary file

(e.g., .git/COMMIT_EDITMSG_TMP.txt) to ensure consistent line endings across platforms. The file should contain the subject, an empty line, then the body (if any) and footer (if any).

1. Execute: Run git commit -F "<temp-file>" then clean up the temporary file.

What to avoid

• Don't ask "what did you change?" — the diff has the answer.
• Don't include conversation content in the message.
• Don't infer intent beyond what the diff shows.
• Don't hardcode the diff base — determine it from context.
• If the diff is empty, stop and tell the user.
• Don't use shell commands to write files (e.g., echo > file, cat > file) when dedicated file writing tools are available (such as write or edit), as shell redirection behavior varies across platforms and can cause reliability issues.