Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/technickai/claude_telemetry/git-commit-messagegit clone --depth 1 https://github.com/TechNickAI/claude_telemetryWhat 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 | $0.00004 | $0.00866 |
| Opus 5 | $0.00002 | $0.00433 |
| Sonnet 5 | $0.00001 | $0.00173 |
| Haiku 4.5 | $0.00000 | $0.00087 |
Grade A, and why
git-commit-message 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 yesterday.
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.
Copies of this mod
1 near-identical copy found in the catalogue:
- git-commit-message — 98% identical, 1 lines differ
How it starts
The opening of the file, as written. The whole thing — 128 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Git Commit Message Guidelines
We write commit messages to communicate with our future selves and teammates. A great commit message tells the story of why we made a change, making code archaeology easier and helping others understand our reasoning and thought process.
Core Principles
- Reflect on the full change before writing the message
- Focus on motivation and reasoning, not just what changed (the diff shows that)
- Scale message length to change importance and size - simple changes get one line, major architectural changes deserve 2-3 paragraphs
- Use imperative mood ("Add feature" not "Added feature")
- Summary line under 72 characters, no period at the end
- Capitalize the first word after any emoji
No-Deploy Marker
For changes that should not trigger deployment (documentation, tests, CI config, etc.),
include [no-deploy] in the commit message. This signals both humans and CI/CD
automation that deployment is unnecessary.
Place the marker either:
- At the end of the summary line if it fits:
Update README with installation steps [no-deploy] - On its own line after the summary for longer messages
Emoji Usage
You have complete freedom to choose ANY emoji that adds value. Start with gitmoji as your reference - if there's a clear gitmoji match, use it. But feel free to get creative and use any emoji that genuinely enhances meaning or clarity.
Include an emoji when it:
- Makes commit history more scannable at a glance
- Provides instant visual categorization of the change type
- Creates useful visual anchors in git log
- Adds personality or context that words alone miss
Skip the emoji entirely when it would feel forced or add no real value. Many excellent commit messages need no emoji at all.
Trust your judgment on which emoji fits best, or whether to use one at all.
Structure
[optional emoji] Summary line under 72 characters
[Optional body when context is needed]
Body is optional. Include when explaining why adds value beyond the summary and diff. When included: explain motivation, problem being solved, impact, trade-offs, or alternatives considered. Wrap at 72 characters. For large/important changes, write 2-3 paragraphs if needed.
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.
- yesterday First seen · 128 lines · 4 tokens per session scan A e237f22cba16
git-commit-message is a cursor rule published in the GitHub repository TechNickAI/claude_telemetry (30 stars, last pushed 10mo ago), licensed MIT. It adds 4 tokens to every session and 866 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other cursor rules, from other repositories
orchestrator-sub
Rules for sub-agents spawned to work on specific tasks.
testing-standards-typescript
When writing tests for typescript.
external-apis
When calling external APIs.
angular-20
This rule provides comprehensive best practices and coding standards for Angular development, focusing on modern TypeScript, standalone components, signals, and performance optimizations.
dev-standard
Apache Superset development standards and guidelines for Cursor IDE.
typescript
Changes to these high-fan-out internals can affect every message, delta, element, or rerun. Keep work in them minimal, and benchmark changes with representative stress-test apps.