Local docs lookup
Skill yigityildiz0/universal-ai-skill-library/skills/common/local-docs-lookup
Ground agent answers in local library documentation (pydoc, go doc, vendored READMEs, help() in REPLs) rather than routing queries through a third-party.From its SKILL.md
npx -y skills add yigityildiz0/universal-ai-skill-library --skill local-docs-lookupAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
6.9 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it
Local Documentation Lookup
Ground agent answers in locally-available documentation before considering any external lookup service. Under the MCP Registry Policy in AGENTS.md, documentation-lookup-as-service MCPs route library names and query text to a third party - this skill is the policy-compliant replacement.
When to Use This Skill
Use this skill when:
- The agent needs API / library details to answer a question correctly.
- The user asks "how do I use X in library Y?" or "what's the signature of foo?"
- You notice the agent hallucinating API calls, method names, or argument orderings.
- A failing test or stack trace references a library function whose real signature the agent should verify rather than guess.
When NOT to use:
- The question is about the user's own code - use direct file reads or
devai-code-searchinstead. - The question is about a runtime error in the user's code - use
bug-localizationorerror-explanation-generator. - The documentation you need is genuinely online-only and the user has explicitly approved fetching a specific public URL - fetch it via
devai-web-fetchwith the one URL (policy-compliant per the decision tree inAGENTS.md).
Instructions
Walk this lookup sequence in order and stop at the first source that answers the question.
Step 1: Introspect the installed package
Python, Ruby, Node, Go all ship REPL introspection. Use it first.
# Python
python -c "import requests; help(requests.get)"
python -m pydoc requests.get
python -c "import inspect, requests; print(inspect.signature(requests.get))"
# Node (REPL)
node -e "console.log(require.resolve('axios'))"
# Then Read the resolved path's README / index.d.ts
# Go (from a module directory)
go doc encoding/json.Marshal
go doc -all encoding/json.Marshaler
# Ruby (irb)
ruby -rjson -e "puts JSON.method(:parse).source_location"
This is the highest-fidelity source because the docstring / signature comes from the exact version installed.
Step 2: Read the vendored package README
Every installed package ships its README on disk.
# Python
find "$(python -c 'import sys; print(sys.prefix)')"/lib/*/site-packages/<package-name> -name "README*" -print
# Node
ls node_modules/<package>/README*
# Ruby
gem contents <gem-name> | grep -i readme
Read the README with the Read tool. This usually answers "what does this library do and how do I use its main entry points."
Step 3: Read the package's shipped .md / .txt / .rst docs
Many packages ship a docs/ directory, a CHANGELOG.md, or inline code comments that contain usage examples.
# Python
ls "$(python -c 'import sys; print(sys.prefix)')"/lib/*/site-packages/<package>/docs 2>/dev/null
find "$(python -c 'import sys; print(sys.prefix)')"/lib/*/site-packages/<package> -name "*.md" -maxdepth 3
# Node
find node_modules/<package> -name "*.md" -maxdepth 3
Step 4: Read the package's type stubs or source
TypeScript .d.ts files, Python type stubs (*.pyi), and plain source are authoritative for signatures.
# Node / TypeScript
cat node_modules/<package>/dist/index.d.ts
cat node_modules/<package>/dist/<submodule>.d.ts
# Python - go straight to the source
python -c "import <package>; print(<package>.__file__)"
# Then Read the printed path.
Step 5: Check the project's own shipped docs
Many well-organized projects ship a docs/ tree in their own repo at <repo-root>/docs/ with guides, ADRs, and references. Always grep this tree before reaching for external sources.
find docs/ -name "*.md" -print
grep -r "<symbol-or-phrase>" docs/
Step 6: Local man pages
For CLI tools and system libraries:
man <command>
<command> --help
Step 7 (last resort, with user approval): devai-web-fetch a single URL
If the prior steps did not answer the question AND the official documentation is online, ask the user:
"The information is not in any local source I can find. Would you like me to fetch the official docs page at
<URL>viadevai-web-fetch? This makes one outbound HTTPS call to the URL you approve; no third-party intermediary is involved."
If the user approves, call devai-web-fetch with the single URL. Do not perform follow-up fetches without re-asking.
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "grep-ing the repo is slower than just asking the MCP" | The initial lookup via pydoc / README is 5-10 seconds. The ongoing cost of the MCP is every query leaking library names, plus a new dependency on an external service's uptime. |
| "The MCP has more up-to-date docs than what's installed locally" | Your code runs against the installed version - that's the version whose docs actually matter. An MCP returning the bleeding-edge docs may describe features that don't exist in your installed version, which is worse than nothing. |
| "I don't know where the package is installed" | python -c "import X; print(X.__file__)" or node -e "console.log(require.resolve('X'))" solves this in one line. Take the one line. |
| "The package has no README" | If a package ships with no README and no source comments, its maintainability is the real problem. Do not paper over that with a remote lookup - flag the package for replacement. |
Verification
- The answer cites at least one local source (file path or introspection command output).
- If
devai-web-fetchwas used, the user explicitly approved the URL. - The answer matches the installed version of the package (not a newer API the user does not have).
- No documentation-as-service MCP was invoked.
- Library names and query text did not leave the local machine except to the user-approved URL (if any).
Related Skills
rag-implementation- general RAG over arbitrary document corpora; this skill is the specialized flow for library documentation.context-manager- for shaping what context the agent loads; feed local doc extracts via this skill.code-semantic-search- for searching the user's own code (not library docs).error-explanation-generator- when the library question is triggered by a specific runtime error.
Notes on the Gap
This skill covers cached / installed-version documentation. It does NOT recreate a continuously-updated library index such as a search-engine-style lookup over every package version on PyPI / npm / crates.io. That gap is real; under the MCP Registry Policy, closing it requires either (a) running a local mirror of the documentation corpus, which is large and infrequently needed, or (b) accepting the single-URL user-approved fetch via devai-web-fetch for the rare case where the locally-installed version is genuinely insufficient. Document both as a known limitation rather than papering over it with a third-party service.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.