AnthropicClaude Certified Architect – Professional2026-102.5 Implement prompt reuse strategies (caching, modular prompts, Skills)
Deliver Skills across controlled runtime surfaces
Completed by the knowledge check
Learning objective
Package reusable procedures and domain knowledge as Skills that load on demand.
Core idea
A Skill packages SKILL.md instructions and supporting files; metadata supports discovery, while the procedure loads when relevant. At professional scope, your problem is delivering that package across products with different runtime, versioning, and governance behavior.
Define the supported surface before promising reuse. A procedure that reads a bundled template can travel readily; one that assumes local credentials, a network connection, or Claude Code-specific frontmatter may not. Portability is a property you test for the whole package, including its scripts and dependencies.
How it works
Design a portable procedure
Keep the main procedure focused on the task and direct Claude to specific reference files when needed. For a procurement Skill, the body can select a proposal template by procurement route, consult the matching policy reference, and run a bundled calculation script. Do not embed every route’s reference library into the main body merely because all files ship together.
Anthropic describes three loading levels: metadata at startup, instructions when triggered, and resources when accessed. Its approximate context guidance is about 100 tokens for metadata and under 5,000 for instructions. These are sizing guidance, not an API acceptance limit. A script executed through bash contributes its output rather than requiring its source to enter model context; reading a reference file does bring that file’s content into context. Keep calculator output concise and relevant to the decision.
For portability beyond Claude Code, use the accepted frontmatter fields: name, description, license, compatibility, metadata, and allowed-tools. Claude Code extensions such as context, argument-hint, and disable-model-invocation cause a hard unexpected-key error on API or claude.ai upload. Separate surface-specific configuration from the portable package. Claude Code-only dynamic context injection also does not function in claude.ai chat or the API.
Bind the API package explicitly
The Skills API creates custom Skills through POST /v1/skills and versions through POST /v1/skills/{skill_id}/versions. Keep SKILL.md at the upload root or the top of a single enclosing folder. The upload must be under 30 MB uncompressed. A name is at most 64 characters using lowercase letters, numbers, and hyphens, without reserved words anthropic or claude; a description is nonempty, at most 1,024 characters, and contains no XML tags.
Messages requests attach at most 20 Skills through container.skills. Each entry has type, skill_id, and optionally version: type: "custom" selects an uploaded Skill, while type: "anthropic" selects a pre-built one. Include the code execution tool, for example type: "code_execution_20250825" with name: "code_execution". Skill attachment alone does not enable its runtime.
The Skills API is out of beta and needs no beta header. The listed code execution tool also needs no beta header. Compatibility still matters: check the selected model’s capabilities.server_tools.code_execution.supported from the Models API. The top-level capabilities.code_execution answers a different question about code calling other tools.
Use a specific custom version ID, such as the skver_... string returned by version creation, in container.skills[].version. Omitting it or setting "latest" selects the newest version, so another workspace member’s upload can change production behavior without a release by your application team. The newest pointer is latest_version_id; do not design a release registry around the beta response’s latest_version field.
Separate package distribution from runtime access
API custom Skills are workspace-wide. Uploading them does not distribute them to claude.ai or a project’s filesystem. Claude Code can use project directories under .claude/skills/ and personal directories under ~/.claude/skills/. Maintain a source release and record its corresponding API version and filesystem deployment; an API Skill ID is not a repository revision.
Claude Code also documents an account-sync path: terminal sessions signed in through a claude.ai account can download enabled account Skills to ~/.claude/skills/synced/ on version 2.1.273 or later. This excludes API-key sessions and sessions without the required feature-flag access, among other restrictions. The sync downloads rather than uploads; editing that directory does not update the account package. Do not treat this account feature as general synchronization of API workspace uploads.
A source release has a corresponding API version and filesystem deployment, and account sync is a separate download path.
On the API, the code execution container has no network access and no runtime package installation. Bundle the needed reference data and use available dependencies, or retain external retrieval in the host application’s separate integration. Claude Code runs with the machine’s network access; claude.ai access depends on user and administrator settings. The same script therefore requires different deployment tests across those surfaces.
The API code execution compatibility page lists the Claude API, Claude Platform on AWS, and Microsoft Foundry. Foundry requires a Hosted on Anthropic deployment. Do not promise the Skills integration for every cloud model endpoint merely because ordinary Messages calls work there. Agent Skills are also outside zero data retention (ZDR) arrangements; a ZDR requirement needs explicit review before this surface is selected.
Govern the package as executable behavior
Anthropic’s enterprise guidance calls for a registry with purpose, owner, version, dependencies, and evaluation status. Store the directory in source control, review every bundled file, and verify reviewed checksums at deployment. Separate author and reviewer: instructions can steer tool use, and scripts can introduce behavior that is absent from the description.
Test trigger accuracy both alone and alongside the active Skill set. A well-performing procurement procedure is still unusable if unrelated tasks load it or qualifying tasks fail to load it. Test output quality and regressions before promoting a version, retain the preceding version for rollback, and log attached Skills at application level. Request inclusion is not proof that Claude invoked every attached Skill.
Key distinctions and trade-offs
Portable format versus portable operation: Accepted frontmatter does not supply missing network access, dependencies, or credentials.
Attached versus used: Metadata makes a procedure discoverable. Relevance and task behavior still require evaluation; attaching 20 Skills is not a guarantee that all execute.
Pinned API version versus filesystem release: They identify different deployments. Record the relationship and verify each supported surface.
Architecture / decision scenario
A government-services vendor wants one procurement procedure in an API drafting service and developers’ Claude Code sessions. Only 5% of 2,000 daily requests need its 12,000-token reference library. The delivery lead proposes adding the whole library to every system prompt and running the existing local script unchanged on the API.
The architect selects a compact Skill with route-specific reference files instead. The script attempts to fetch live procurement rates, which the API container cannot do. The host supplies an approved rate snapshot in the supported workflow; the package calculates from that snapshot. The platform team tests the API deployment with code execution enabled and pins its custom skver_... version. Developers receive the reviewed filesystem release rather than an assumption that API upload synchronizes it.
The domain owner approves the reference content, security reviews the script, and platform engineering evaluates positive triggers, unrelated tasks, and coexistence. The architect rejects the always-loaded library because 95% of requests do not need it, but keeps universal drafting requirements in system. The procurement package is promoted only after both surfaces pass; retention requirements are reviewed explicitly because Skills are not ZDR-covered.
Common exam traps
- Assuming a Skill pinned on the API is also pinned in Claude Code.
- Omitting the code execution tool after attaching a Skill.
- Using
"latest"in production and calling the deployment pinned. - Expecting API containers to install packages or fetch external data.
- Assuming API workspace distribution and claude.ai account sync are the same feature.
What to remember
Release the entire package for each supported runtime. Pin API versions, test selective loading and coexistence, and verify dependencies rather than assuming portability. Keep the package’s source, ownership, deployed versions, and rollback relationship explicit.
Knowledge check
A team attaches its custom invoice-audit Skill to Messages API requests through container.skills, pinned to a skver_ version ID. The team has verified model compatibility and the Skill and version IDs. Which additional request element provides the attached Skill’s runtime?
tools arraySKILL.md text in its system prompt"latest" in place of the version IDcontainer.skills does not enable its runtime; the request must also declare the tool, for example code_execution_20250825 . Neither the Skills API nor that tool needs a beta header, copying SKILL.md into system bypasses the package and its bundled files, and the version choice controls which package runs, not whether it can.A payments team attaches its custom Skill on the Claude API with version: "latest". A colleague in the same API workspace uploads a new version to try an idea, and production output changes within the hour without any release by the payments team. Which change prevents a recurrence?
.claude/skills/ directorylatest_version from the beta response before each requestdisable-model-invocation: true in the Skill’s frontmatterversion to the reviewed version’s skver_ ID"latest" resolves to the newest version uploaded to the workspace, so anyone with workspace access can change production; a specific skver_ ID pins the reviewed package. A .claude/skills/ directory is a Claude Code filesystem deployment rather than the API one, reading the newest pointer still follows the colleague’s upload, and disable-model-invocation is a Claude Code extension that the Skills API rejects at upload.A procurement Skill runs on the Claude API. Its bundled script fetches the day’s exchange rates from a public endpoint and fails inside the code execution container. Code execution is the only tool available to Claude in this deployment. The calculation must stay in the Skill and use rates no older than one day. Which design meets this?
allowed-tools frontmatter grant access to the endpointSKILL.md instructions direct Claude to fetch the rates itselfallowed-tools pre-approves tools rather than opening network access, and asking Claude to fetch cannot supply network access when its only tool is that container.A team’s Skill uses disable-model-invocation: true and argument-hint in its frontmatter, and Claude Code developers must keep invoking it only by hand. Uploading the same directory to the Skills API fails with an unexpected-key error. The team wants one reviewed procedure on both surfaces. What should it do?
compatibility fieldname , description , license , compatibility , metadata and allowed-tools , and reject any other key with a hard error. Keep the portable package as the reviewed procedure and add Claude Code extensions only where Claude Code reads them; a claude.ai upload follows the same rules. Removing the fields everywhere drops the manual-only behavior developers need, and compatibility describes environment requirements without turning on Claude Code behavior.References
- Anthropic, Agent Skills
- Anthropic, Using Skills with the API
- Anthropic, Code execution tool
- Anthropic, Skills for enterprise
- Anthropic, Extend Claude with skills