getty-git-commit-style

Writes imperative git commit messages and changelog entries following Getty repository conventions.

1|Updated Mar 29, 2026
One-click install
npx skills add https://github.com/Getty/p5-alien-libssh --skill getty-git-commit-style-getty
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: getty-git-commit-style
Source: https://github.com/Getty/p5-alien-libssh/tree/main/.claude/skills/getty-git-commit-style
Command: npx skills add https://github.com/Getty/p5-alien-libssh --skill getty-git-commit-style-getty

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing consistent, complete commit messages and changelog entries across Getty repositories is error-prone: vague summaries, missing file-level changes, duplicated changelog bullets, and accidental @ mentions or wrong issue references all slip in. This Skill enforces a strict format so every commit and Changes entry follows the same rules. ## Core Features & Use Cases - Commit message formatting: imperative summary line (max ~72 chars), one body line per discrete change, no filler phrases, and a Co-Authored-By trailer naming the actual model. - Changelog discipline: one topic per entry, rewrite existing unreleased bullets instead of appending, describe the destination not the journey, and reference only publicly readable trackers. - Multi-repo and HEREDOC handling: separate commits per repo without cross-references, and messages passed via HEREDOC to preserve formatting. - Use Case: After renaming an accessor across three Perl modules, produce a commit message listing every touched file and update the unreleased Changes section in the same commit. ## Quick Start Write a commit message for my staged changes following the Getty commit style, including the changelog entry.

Frequently Asked Questions about getty-git-commit-style

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a good git commit message?

Use an imperative summary line under 72 characters describing the primary intent, then list every discrete file-level change on its own body line. Avoid filler phrases like "This commit" and state what changed, not why it matters.

How should changelog entries be written for unreleased changes?

Keep one bullet per topic: before adding an entry, check the unreleased section and rewrite the existing bullet if the topic already appears. Describe the current state of the code, not the history of attempts, in one to three lines.

Can I use @ mentions or issue numbers in commit messages?

Never use `@` in commit messages because platforms like GitHub interpret it as a user mention; write `[DBIO]` instead of `[@DBIO]`. Internal ticket ids may appear in the board's own notation like `k254`, never as `#254` which resolves against the host's own issues.

How do I commit changes that span multiple repositories?

Give each repository its own commit with its own message, and do not reference other repos in the message text. Each commit stands alone describing only the changes in that repository.

Why pass git commit messages via HEREDOC?

HEREDOC preserves multi-line formatting, blank lines between summary and body, and trailer lines exactly as written. Use `git commit -m "$(cat <<'EOF' ... EOF)"` so the shell does not mangle the message structure.