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 mimfort/rag_for_git --skill maintainability-reviewgit clone --depth 1 https://github.com/mimfort/rag_for_gitWrote 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/mimfort/rag_for_git/maintainability-review)<a href="https://agentmods.dev/skills/mimfort/rag_for_git/maintainability-review"><img src="https://agentmods.dev/badge/skills/mimfort/rag_for_git/maintainability-review/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/mimfort/rag_for_git/maintainability-review"><img src="https://agentmods.dev/badge/skills/mimfort/rag_for_git/maintainability-review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Prompt Injection · line 8 Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.Fix: Audit all comments and invisible characters. Remove any instructions that direct the agent to perform unauthorized actions. Use plain, reviewable content.
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.00073 | $0.01005 |
| Opus 5.5 | $0.00029 | $0.00402 |
| Sonnet 5.5 | $0.00015 | $0.00201 |
| Haiku 4.5 | $0.00007 | $0.00101 |
Grade A, and why
maintainability-review 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 — 118 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Maintainability Review
In rag-reviewer:review-pr use the PR-session tools above. Standalone (no PR session): use
the session-less tools per the reviewer-grounding block when reviewer is connected and the
index is fresh; otherwise fall back to grep/Read.
Goal
Look only for maintainability risks in the selected changes. Ignore performance, security, and general correctness unless they directly explain a maintainability concern.
Prioritize findings such as:
- unnecessary branching, flag combinations, and deep nesting that increase cognitive load;
- large or mixed-responsibility functions that became harder to understand;
- duplication or near-duplication that should likely be consolidated;
- abstractions, wrappers, or indirection layers that hide a simple flow without a clear payoff;
- hidden side effects, implicit contracts, or unclear data flow;
- naming or structure that materially harms readability or makes intent harder to recover;
- changes that drift away from established repository patterns or documented contributor rules;
- behavior changes that should likely carry nearby tests according to project practice;
- edits to generated artifacts when the repository expects source changes plus regeneration.
Repository Context
Before raising project-practice findings, read the repository-local guidance that governs the current workspace.
Prefer this order:
- In
rag-reviewer:review-pr, readCLAUDE.mdorAGENTS.mdviaread_file; in standalone, read them from disk. - Read the nearby implementation to understand existing patterns.
- Compare the change against the established local style before flagging it.
Do not treat personal preference as a project convention.
Method
- Read the diff first.
- Open only the nearby code needed to understand the changed path.
- Prefer concrete maintainability costs over vague "clean code" opinions.
- State assumptions explicitly when a finding depends on local context.
- Suggest a simpler alternative that preserves behavior and better fits local
patterns; put this in the
suggestionfield. - Avoid review spam. Do not invent nits.
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 · 118 lines · 73 tokens per session scan A 3ebb10ebe771
maintainability-review is a skill published in the GitHub repository mimfort/rag_for_git (20 stars, last pushed 6d ago), licensed MIT. It adds 73 tokens to every session and 1,005 once invoked, about $0.0003 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
code-knowledge-graph
Codebase'i knowledge graph olarak analiz et. Dependency, call graph, hotspot analizi.
m1nd-first
Use when investigating a repository, searching for implementation, reviewing changes, working from specs/docs, or preparing a risky code change in an environment where m1nd is available. This doctrine makes m1nd the first investigative layer before grep, glob, or manual file reads, except when the task is pure…
coograph-review
Strict read-only review of the current changes for spec compliance, convention violations, logic bugs, and architecture. Every finding cites a verbatim quote from a fresh file read. Use after implementation, before declaring done.
graphenium
Use when analyzing codebase structure, verifying pre-flight policy compliance, tracing transitive dependency closures, or auditing post-edit scope creep.
celmis-search
Search and read code through Celmis instead of grepping or cat-ing whole repositories. Use when you need where a symbol is defined, who calls it, what a file or module contains, how another service does something ("make a DB connection like in service X", "do authorization the way service X does", "how does X load its…
autoreview
Structured code review through the shared OpenClaw agent-skills installation.