live-docs-lookup
Use when building with any AI SDK or API — Anthropic, OpenAI, or Google. Fetches current documentation in real time before answering, so stale training data doesn't cause bugs. Trigger on: model selection, tool use, function calling, streaming, prompt caching, batch processing, SDK setup, or any AI API integration, planning, debugging, or code review.
Why this skill exists
AI platforms change constantly: model IDs get renamed, parameters get deprecated, new features launch behind flags, entire APIs get replaced. Your training data has a cutoff — this skill fetches live docs before you advise on any AI SDK integration, catching the gap between what you remember and what's actually current.
A 30-second doc check prevents hours of wasted implementation effort.
Step 1: Detect which provider is in scope
Check imports, environment variables, model names, or the user's stated intent:
| Signal | Provider |
|---|---|
import anthropic, from anthropic import, ANTHROPIC_API_KEY, model names like claude-*, opus, sonnet, haiku | Anthropic |
from openai import, import openai, OPENAI_API_KEY, model names like gpt-*, o1, o3, chatgpt-* | OpenAI |
import google.generativeai, from google import genai, import vertexai, GOOGLE_API_KEY, model names like gemini-* |
If multiple providers are in scope (e.g. a multi-provider app), fetch docs for each. If unclear, ask the user which SDK they're targeting before fetching.
Step 2: Fetch the relevant live docs
Use your web fetching tool (WebFetch, web_search, browse, or equivalent).
Always fetch the models page first — model IDs are the most common source of outdated guidance, and the user will copy-paste whatever you put in example code. Stale IDs produce confusing "model not found" errors.
If a URL fails or returns a redirect/404, don't stop — search for it instead. Restrict the search to the provider's official docs domain to avoid landing on blog posts or unofficial mirrors:
- Anthropic:
site:platform.claude.com/docs - OpenAI:
site:developers.openai.com - Google:
site:ai.google.dev
Example queries: site:platform.claude.com/docs adaptive thinking or
site:developers.openai.com responses API. Doc URLs move; the information
is always findable on the canonical domain.
Fetch only what's relevant to the task. Three parallel fetches is ideal; don't flood context with docs the user doesn't need.
Anthropic
| Feature | URL |
|---|---|
| Model IDs (always fetch) | https://platform.claude.com/docs/en/about-claude/models/overview.md |
| Messages API | https://platform.claude.com/docs/en/api/messages |
| Tool use / function calling | https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview.md |
| Streaming | https://platform.claude.com/docs/en/build-with-claude/streaming.md |
| Extended / adaptive thinking | https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking.md |
| Prompt caching | https://platform.claude.com/docs/en/build-with-claude/prompt-caching.md |
| Computer use | https://platform.claude.com/docs/en/agents-and-tools/tool-use/computer-use.md |
| Batch processing | https://platform.claude.com/docs/en/build-with-claude/batch-processing.md |
| Files API | https://platform.claude.com/docs/en/build-with-claude/files.md |
| Code execution tool | https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool.md |
| Structured outputs | https://platform.claude.com/docs/en/build-with-claude/structured-outputs.md |
| SDK setup | https://platform.claude.com/docs/en/api/client-sdks |
| Rate limits | https://platform.claude.com/docs/en/api/rate-limits.md |
OpenAI
| Feature | URL |
|---|---|
| Model IDs (always fetch) | https://developers.openai.com/api/docs/models |
| Chat completions | https://developers.openai.com/api/reference/chat-completions/overview |
| Responses API | https://developers.openai.com/api/reference/responses/overview |
| Function calling / tools | https://developers.openai.com/api/docs/guides/function-calling |
| Streaming | https://developers.openai.com/api/docs/guides/streaming-responses |
| Structured outputs | https://developers.openai.com/api/docs/guides/structured-outputs |
| Batch API | https://developers.openai.com/api/docs/guides/batch |
| Rate limits | https://developers.openai.com/api/docs/guides/rate-limits |
Google / Gemini
| Feature | URL |
|---|---|
| Model IDs (always fetch) | https://ai.google.dev/gemini-api/docs/models |
| Text generation | https://ai.google.dev/gemini-api/docs/text-generation |
| Function calling | https://ai.google.dev/gemini-api/docs/function-calling |
| Streaming | https://ai.google.dev/gemini-api/docs/text-generation#streaming |
| Structured outputs | https://ai.google.dev/gemini-api/docs/structured-output |
| File API | https://ai.google.dev/gemini-api/docs/files |
Step 3: Surface a brief summary
Present only what's relevant and potentially surprising given your training data. Aim for 5–10 bullet points, not a wall of text:
Current recommended models: [list the relevant current model IDs]
Key API details for [features in scope]: [params, headers, syntax that matters]
Watch out for: [deprecations, gotchas, recently changed behavior — omit if nothing notable]
If the docs confirm what you'd expect:
"Docs confirm current expected behavior. Recommended model: claude-opus-4-6."
Step 4: Proceed with the original task
Carry the grounded context forward into all code, tests, plans, and reviews. The correct model IDs, parameter names, and feature knowledge should flow through naturally — don't repeat the summary, just use it.
If invoked before a superpowers skill: proceed to invoke that skill next. The live context is now loaded — carry it forward.
Common things to verify
Things that change often and are most likely to be wrong in training data:
Anthropic
budget_tokens/ thinking params — syntax and supported models have changed across versions; verify current API shape in docsoutput_format/ output config params — naming has changed; verify current parameter structure from docs- Model ID suffixes — never construct date-suffixed IDs from memory; copy exact aliases from the models page
- Beta headers (Files API, Compaction, etc.) — required headers and values change; verify current values from docs before using
- Docs base URL — has moved before; if a URL fails, re-find on
platform.claude.com/docs
OpenAI
- API surface choice — verify which API the docs currently recommend for the user's use case
- Model IDs — always copy from the live models page
- SDK migration details — confirm version-specific breaking changes before suggesting code
- Output formatting features — verify the current recommended pattern from the docs
- Gemini API vs Vertex AI — clarify which surface the user is targeting, then fetch the matching docs
- SDK choice and imports — verify the current recommended SDK/import path from live docs
- Model IDs — always verify from the live models page
Superpowers integration
Live doc lookup is most valuable before any planning, implementation, testing, debugging, or review of AI SDK work — catching stale assumptions before they get baked into a plan or test suite.
| Superpowers skill | Why live docs matter |
|---|---|
| brainstorming | Architecture decisions bake in model choices and API patterns |
| writing-plans | Plans contain model IDs, API call patterns, parameter names |
| test-driven-development | Tests depend on exact response formats, param names, stop reasons |
| systematic-debugging | Debugging API errors needs current known behavior, not assumptions |
| executing-plans | Plans may not have had live doc grounding at write time |
| subagent-driven-development | Subagents write code independently; they need accurate API context upfront |
| dispatching-parallel-agents | Same — agents need correct params from the start |
| requesting-code-review | Reviewers need current docs to spot stale patterns |
| verification-before-completion | Verifying AI API code requires knowing current expected behavior |