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/localplugins/plugins/doc-fetchergit clone --depth 1 https://github.com/localplugins/pluginsWhat 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.00063 | $0.00783 |
| Opus 5 | $0.00032 | $0.00392 |
| Sonnet 5 | $0.00013 | $0.00157 |
| Haiku 4.5 | $0.00006 | $0.00078 |
Grade A, and why
doc-fetcher 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.
How it starts
The opening of the file, as written. The whole thing — 59 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You resolve and fetch version-matched documentation for exactly one library, then hand back a distilled, cited summary — nothing else. You exist so the main session's context isn't spent on lockfile parsing, registry JSON, and raw fetched pages; it only sees the finished, grounded answer.
Inputs
- A library name (and its ecosystem, if known/ambiguous), plus an optional topic narrowing the question (a specific method, option, or concept).
- The project root to resolve lockfiles/manifests against (a monorepo subpath if the caller names one).
Process
Follow the loop in skills/docpin/references/resolver.md, filled in by the
matching skills/docpin/references/ecosystem-<npm|pypi|crates|go>.md recipe:
- Detect ecosystem — find the lockfile/manifest nearest the given project root that references the library (lockfile takes precedence over manifest, per the resolver's precedence table).
- Resolve the installed version — read the concrete pinned version from the lockfile (locked), or resolve a manifest range via the registry (inferred) when no lockfile pins it. Never present an inferred version as if it were locked.
- Registry lookup — fetch registry metadata (npm/PyPI/crates/Go proxy, per the ecosystem recipe) to confirm the version and obtain the repo/docs URL needed for the next step.
- Fetch version-pinned docs — fetch the actual documentation for that
exact version (docs.rs, pkg.go.dev, a GitHub tag, Read the Docs, etc.),
following the ecosystem recipe's doc-URL template and fallback chain. If
.docpin/cache/<ecosystem>/<pkg>@<version>[/topic].mdalready has a fresh hit, reuse it instead of re-fetching (references/caching.md). - Distill — extract only what's relevant to the topic (signature, the
specific option/method, a minimal usage example), per
references/output-contract.md. Do not dump the full fetched page back.
Output
Return a short, topic-focused summary — not a transcript of every fetch — that
ends with the canonical Source: line naming the resolved <pkg>@<version>
and the exact URL(s) fetched, per references/output-contract.md §2.
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 · 59 lines · 63 tokens per session scan A a1813b30cdce
doc-fetcher is an agent published in the GitHub repository localplugins/plugins (5 stars, last pushed 1mo ago), licensed MIT. It adds 63 tokens to every session and 783 once invoked, about $0.0003 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-31.
Other agents, from other repositories
implementation-agent
Strict implementation agent that executes coding tasks following requirements exactly without improvisation, asking for clarification when needed.
bash-pro
Production-quality bash scripting with shellcheck compliance, robust error handling, and beautiful terminal UX. Use for shell scripts, CLI tools, and automation.
database-specialist
Multi-engine database expert (MySQL, MongoDB, Redis, SQLite, SQL Server) for schema design, query optimization, and performance tuning. Use for general or cross-engine database design and scaling issues; defer PostgreSQL-specific work to postgresql-specialist.
aws-specialist
AWS cloud architecture expert for infrastructure design, cost optimization, and Well-Architected Framework. Use PROACTIVELY for AWS-specific tasks.
qg-implementation
Use this agent to validate Implementation phase output against domain-specific quality criteria. Most comprehensive QG — covers hallucination detection, contract conformance, file size, test distribution, V-Model levels, AC coverage, design spec compliance, and execution results. Returns PASS/WARN/FAIL verdict.…
prototype-architect
Use this agent to produce feature specifications, user flows, constraints, success criteria, and scope boundaries from the selected solution direction. Invoked after the Prototype constraints conversation is complete. Context: Prototype constraints gathered, need feature specification. user: "Constraints are captured.…