live-docs-lookup

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-* | Google |

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 docs
• output_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

Google

• 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 |