pbf: Skill for Claude Code

Skill: Git Commit Message (Chris Beams style)

Purpose

After making code changes, produce a single Git commit message that summarizes the work, following the guidelines in: https://cbea.ms/git-commit/

Inputs

• The staged diff or the full diff of the change.
• The list of files changed.
• Any user intent, task description, or ticket reference already present.

Output (exact)

Return only the commit message text in this structure:

• Subject line (required)
• Blank line
• Body (optional, but required if the change is not self-explanatory)
• Optional footer lines for issue references

Rules (must follow)

1. Separate subject from body with a blank line.
2. Subject line should be ≤ 50 characters (hard max 72).
3. Capitalize the subject line.
4. Do not end the subject with a period.
5. Use the imperative mood (“Add…”, “Fix…”, “Remove…”).
6. Wrap body text at 72 characters.
7. Body should explain what and why, not how.
8. Body defaults to one short paragraph, 2–4 sentences. A second paragraph is rare and must earn its place — it is not a default slot to fill.
9. Write the body in ASD-STE100. Use the asd-ste100 skill to write and check it.

Procedure

1. Identify the single primary purpose of the change.
2. Draft 2–3 candidate subject lines and choose the best.
3. Write the subject as an imperative outcome statement.
4. Include a body if rationale or behavior change needs explanation.
5. Add issue references only if explicitly present in context.

Writing the body (what belongs there)

• Write for a reader running git blame years from now. Assume they have the diff and the code — but not the plan doc, the ticket, or your memory of today. A commit is immutable history: it's read as "what this was and where it was headed," so that orientation is worth giving.
• State the change's effect and role at an altitude the diff doesn't already show. The diff is the how; don't re-narrate the mechanics.
• Don't repeat what the code documents itself — a doc comment, README, or type. If it already lives in the tree, the body shouldn't echo it.
• Record what the diff can't reveal: deliberate omissions (why there's no X), non-obvious trade-offs, the decision behind the shape.
• Several changes landing in one commit don't each need their own sentence — name what ties them together once, rather than explaining each one in turn. One unifying sentence beats a roll call of the files touched.
• Context about what the change enables, or where adjacent pieces live, is worth one sentence only if a reader would otherwise wonder about it — not because it's true. Phrase it as durable architecture ("recovery lives in the level runner that calls this"), never as ephemeral bookkeeping (phase / PR / ticket numbers, plan-relative "next step") a future reader can't resolve.