Read-only external knowledge gathering. Walk the 5-tier source ladder; cite every claim to a primary source; flag training-data-only assertions explicitly. Do NOT write, edit, or commit files.
When to Apply / NOT
Apply:
- Library/framework/SDK/API docs — signatures, config options, migration
- Version-specific behavior — changelogs, deprecations, breaking changes
- Vendor announcements, RFCs, public web technical content
- Any named library, framework, SDK, API, CLI tool, or cloud service
NOT apply:
- Questions about a local repo's code — use a codebase exploration workflow instead
- Autonomous goal-directed research loops (multi-step, agent-driven)
- Implementation or file editing
Process
- Identify subject — extract the library, framework, SDK, API, CLI, or topic from the user's message. Capture version if stated (e.g.,
pydantic@2.7). If version unstated, resolve latest stable at Tier 1. - Resolve identifier — look up the canonical name and version from the library's official documentation surface. If no dedicated doc tool is available, use the subject name as the search query and proceed.
- Walk the source ladder — start at Tier 1; proceed to the next tier only on hard failure (source unavailable, no results, clearly non-authoritative hit). State which tier was skipped and why.
- Cross-reference — every factual claim must cite at least one primary source URL. Assertions derived solely from training data must carry
[Speculative — training data only]. - Synthesize — produce Required Output with source URLs and
library@versionidentifiers.
Source Ladder
Priority order (canonical): 1) Official docs 2) API refs 3) Books/papers 4) Tutorials 5) Community
If a source category is unavailable or returns no authoritative results, skip it and move to the next tier — do not halt.
| Tier | Priority | Source type | Use when |
|---|---|---|---|
| 1 | Official docs | Library/framework official documentation site; SDK reference pages | Named library/framework/SDK with a published doc surface |
| 2 | API refs | API reference pages; repository README and docs folders | API signatures, types, configuration keys, repo-architecture details |
| 3 | Books/papers | RFCs; academic papers; vendor whitepapers; standards documents | Standards-body publications, deep technical specifications |
| 4 | Tutorials | Tutorial articles; blog posts; vendor how-to guides | Example-driven walkthroughs when reference docs are insufficient |
| 5 | Community | Repository issues and discussions; community forums; Q&A threads | Real-world usage patterns, upstream known issues, community workarounds |
Required Output
- Subject identification — canonical name + version (e.g.,
pydantic@2.7.4) - Source-cited claims — each claim:
[Claim] — Tier N, source: [URL or doc path] - Confidence labels —
Verified(Tier 1–2 primary source),Probable(Tier 3–4),Speculative(training data only — flag explicitly) - Open questions — claims unanswered after ladder exhaustion; state which tiers were attempted
Anti-Patterns
- Inventing versions, API signatures, or config keys from training data without Tier 1 verification
- Skipping Tier 1 for a named library that has published docs — always attempt official docs first
- Opaque source attribution — every claim needs a citable source URL or an explicit
[Speculative]label - Re-entering a router or orchestrator skill from within this leaf skill — forbidden (recursion guard)