Research Command
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@version identifiers.
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)
1---2name: research-503description: Read-only external knowledge gathering via ODIN's 5-tier doc ladder (Official docs → API refs → Books/papers → Tutorials → Community). For library APIs, framework behavior, SDK migrations, version-specific docs, vendor announcements, RFCs. Verifies claims against primary sources. Invoke on "how does X library work", "migration guide", "docs for", or any named library/framework/SDK/API/CLI/service.4---5
6# Research Command
7
8Read-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.
9
10## When to Apply / NOT
11
12**Apply:**
13- Library/framework/SDK/API docs — signatures, config options, migration
14- Version-specific behavior — changelogs, deprecations, breaking changes
15- Vendor announcements, RFCs, public web technical content
16- Any named library, framework, SDK, API, CLI tool, or cloud service
17
18**NOT apply:**
19- Questions about a local repo's code — use a codebase exploration workflow instead
20- Autonomous goal-directed research loops (multi-step, agent-driven)
21- Implementation or file editing
22
23## Process
24
251. **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.
262. **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.
273. **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.
284. **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]`.
295. **Synthesize** — produce Required Output with source URLs and `library@version` identifiers.
30
31## Source Ladder
32
33Priority order (canonical): 1) Official docs 2) API refs 3) Books/papers 4) Tutorials 5) Community
34
35If a source category is unavailable or returns no authoritative results, skip it and move to the next tier — do not halt.
36
37| Tier | Priority | Source type | Use when |
38|------|----------|-------------|---------|
39| 1 | Official docs | Library/framework official documentation site; SDK reference pages | Named library/framework/SDK with a published doc surface |
40| 2 | API refs | API reference pages; repository README and docs folders | API signatures, types, configuration keys, repo-architecture details |
41| 3 | Books/papers | RFCs; academic papers; vendor whitepapers; standards documents | Standards-body publications, deep technical specifications |
42| 4 | Tutorials | Tutorial articles; blog posts; vendor how-to guides | Example-driven walkthroughs when reference docs are insufficient |
43| 5 | Community | Repository issues and discussions; community forums; Q&A threads | Real-world usage patterns, upstream known issues, community workarounds |
44
45## Required Output
46
471. **Subject identification** — canonical name + version (e.g., `pydantic@2.7.4`)
482. **Source-cited claims** — each claim: `[Claim] — Tier N, source: [URL or doc path]`
493. **Confidence labels** — `Verified` (Tier 1–2 primary source), `Probable` (Tier 3–4), `Speculative` (training data only — flag explicitly)
504. **Open questions** — claims unanswered after ladder exhaustion; state which tiers were attempted
51
52## Anti-Patterns
53
54- Inventing versions, API signatures, or config keys from training data without Tier 1 verification
55- Skipping Tier 1 for a named library that has published docs — always attempt official docs first
56- Opaque source attribution — every claim needs a citable source URL or an explicit `[Speculative]` label
57- Re-entering a router or orchestrator skill from within this leaf skill — forbidden (recursion guard)
majiayu000