API builder pack reference

Every skill in the API builder pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.

Skills for teams building on the Anthropic API — prompt caching, token budgeting, eval generation for skills, and tool-use schema writing.

Skills

eval-harness-generator

Takes a skill's SKILL.md and generates a set of eval cases — trigger queries, expected output shape, and pass/fail criteria — ready to drop into the skill's evals/ directory.

Tier standard · v1.0.3 · SKILL.md · skill page

Use it when adding evals to a new or existing skill, verifying a skill behaves as documented, or building a regression gate before modifying a skill.

A good result:

• Triggers must be realistic. A trigger of "run this skill" is not an eval case — it doesn't test anything specific. Each trigger should be the kind of input a real user would paste.
• expected_shape items must be checkable. "Output is good" is not checkable. "Output contains a numbered repro sequence starting from a clean state" is.
• Cover the refusal cases. The most common gap in skilldrop evals is missing cases for the skill's anti-patterns — the bad outputs the quality bar explicitly forbids. At least 2 of the 8–12 cases must test that the skill refuses or avoids its stated failure mode.
• Don't pad to 12. Eight strong cases beat twelve weak ones. Only add cases that test a distinct failure mode not already covered.

prompt-caching-advisor

Analyzes a prompt or conversation structure and identifies the highest-value cache breakpoints — where to insert cache_control checkpoints to minimize repeated token processing.

Tier standard · v1.0.0 · SKILL.md · skill page

Use it when designing or optimizing a Claude API integration that uses prompt caching, when input costs are dominated by a static system prompt or few-shot block, or when a multi-turn conversation reprocesses the same context on every turn.

A good result:

• Never cache dynamic content. A user query, a timestamp, a database result retrieved per-request — these must not appear in a cached block. If the user's structure embeds dynamic content in an otherwise static block, flag it before recommending the cache.
• One breakpoint per logical boundary. A system prompt with three sections (instructions, reference docs, examples) can have up to three breakpoints. More than four breakpoints on a single request is a signal the structure needs rethinking.
• The last block caches everything before it. This is the most common misunderstanding — the cache breakpoint is not a marker for just that block, it's a marker for the entire prefix up to that point.

token-budget-estimator

Estimates input and output token usage for a described agentic workflow, surfaces the dominant cost drivers, and suggests max_tokens budget controls per component.

Tier standard · v1.0.0 · SKILL.md · skill page

Use it when planning a new Claude API integration, sizing a cost budget for a feature, or diagnosing why a workflow's token usage is higher than expected.

A good result:

• Ranges over false precision. "~2,000–4,000 tokens" is more honest than "3,142 tokens" when you're working from a description. Use ranges when working from descriptions, tighter estimates when working from actual content.
• The table beats the total. A single "~50,000 tokens per session" is nearly useless — the table that shows context accumulation accounts for 40,000 of those gives the developer somewhere to act.
• Name the optimization target. Don't list five optimizations without ranking them. The one that saves 80% of the dominant component beats the one that shaves 5% off a small component.

tool-use-schema-writer

Takes a function description (name, purpose, parameters) and writes a valid Anthropic tool_use JSON schema, with type annotations, required fields, and a description for each parameter. Adds a Python client.messages.create(tools=[...]) snippet only when asked.

Tier standard · v1.0.2 · SKILL.md · skill page

Use it when wiring a Claude agent to a function or API, designing tools for a multi-agent system, or documenting an existing tool for agent consumption.

A good result:

• Descriptions are decision conditions, not function names restated. "Gets the weather" is not a description — "Returns the current temperature and conditions for a given city. Call this when the user asks about current weather, not forecasts." is.
• Required arrays are never omitted. An omitted required array means all fields are optional — the model will skip fields the function actually needs and the call will fail at runtime.
• Enum values always have descriptions. "enum": ["asc", "desc"] without a description leaves the model guessing which to use.

Edit this page on GitHub · View source