Borrowing it
Nothing to install: this file belongs to Sarv/SarvTerminal. 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/Sarv/SarvTerminal/main/.agents/skills/writing-commit-messages/SKILL.mdgit clone --depth 1 https://github.com/Sarv/SarvTerminalWrote 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/sarv/sarvterminal/writing-commit-messages)<a href="https://agentmods.dev/skills/sarv/sarvterminal/writing-commit-messages"><img src="https://agentmods.dev/badge/skills/sarv/sarvterminal/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/sarv/sarvterminal/writing-commit-messages"><img src="https://agentmods.dev/badge/skills/sarv/sarvterminal/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.00489 |
| 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
100% identical to writing-commit-messages — 0 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 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 d76298141711
writing-commit-messages is a skill published in the GitHub repository Sarv/SarvTerminal (67 stars, last pushed 1mo ago), licensed MIT. It adds 31 tokens to every session and 489 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 100% identical to writing-commit-messages, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
release-rollback
Roll a release back for real when post-deploy regression goes red — apc release rollback flips the current version to pulled and the last good version back to current in the release ledger, and (with --mirror) repoints the bare mirror ref. Behind an approval gate; with no previous good version it BLOCKS instead of…
release-tag
Cut a release tag behind a real tier gate and cloud approval readback. The approval, task, approved commit, and resulting tag are bound; self-approval and HEAD drift fail closed. Prod prefixes remain refused.
git-ops
Close out a local coding task on the bound daemon — stage, commit, branch, merge, push via cloud git — and when a merge conflicts, STOP and escalate with the file list instead of auto-resolving. Push reaches only the bare replica; prod-triggering tags are refused.
start-temps-cluster
Start (or restart) a local multi-node Temps cluster using Docker-in-Docker — one control plane + 3 worker nodes, each a privileged DinD container running its own dockerd + temps agent, wired with the real multi-host overlay (VXLAN, computecidr allocation) via tools/dev-cluster/ in whichever checkout/worktree you run…
cli-local-build
Build and test the Kurtosis CLI from source. Compile the CLI binary locally, run it against Docker or Kubernetes engines, and iterate on CLI changes without creating a release. Use when developing or debugging CLI commands.
prismer-github
GitHub via gh CLI: PRs, issues, reviews, repos, auth.