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 grimoire-rs/grimoire --skill docs-reviewgit clone --depth 1 https://github.com/grimoire-rs/grimoireWrote 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/grimoire-rs/grimoire/docs-review)<a href="https://agentmods.dev/skills/grimoire-rs/grimoire/docs-review"><img src="https://agentmods.dev/badge/skills/grimoire-rs/grimoire/docs-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/grimoire-rs/grimoire/docs-review"><img src="https://agentmods.dev/badge/skills/grimoire-rs/grimoire/docs-review.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.00120 | $0.00952 |
| Opus 5.5 | $0.00048 | $0.00381 |
| Sonnet 5.5 | $0.00024 | $0.00190 |
| Haiku 4.5 | $0.00012 | $0.00095 |
Grade A, and why
docs-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 21d 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 — 77 lines — stays where its author put it; the contents beside it link to each section on GitHub.
docs-review
The docs-quality rule loads when an agent edits a page. This skill is the
explicit trigger: grade pages nobody is editing, pages in unusual places, and
pages in a format the scripts only partly read.
Stop condition
Stop when every target page has a verdict: each finding as
path:line: DOC-XXX-nn: message, or clean. Mark any finding no script
produced unverified: reading heuristic. Report; never fix unless asked.
1. Pick the targets
- Named paths or directories: use them as given, whatever their location.
- Nothing named: the branch diff,
git diff --name-only --diff-filter=d "$(git merge-base HEAD origin/HEAD)" -- '*.md' '*.mdx' '*.rst' '*.adoc' '*.asciidoc'. - Drop agent config (
CLAUDE.md,AGENTS.md,SKILL.md,.claude/,.agents/), vendored copies and build output. The rule excludes them too.
2. Load the rule
Read the installed docs-quality rule index, then only the depth files its
routing table names for the target page types. Find it with
find . -path '*docs-quality*' -name 'docs-quality.md' -not -path '*/node_modules/*'.
Its checks/ directory sits beside it. No hit means the rule is not
installed: say grim add ghcr.io/ocx-sh/lore/docs-quality and stop.
3. Run the checks by format
CHECKS below is that checks/ directory. Every script takes explicit paths,
so pass the targets rather than --root.
| Format | Scripted | Read by hand |
|---|---|---|
.md, .mdx |
the whole gate, in the rule's order | rows the scripts mark heuristic |
.rst, MyST, .adoc |
doc_declaration.py |
everything else, or convert first |
Markdown and MDX:
python3 "$CHECKS/doc_declaration.py" PAGE...
python3 "$CHECKS/prose.py" PAGE...
python3 "$CHECKS/page_type.py" PAGE...
python3 "$CHECKS/landing_check.py" PAGE...
Add doc_examples.py, nav_depth.py and links_raw.py when the review covers
a whole docs tree rather than single pages. Their inputs are a tree.
reStructuredText and AsciiDoc: run doc_declaration.py on the source. The
prose and page-type scripts parse Markdown only. When pandoc is on the PATH,
convert each page into a scratch directory and run them on the copy:
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.
- 21d ago First seen · 77 lines · 120 tokens per session scan A 2b33ea89c9cf
docs-review is a skill published in the GitHub repository grimoire-rs/grimoire (14 stars, last pushed today), licensed Apache-2.0. It adds 120 tokens to every session and 952 once invoked, about $0.0005 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-09-26.
Other skills, from other repositories
oracle
Oracle second-model review: bundle prompts/files, debug, refactor, design.
pr-review
Review open PRs two ways - default is a per-PR deep review with severity-tagged findings, inline comments, and a verdict; --survey runs a risk-tiered triage digest of what's safe to merge first.
pr-triage
First-touch triage for external pull requests - verdict, label, and a welcoming comment within minutes of open.
feedback-builder
Point Aeon at a service's /feedback endpoint - pull what agents reported (bugs, missing features), triage and cluster it, then build the best accepted request as a PR for a human to approve.
[REPLACE: SKILL_NAME]
First-touch review of newly opened PRs on [REPLACE: WATCHEDREPO] — verdict + welcoming comment + label.
no-mistakes
Validate committed feature-branch changes through the no-mistakes pipeline: intent, rebase, review, test, docs, lint, push, PR, and CI. Use when the user asks to run no-mistakes, ship safely, validate before pushing, or gate a change before it reaches upstream.