claude-api

Overview of claude-api skill

What claude-api skill is for

The claude-api skill is an implementation guide for building against the Claude API and Anthropic SDKs, not a generic prompt pack. It helps you choose the right integration surface, pick the correct language-specific docs, and start with working defaults for real application code.

If you are adding Claude to a product, backend, internal tool, CLI, or agent workflow, this skill is a strong fit. If you are just asking for general coding help, or your project uses another model provider SDK, it is not the right skill.

Who should install claude-api

Best-fit users are developers who need to move from “I want to use Claude” to “I have a correct request shape, SDK setup, and workflow for my stack.” That includes:

• API developers choosing between raw HTTP, SDKs, and Agent SDK
• teams adding streaming, tool use, files, or batch processing
• developers working in python, typescript, go, java, php, ruby, csharp, or plain curl

What makes claude-api different

The main value of claude-api is decision reduction. Instead of one monolithic doc, it gives you:

• a trigger boundary: use it when the work is specifically about Claude API or Anthropic SDKs
• language detection guidance so you read only the relevant folder
• practical defaults, including claude-opus-4-6, adaptive thinking, and streaming for longer requests
• separate coverage for adjacent concerns like tool use, files API, batches, error codes, models, prompt caching, and live sources

That makes the claude-api skill more useful than a generic “show me API code” prompt when you care about correct SDK patterns and feature-specific workflows.

The real job-to-be-done

Most users are not looking for a repo tour. They want to answer questions like:

• Which surface should I use: raw HTTP, Claude API SDK, or Agent SDK?
• What is the fastest correct install path for my language?
• How should I structure requests for streaming, tools, or longer outputs?
• What files should I read first so I do not miss constraints or language-specific support gaps?

The skill is strongest when you already know you want Claude and need implementation guidance with fewer wrong turns.

How to Use claude-api skill

Install claude-api skill

Install from the Anthropic skills repository:

npx skills add https://github.com/anthropics/skills --skill claude-api

After install, use claude-api when your task explicitly involves:

• anthropic
• @anthropic-ai/sdk
• claude_agent_sdk
• Claude API request design
• Anthropic SDK migration or implementation

Do not reach for it for unrelated app code, ML theory, or OpenAI-specific integrations.

Start with the right files

For most users, the fastest reading order is:

1. skills/claude-api/SKILL.md
2. your language folder, such as python/claude-api/README.md or typescript/claude-api/README.md
3. feature files you actually need:
   • streaming.md
   • tool-use.md
   • files-api.md
   • batches.md
4. shared references:
   • shared/error-codes.md
   • shared/models.md
   • shared/prompt-caching.md
   • shared/live-sources.md
   • shared/tool-use-concepts.md

This path matters because the repository is structured by implementation choice, not by beginner walkthrough.

Choose the right surface first

A common adoption blocker is starting with the wrong API surface.

Use the Claude API SDK docs when you need direct model calls in app code.

Use raw curl examples when:

• you need to validate request shape quickly
• your language has no official SDK in the current project
• you want a transport-level debug baseline

Use Agent SDK docs only if you are building agentic workflows and your language supports them. In this skill, Agent SDK coverage is present for python and typescript, while some other languages only cover Claude API usage.

Detect language before copying examples

The claude-api guide is intentionally language-split. Before prompting or reading further, identify the project language from files such as:

• package.json, tsconfig.json → TypeScript/JavaScript
• pyproject.toml, requirements.txt → Python
• go.mod → Go
• pom.xml, build.gradle → Java
• composer.json → PHP
• Gemfile → Ruby
• .csproj → C#

This sounds obvious, but it prevents a common failure mode: asking for patterns that exist in one SDK but not another.

Use the built-in defaults intentionally

The claude-api usage guidance in SKILL.md sets strong defaults:

• model: claude-opus-4-6
• thinking: thinking: {type: "adaptive"}
• streaming for long input, long output, or high max_tokens

These defaults are useful because they reduce timeout risk and improve first-pass quality on harder tasks. If you omit them in a vague prompt, you often get shorter, less production-ready examples.

Pass the minimum inputs the skill actually needs

To get a useful result from claude-api, provide:

• your language and runtime
• whether you want Claude API, SDK, or Agent SDK
• the exact feature you need: basic messages, streaming, tool use, files, batches
• your execution environment: local app, server, CLI, cloud function, etc.
• any constraints: no hardcoded keys, async only, framework requirements, cloud provider routing

Without that, the output tends to stay generic and may miss feature availability differences between SDKs.

Turn a rough goal into a strong claude-api prompt

Weak prompt:

Help me use Claude in my app.

Stronger prompt:

Use the claude-api skill. My project is TypeScript with package.json. I need a server-side example using @anthropic-ai/sdk with claude-opus-4-6, streaming enabled, environment-variable auth, and one tool call for weather lookup. Show install, client setup, the request shape, and basic error handling for 429 and 500.

Why this works better:

• it selects the correct folder
• it narrows to one surface
• it states must-have features
• it asks for operational details that affect successful integration

Use install commands by language

A practical reason to use the claude-api skill is that it surfaces the correct package names quickly:

• C#: dotnet add package Anthropic
• Go: go get github.com/anthropics/anthropic-sdk-go
• PHP: composer require "anthropic-ai/sdk"
• Ruby: gem install anthropic

For Java, use com.anthropic:anthropic-java. For raw HTTP, start with the curl/examples.md path.

If you need Python or TypeScript, go directly into the language-specific README.md and feature docs in those folders instead of guessing package usage from another language example.

Know the important feature gaps by language

This skill helps most when you care about supported features, not just syntax.

Examples surfaced by the repo:

• Go supports the Claude API and beta tool use, but Agent SDK is not available
• Java supports Claude API and beta tool use, but Agent SDK is not available
• Ruby supports Claude API and a beta tool runner, but not Agent SDK
• PHP supports Claude API and multiple client backends, including Bedrock, Vertex AI, and Foundry
• C# supports tool use via Messages API, but not a class-annotation tool runner

That means “show me tool use” is not a complete request; the answer depends on language.

Validate with curl before debugging SDK behavior

If your first SDK attempt fails, use the raw HTTP example in curl/examples.md as a control. This is one of the highest-value workflows in the repository because it separates:

• auth and endpoint problems
• malformed JSON
• model and parameter issues
• SDK-specific typing or serialization mistakes

The repo also explicitly recommends parsing JSON with jq, not grep or sed, which is a small but important reliability detail.

Read shared error handling early

Before production use, read shared/error-codes.md. It is short and materially useful for claude-api for API Development because it tells you which failures are retryable.

Important examples:

• 400 usually means request shape or parameter issues
• 401 and 403 are auth or permission problems
• 429, 500, and 529 are the main retryable cases
• 413 means your request is too large and needs restructuring, not blind retries

This is the difference between shipping a resilient integration and repeatedly failing the same request.

claude-api skill FAQ

Is claude-api better than a normal prompt?

Yes, when your task is implementation-specific. A normal prompt can generate plausible code, but claude-api is better at routing you to the right SDK surface, language docs, and feature notes. That reduces subtle mistakes like using unsupported tool-runner patterns in the wrong language.

Is claude-api suitable for beginners?

Yes, if you already understand basic programming and API keys. The skill does not replace general coding instruction; it is best for beginners who know their stack and want a correct Claude integration path without reading every folder manually.

When should I not use claude-api?

Skip claude-api if:

• your task is general software engineering, not Claude integration
• your app is built around another AI provider SDK
• you need model-agnostic architecture advice more than Anthropic-specific implementation
• you are doing ML training or data science work rather than application integration

Does claude-api cover more than basic messages?

Yes. The repo includes focused docs for streaming, tool use, files API, batches, error handling, model references, prompt caching, and live sources. That makes the claude-api install decision more favorable if you know your project will expand beyond a single request-response example.

Which languages are best covered?

The visible repo structure shows strong coverage across python, typescript, go, java, php, ruby, csharp, and curl. Python and TypeScript also include Agent SDK material, so they are the best fit if agent workflows are part of your roadmap.

How to Improve claude-api skill

Give claude-api sharper implementation context

The biggest quality upgrade is to stop asking for “an example” and instead specify:

• language
• feature
• framework or runtime
• auth method
• deployment context
• whether you need direct SDK calls or agent behavior

For example:

Use claude-api for Python. I need streaming with the Claude API in a FastAPI endpoint, API key from env, graceful handling for 429 and 529, and code structured so I can add tool use later.

That leads to code you can keep, not just inspect.

Ask for one feature path at a time

The repository is broad. If you ask for streaming, tools, files, and batches in one pass, the result usually becomes shallow. Better workflow:

1. get a minimal messages example working
2. add streaming
3. add tool use
4. add files or batches if needed
5. add retries and production guards

This sequencing matches how the skill is organized and reduces debugging complexity.

Prevent common claude-api failure modes

The most common issues are predictable:

• choosing the wrong language docs
• assuming every SDK supports the same helper abstractions
• forgetting streaming for long responses
• omitting max_tokens
• hardcoding API keys in examples
• treating retryable and non-retryable errors the same way

If you ask claude-api to include these safeguards explicitly, the output quality improves a lot.

Request repository-grounded answers

A practical way to improve claude-api usage is to tell the assistant to anchor output to specific repo files. For example:

Use claude-api and base the answer on typescript/claude-api/README.md, typescript/claude-api/streaming.md, and shared/error-codes.md. Give me the shortest production-safe starter.

This prevents drift into generic sample code that looks right but ignores the skill's structure and constraints.

Iterate after the first output

After the first answer, refine with concrete follow-ups:

• “Convert this to raw HTTP so I can debug transport issues.”
• “Adapt this to my project’s go.mod and add backoff for 429.”
• “Replace the simple message call with tool use supported by this language.”
• “Show what changes if I use Bedrock or Vertex in PHP.”

That is the fastest way to turn the claude-api guide into working project code rather than a one-shot snippet.