claude-api skill

Building LLM-Powered Applications with Claude

This skill helps you build LLM-powered applications with Claude. Choose the right surface based on your needs, detect the project language, then read the relevant language-specific documentation.

Before You Start

Scan the target file (or, if no target file, the prompt and project) for non-Anthropic provider markers - import openai, from openai, langchainopenai, OpenAI(, gpt-4, gpt-5, file names like agent-openai.py or -generic.py, or any explicit instruction to keep the code provider-neutral. If you find any, stop and tell the user that this skill produces Claude/Anthropic SDK code; ask whether they want to switch the file to Claude or want a non-Claude implementation. Do not edit a non-Anthropic file with Anthropic SDK calls. (Exception: the prompt-audit subcommand is non-interactive and does not stop here - it records non-Anthropic provider markers in its report's stated assumptions and never proposes switching a non-Anthropic file to the Anthropic SDK.)

Output Requirement

When the user asks you to add, modify, or implement a Claude feature, your code must call Claude through one of:

1. The official Anthropic SDK for the project's language (anthropic, @anthropic-ai/sdk, com.anthropic.*, etc.). This is the default whenever a supported SDK exists for the project.
2. Raw HTTP (curl, requests, fetch, httpx, etc.) - only when the user explicitly asks for cURL/REST/raw HTTP, the project is a shell/cURL project, or the language has no official SDK.

Never mix the two - don't reach for requests/fetch in a Python or TypeScript project just because it feels lighter. Never fall back to OpenAI-compatible shims.

Never guess SDK usage. Function names, class names, namespaces, method signatures, and import paths must come from explicit documentation - either the {lang}/ files in this skill or the official SDK repositories or documentation links listed in shared/live-sources.md. If the binding you need is not explicitly documented in the skill files, WebFetch the relevant SDK repo from shared/live-sources.md before writing code. Do not infer Ruby/Java/Go/PHP/C# APIs from cURL shapes or from another language's SDK.

If WebFetch or repository access fails (network restricted, timeouts, clone blocked): do not keep retrying - write code from the patterns and namespace/package tables in the {lang}/ file, run the compiler or interpreter on it, and iterate on the error output. For statically-typed SDKs (C#, Java, Go) a compile-fix loop against local errors reaches working code faster than blocked network research.

Defaults

Unless the user requests otherwise:

For the Claude model version, please use Claude Opus 5, which you can access via the exact model string claude-opus-5. Please default to using adaptive thinking (thinking: {type: "adaptive"}) for anything remotely complicated. And finally, please default to streaming for any request that may involve long input, long output, or high maxtokens - it prevents hitting request timeouts. Use the SDK's .getfinal_message() / .finalMessage() helper to get the complete response if you don't need to handle individual stream events

Warning: API Drift - Your Training Prior May Be Stale

Several common Claude API shapes changed in 2025-2026. If you recall a pattern from training, verify it against the {lang}/ files in this skill before writing - the rows below are the most frequent drift points:

The {lang}/ files in this skill are authoritative over recalled patterns.

Subcommands

If the User Request at the bottom of this prompt is a bare subcommand string (no prose), search every Subcommands table in this document - including any in sections appended below - and follow the matching Action column directly. This lets users invoke specific flows via /claude-api . If no table in the document matches, treat the request as normal prose.

Language Detection

Before reading code examples, determine which language the user is working in (exception: for the prompt-audit subcommand, skip this section's ask steps - the audit is non-interactive and its inventory is language-agnostic; when no language is inferable, proceed without asking and state the assumption in the report):

1. Look at project files to infer the language:

• .py, requirements.txt, pyproject.toml, setup.py, Pipfile -> Python** - read from python/
• .ts, .tsx, package.json, tsconfig.json -> TypeScript - read from typescript/
• .js, .jsx (no .ts files present) -> TypeScript - JS uses the same SDK, read from typescript/
• .java, pom.xml, build.gradle -> Java** - read from java/
• .kt, .kts, build.gradle.kts -> Java - Kotlin uses the Java SDK, read from java/
• .scala, build.sbt -> Java** - Scala uses the Java SDK, read from java/
• .go, go.mod -> Go** - read from go/
• .rb, Gemfile -> Ruby** - read from ruby/
• .cs, .csproj -> C# - read from csharp/
• .php, composer.json -> PHP** - read from php/

1. If multiple languages detected (e.g., both Python and TypeScript files):

• Check which language the user's current file or question relates to
• If still ambiguous, ask: "I detected both Python and TypeScript files. Which language are you using for the Claude API integration?"

1. If language can't be inferred (empty project, no source files, or unsupported language):

• Use AskUserQuestion with options: Python, TypeScript, Java, Go, Ruby, cURL/raw HTTP, C#, PHP
• If AskUserQuestion is unavailable, default to Python examples and note: "Showing Python examples. Let me know if you need a different language."

1. If unsupported language detected (Rust, Swift, C++, Elixir, etc.):

• Suggest cURL/raw HTTP examples from curl/ and note that community SDKs may exist
• Offer to show Python or TypeScript examples as reference implementations

1. If user needs cURL/raw HTTP examples, read from curl/.

Language-Specific Feature Support

Every SDK language above supports both the beta Tool Runner and Managed Agents (beta) - Python (@betatool decorator), TypeScript (betaZodTool + Zod), Java (annotated classes), Go (BetaToolRunner in the toolrunner pkg), Ruby (BaseTool + toolrunner), C# (BetaToolRunner + raw JSON schema), PHP (BetaRunnableTool + toolRunner()); code entry points are in the Tool Use Patterns quick reference below. cURL is raw HTTP (no SDK features) and supports Managed Agents.

Managed Agents code examples: see the reading guide in the ## Managed Agents (Beta) section below.

Which Surface Should I Use?

Start simple. Default to the simplest tier that meets your needs. Single API calls and workflows handle most use cases - only reach for agents when the task genuinely requires open-ended, model-driven exploration. "Simplest" means the least code you own: for a hosted, scheduled, or memory-backed agent, Managed Agents is usually the simplest option (no loop code, no state files, no scheduler), even though it's a bigger platform.

Note: Managed Agents is the right choice when you want Anthropic to run the agent loop and host the container where tools execute - file ops, bash, code execution all run in the per-session workspace. If you want to host the compute yourself or run your own custom tool runtime, Claude API + tool use is the right choice - use the tool runner for the agentic loop - its per-turn hooks still give you approval gates, logging, error interception, and conditional execution (see shared/tool-use-concepts.md) - or the manual loop when you want to own the entire loop yourself.

Cloud-provider access. Claude Platform on AWS is Anthropic-operated with same-day API parity - see shared/claude-platform-on-aws.md for client setup. For per-feature availability on Claude Platform on AWS, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry, see shared/platform-availability.md - that table is the single source of truth in this skill; do not infer availability from anywhere else.

Building an Agent: Four Approaches

Once you've decided you actually need an agent (open-ended, model-driven tool use), there are four distinct ways to build one. Two independent questions separate them: who supplies the harness (the agent loop + context management) and who supplies the deployment (the infra the agent runs on). The Tool Runner and the Claude Agent SDK both supply a harness only - you still host and deploy them yourself - which is why they're easy to conflate. Managed Agents (CMA) is the only option that supplies both the harness and managed deployment; the manual loop supplies neither.

The harness/deployment split is the key mental model: options 1, 2, and 4 all leave deployment to you; only option 3 (CMA) adds managed deployment. Options 1-3 are what this skill generates; option 4 is a different library with its own docs - see the disambiguation below.

Tool Runner != Claude Agent SDK. These sound alike but are different packages:

- Tool Runner is part of the regular Anthropic API SDK (anthropic / @anthropic-ai/sdk), reached via client.beta.messages.toolrunner. It automates the request -> execute -> loop cycle for tools you define*. No built-in tools, no filesystem access, no sandbox - you supply every tool and host the compute. It is option 2 above, a thin helper over POST /v1/messages.

- Claude Agent SDK (claude-agent-sdk / @anthropic-ai/claude-agent-sdk) is Claude Code packaged as a library. It ships built-in tools (file read/write/edit, bash, grep, web search), the full agent loop, context management, hooks, subagents, permissions, and sessions. You call query(prompt, options) and it drives everything.

Both are harness-only - you host and deploy them. The difference is scope of harness: the Tool Runner loops over tools you define (with per-turn hooks for approval, interception, result modification, and retries - but no built-in tools); the Agent SDK is the full Claude Code harness with built-in tools. Neither provides managed deployment - that's what Managed Agents (CMA) adds (Anthropic hosts the loop and a per-session sandbox).

This skill covers the Claude API and Managed Agents (options 1-3); it does not generate Claude Agent SDK code. If the user actually wants the Claude Agent SDK, point them to its docs (code.claude.com/docs/en/agent-sdk) - don't substitute the API Tool Runner for it, or vice-versa.

Should I Build an Agent?

Before choosing the agent tier, check all four criteria:

• Complexity - Is the task multi-step and hard to fully specify in advance? (e.g., "turn this design doc into a PR" vs. "extract the title from this PDF")
• Value - Does the outcome justify higher cost and latency?
• Viability - Is Claude capable at this task type?
• Cost of error - Can errors be caught and recovered from? (tests, review, rollback)

If the answer is "no" to any of these, stay at a simpler tier (single call or workflow).

Architecture

Everything goes through POST /v1/messages. Tools and output constraints are fea