| name | git |
| description | Guide for using git with specific preferences -- branch names without `feat/`/`hotfix/` prefixes, backticks around code identifiers in commit messages, asking about GitHub issues to reference before committing. Use this whenever you branch, commit, or write a commit message -- not just when explicitly asked to "commit". These conventions aren't in your default knowledge and you'll get them wrong without consulting this skill. |
| license | MIT |
git
Most of git usage is what you already know, so depend on that. This skill is just a refinement.
Branch naming
Just name the branch a short sentence separated with dashes. Example: add-some-feature. Don't use feat/, hotfix/ etc. prefixes.
Commit messages
- Keep them concise and easily readable for someone who isn't intimately familiar with the change. The reader is a future teammate (or future you) skimming
git log, not a reviewer studying the diff. Lead with what changed in plain language; skip implementation play-by-play, rationale chains, and trivia. If deeper context is worth capturing, that's what the diary is for -- see the [[diary]] skill -- not the commit message.
- Always enclose code identifiers with backticks. Example: "Add
html.UserPage component"
- Backticks are command substitution in the shell, so a backtick in a double-quoted
git commit -m "..." gets executed and silently dropped from the message -- e.g. -m "Add `html.UserPage`" tries to run html.UserPage and commits "Add ". Protect them: write the message with a single-quoted here-doc (-F - reading a <<'EOF' block), pass a single-quoted -m '...', or escape each backtick as \`. The here-doc is the most reliable for multi-line messages.
- Always refer to Go code identifiers including the package name, like in
html.UserPage above. Fields and methods on structs can be referred with model.User.Name.
- Ask me about any Github issues that should be referenced, and wait for my response before committing. Reference them at the end of the commit message like this: "See #123, #234". If the commit fixes one or more issues, use "Fixes #123, fixes #234" instead (the double "fixes" is important for Github to actually close the issue).
- Don't mention that you've updated tests, that's assumed.
Pull request descriptions
- Don't include sections that mirror what CI reports. Test Plan, Quality Gates, "ran build/lint/tests, all green" status -- skip them all. CI is the source of truth; freezing a snapshot into the PR body is noise.
- Skip the "## Summary" header too -- just write the bullet points directly.
- Before merging, refresh the PR title and description so they match what actually shipped. A branch drifts as review feedback lands, leaving a title or body written for the first commit stale.
