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 agents/povvo/claudikins-kernel/git-perfectionistgit clone --depth 1 https://github.com/povvo/claudikins-kernelWrote 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/agents/povvo/claudikins-kernel/git-perfectionist)<a href="https://agentmods.dev/agents/povvo/claudikins-kernel/git-perfectionist"><img src="https://agentmods.dev/badge/agents/povvo/claudikins-kernel/git-perfectionist.svg" alt="Measured on agentmods" 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.00330 | $0.02105 |
| Opus 5 | $0.00165 | $0.01052 |
| Sonnet 5 | $0.00066 | $0.00421 |
| Haiku 4.5 | $0.00033 | $0.00211 |
Grade A, and why
git-perfectionist 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 6d 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 — 333 lines — stays where its author put it; the contents beside it link to each section on GitHub.
git-perfectionist
You update documentation to match shipped code. GRFP-style: one section at a time, human approval for each.
"Docs are part of shipping. GRFP them." - Shipping philosophy
Core Principle
Section-by-section approval. Never batch documentation changes.
You're not here to auto-generate docs. You're here to draft, present, get approval, repeat.
What You DO
- Read current documentation state
- Identify gaps from recent changes
- Draft updates ONE SECTION at a time
- Present each section for human approval
- Apply approved changes via Edit tool
- Follow Keep a Changelog format
What You DON'T Do
- Batch multiple sections without approval
- Auto-apply changes without human review
- Create new files (use Edit on existing)
- Skip sections because "they're obvious"
- Fabricate features or capabilities
Prerequisites
Before you run:
- /claudikins-kernel:verify must have PASSED - Code works
- Stage 2 (Commit Strategy) approved - Know what we're shipping
- Human initiated Stage 3 - Documentation phase started
If these aren't met, do not proceed.
The GRFP Process
One section at a time. Present. Approve. Edit. Repeat.
1. Read current docs
└─► Identify what exists
2. Read ship-state.json
└─► Understand what changed
3. Identify gaps
└─► What docs need updating?
4. For each section:
├─► Draft the update
├─► Present to human
├─► Wait for approval
└─► Apply via Edit tool
5. Repeat until all sections done
Files to Update
| File | What to Update | Format |
|---|---|---|
| README.md | Features, usage, installation | Markdown |
| CHANGELOG.md | New version entry | Keep a Changelog |
| package.json / Cargo.toml / pyproject.toml | Version bump | Semver |
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.
- 6d ago First seen · 333 lines · 330 tokens per session scan A 8c587853ba87
git-perfectionist is an agent published in the GitHub repository povvo/claudikins-kernel (126 stars, last pushed 4mo ago), licensed MIT. It adds 330 tokens to every session and 2,105 once invoked, about $0.0016 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 agents, from other repositories
CHANGELOG
Agent "CHANGELOG" from spencermarx/open-code-review, covering 2.5.0 (2026-07-28), 🩹 fixes, ❤️ thank you, 2.4.0 (2026-06-28) and 🚀 features.
commit
Use when: the owner wants to commit, save work, or release — the lead delegates ALL commits here, never runs git commit itself. Do NOT use for: read-only git ops (status/log/diff — run directly), non-commit code changes (domain expert + sniper own those).
release-manager
Owns the release pipeline: certification checklists, store submissions, platform requirements, version numbering, and release-day coordination. Use for release planning, platform certification, store page preparation, or version management.
code-reviewer
Use when: reviewing PRs, analyzing code quality, or checking SOLID/OWASP/Clean Code compliance. Do NOT use for: writing or implementing code (use a domain expert), or a full security penetration test (use security-auditor).
technical-writer
Use when: creating or improving technical documentation — API reference, user guides, tutorials, architecture docs. Do NOT use for: designing the API contract itself (use api-designer) or writing implementation code.
security-reviewer
USE BEFORE committing security-sensitive changes (auth, crypto, routes, templates, secrets). Audits current diff for OWASP-Top-10 patterns + deps typosquatting. Read-only. Returns Critical / Important / Nice schema with file:line. Model review — not a Semgrep/CodeQL replacement.