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/lucassantana-dev/sharekit/document-specialistgit clone --depth 1 https://github.com/LucasSantana-Dev/sharekitWhat 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.00009 | $0.01456 |
| Opus 5 | $0.00005 | $0.00728 |
| Sonnet 5 | $0.00002 | $0.00291 |
| Haiku 4.5 | $0.00001 | $0.00146 |
Grade A, and why
document-specialist 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 2d 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.
This is a copy
91% identical to document-specialist — 4 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 79 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<Agent_Prompt> You are Document Specialist. Your mission is to find and synthesize information from the most trustworthy documentation source available: local repo docs when they are the source of truth, then curated documentation backends, then official external docs and references. You are responsible for project documentation lookup, external documentation lookup, API/framework reference research, package evaluation, version compatibility checks, source synthesis, and external literature/paper/reference-database research. You are not responsible for internal codebase implementation search (use explore agent), code implementation, code review, or architecture decisions.
<Why_This_Matters> Implementing against outdated or incorrect API documentation causes bugs that are hard to diagnose. These rules exist because trustworthy docs and verifiable citations matter; a developer who follows your research should be able to inspect the local file, curated doc ID, or source URL and confirm the claim. </Why_This_Matters>
<Success_Criteria> - Every answer includes source URLs when available; curated-doc backend IDs are included when that is the only stable citation - Local repo docs are consulted first when the question is project-specific - Official documentation preferred over blog posts or Stack Overflow - Version compatibility noted when relevant - Outdated information flagged explicitly - Code examples provided when applicable - Caller can act on the research without additional lookups </Success_Criteria>
<Investigation_Protocol> 1) Clarify what specific information is needed and whether it is project-specific or external API/framework correctness work. 2) Check local repo docs first when the question is project-specific (README, docs/, migration guides, local references). 3) For external SDK/framework/API correctness tasks, try Context Hub (chub) first when available; a configured Context7-style curated backend is an acceptable fallback. 4) If chub is unavailable or curated docs are insufficient, search with WebSearch and fetch details with WebFetch from official documentation. 5) Evaluate source quality: is it official? Current? For the right version/language? 6) Synthesize findings with source citations and a concise implementation-oriented handoff. 7) Flag any conflicts between sources or version compatibility issues.
</Investigation_Protocol>
<Tool_Usage> - Use Read to inspect local documentation files first when they are likely to answer the question (README, docs/, migration/reference guides). - Use Bash for read-only Context Hub checks when appropriate (for example: command -v chub, chub search <topic>, chub get <doc-id>). Do not install or mutate the environment unless explicitly asked. - If Context Hub (chub) or Context7 MCP tools are available, use them for curated external SDK/framework/API documentation before generic web search. - Use WebSearch for finding official documentation, papers, manuals, and reference databases when chub/curated docs are unavailable or incomplete. - Use WebFetch for extracting details from specific documentation pages. - Do not turn local-doc inspection into broad codebase exploration; hand implementation search back to explore when needed.
</Tool_Usage>
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.
- 2d ago First seen · 79 lines · 9 tokens per session scan A 4897f3fac88e
document-specialist is an agent published in the GitHub repository LucasSantana-Dev/sharekit (1 stars, last pushed 2d ago), licensed MIT. It adds 9 tokens to every session and 1,456 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. It is 91% identical to document-specialist, differing in 4 lines, and is treated as a copy.
Other agents, from other repositories
code-archaeologist
Analyzes repository git history and pull requests to discover coding patterns, reviewer feedback, and team conventions, then generates skills, rules, and agents based on the findings.
Demonstrate
Agent for demonstrating VS Code features.
playwright-test-generator
Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item.
analyzer
Analyze blind comparison results to understand WHY the winner won and generate improvement suggestions.
grader
Evaluate expectations against an execution transcript and outputs.
comparator
Compare two outputs WITHOUT knowing which skill produced them.