Borrowing it
Nothing to install: this file belongs to dancinlab/void. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/dancinlab/void/void/main/.agents/skills/writing-commit-messages/SKILL.mdgit clone --depth 1 https://github.com/dancinlab/voidWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/dancinlab/void/writing-commit-messages)<a href="https://agentmods.dev/skills/dancinlab/void/writing-commit-messages"><img src="https://agentmods.dev/badge/skills/dancinlab/void/writing-commit-messages/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/dancinlab/void/writing-commit-messages"><img src="https://agentmods.dev/badge/skills/dancinlab/void/writing-commit-messages.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00031 | $0.00490 |
| Opus 5.5 | $0.00012 | $0.00196 |
| Sonnet 5.5 | $0.00006 | $0.00098 |
| Haiku 4.5 | $0.00003 | $0.00049 |
Grade A, and why
writing-commit-messages scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
95% identical to writing-commit-messages — 2 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
What it actually says
Writing Commit Messages
Write commit messages that follow commit style guidelines for the project.
Format
<subsystem>: <summary>
<reference issues/PRs/etc.>
<long form description>
Rules
Subject line
- Subsystem prefix: Use a short, lowercase identifier for the
area of code changed (e.g.,
terminal,vt,lib,config,font). Determine this from the file paths in the diff. If changes span the macOS app, usemacos. For GTK, usegtk. For build system, usebuild. Use nested subsystems with/when helpful and exclusive (e.g.,terminal/osc). - Summary: Lowercase start (not capitalized), imperative mood, no trailing period. Keep it concise—ideally under 60 characters total for the whole subject line.
References
- If the change relates to a GitHub issue, PR, or discussion, list
the relevant numbers on their own lines after the subject, separated
by a blank line. E.g.
#1234 - If there are no references, omit this section entirely (no blank line).
Long form description
- Describe what changed, what the previous behavior was, and how the new behavior works at a high level.
- Use plain prose, not bullet points. Wrap lines at ~72 characters.
- Focus on the why and how rather than restating the diff.
- Keep the tone direct and technical without no filler phrases.
- Don't exceed a handful of paragraphs; less is more.
Workflow
- If
.jjis present, usejjinstead ofgitfor all commands. - Run a diff to see what changes are present since the last commit.
- Identify the subsystem from the changed file paths.
- Identify any referenced issues/PRs from the diff context or branch name.
- Draft the commit message following the format above.
- Apply the commit
- Don't push the commit; leave that to the user.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 63 lines · 31 tokens per session scan A 2d6d781b0282
writing-commit-messages is a skill published in the GitHub repository dancinlab/void (116 stars, last pushed 2mo ago), licensed MIT. It adds 31 tokens to every session and 490 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 95% identical to writing-commit-messages, differing in 2 lines, and is treated as a copy.
Other skills, from other repositories
create-pr
Creates a GitHub PR with a Linear-ticket-prefixed title and a decision-led, narrative description for Prisma 8. Use when the user wants to create a pull request, open a PR, or submit changes for review.
git-commit
Generate well-formatted git commit messages following conventional commit standards.
repo-sync
Manage automatic Git syncing on macOS with repo-sync. Use only when the user explicitly invokes /repo-sync.
mcore-split-pr
Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.
contributing
How to contribute to evlog, covering commit and PR conventions, changesets, the Definition of Done, testing rules, and the authored skills that walk through building a new adapter, enricher, framework integration, or map rule. Load this for any question about contributing, opening a PR, or adding something to the…
engineer-bot-ops
A workflow for carrying an engineering task from scope through implementation and reviewable delivery. It works with a repository's branch, existing changes, rules, checks, and permissions while separating completed, unverified, and next-step work.