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 skills add JeremyDev87/codingbuddy --skill git-mastergit clone --depth 1 https://github.com/JeremyDev87/codingbuddyWrote 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/jeremydev87/codingbuddy/git-master)<a href="https://agentmods.dev/skills/jeremydev87/codingbuddy/git-master"><img src="https://agentmods.dev/badge/skills/jeremydev87/codingbuddy/git-master/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/jeremydev87/codingbuddy/git-master"><img src="https://agentmods.dev/badge/skills/jeremydev87/codingbuddy/git-master.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.00039 | $0.02869 |
| Opus 5.5 | $0.00016 | $0.01148 |
| Sonnet 5.5 | $0.00008 | $0.00574 |
| Haiku 4.5 | $0.00004 | $0.00287 |
Grade A, and why
git-master 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.
How it starts
The opening of the file, as written. The whole thing — 359 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Git Master
Overview
Messy git history obscures intent, makes debugging harder, and wastes reviewer time. Clean history tells the story of WHY changes were made, not just WHAT changed.
Core principle: Every commit should be a single, complete, logical change that can be understood, reverted, or cherry-picked independently.
Violating the letter of this process is violating the spirit of clean version control.
The Iron Law
ONE LOGICAL CHANGE PER COMMIT. NO EXCEPTIONS.
If a commit does two things, it should be two commits. If a commit is incomplete, it should not exist yet.
No exceptions:
- "I'll split it later" → Split it now
- "It's a small extra change" → Separate commit
- "They're related" → Related is not identical
When to Use
Use for ANY git operation beyond trivial:
- Creating commits (single or multiple)
- Rebasing branches (interactive or standard)
- Cherry-picking commits across branches
- Cleaning up history (amend, squash, fixup)
- Resolving merge conflicts
- Preparing branches for review
Use this ESPECIALLY when:
- Repository has established commit conventions
- Branch has messy work-in-progress commits before PR
- Cherry-picking between release branches
- Resolving complex merge conflicts
- History needs cleanup before merging
Don't skip when:
- "It's just a quick fix" (quick fixes deserve clean commits too)
- "Nobody reads commit history" (future-you does, during
git bisect) - "I'll squash on merge anyway" (squash merges lose valuable context)
When NOT to Use
- Initial prototyping — Experiment freely, clean up before PR
- Throwaway branches — No need for perfect history on disposable work
- Automated commits — CI/CD generated commits follow their own patterns
The Six Phases
Phase 1: Style Detection
BEFORE making any commit, understand the repo's conventions:
-
Analyze Recent History
git log --oneline -20 -
Detect Commit Message Pattern
Pattern Example Convention Conventional Commits feat(auth): add OAuth2 flowtype(scope): descriptionImperative mood Add user validationVerb-first, present tense Ticket prefix [PROJ-123] Fix login bug[TICKET] descriptionEmoji prefix :bug: Fix null pointerEmoji + description Freeform Fixed the login thingNo consistent pattern
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 · 359 lines · 39 tokens per session scan A 27ba9c901439
git-master is a skill published in the GitHub repository JeremyDev87/codingbuddy (31 stars, last pushed 6mo ago), licensed MIT. It adds 39 tokens to every session and 2,869 once invoked, about $0.0002 per session on Opus 5.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 skills, from other repositories
ring:generating-pr-descriptions
Generating pull request descriptions from git branch changes with automatic title generation, change-type detection, and smart analysis. Uses branch-only scope to avoid full history analysis. Use when preparing a PR for review. Skip when the PR is a single trivial commit or description already exists.
review
Structured code review with parallel audit agents, confidence-scored triage, and optional auto-fix. Examines uncommitted changes, staged diffs, commit ranges, or specific paths. Produces a tiered report (MUST-FIX / RECOMMENDED / NIT) backed by evidence, then optionally applies fixes with verification.
feature
Full per-feature pipeline: implement → testloop → evaluator challenge → coder feedback → document → commit.
quick
/quick — Lightweight Feature Workflow.
wrap-up-branch
Finish a feature branch: add missing tests, review and fix the code, align docs, then merge only after explicit confirmation.
commit
Create a user-requested Conventional Commit from the staged changes.