Skills as a Complementary Memory-Adjacent Pattern

A Different Cost Profile Than Memory or Always-Loaded Context

The previous concept's Memory pattern -- a scratchpad file or external store the agent reads and writes -- persists *state* across sessions. A Skill solves an adjacent but distinct problem: it persists *know-how*, and it does so with a cost profile unlike either memory or an always-loaded instruction file. A Skill is reusable markdown -- a SKILL.md file with YAML frontmatter (at minimum a name and a description) plus an instructions body below the frontmatter. On every single turn, Claude scans the name and description of each Skill it has access to, checks them against what the current task actually needs, and only pulls the *full* instruction body into context on a match. If nothing matches, the instructions never enter the context window at all.

That load-on-demand behavior is the whole point, and it's what separates a Skill from something like a CLAUDE.md file: a CLAUDE.md-style always-loaded file is resident in every conversation turn regardless of task, paying a fixed context tax on every single session whether or not it's relevant. A Skill pays almost nothing (just the name and description) until the moment it's actually needed, then pays the full cost only for that turn. For agent construction specifically, this makes Skills a lever for packaging reusable procedural knowledge -- a report-formatting convention, a specialized review checklist -- without inflating the context budget of every session that doesn't need it.

Skills on the Messages API

Skills are usable directly on the Messages API (beta), not just through Claude Code or the Agent SDK. Using them this way requires two beta headers together: code-execution-2025-08-25 and skills-2025-10-02. Invoked this way, a Skill executes *inside that code-execution container* rather than anywhere in your own application's runtime -- a real distinction, since it changes what the Skill can safely assume about available tools and filesystem access. It's running inside Anthropic's sandbox, not your process.

The Sharp, Testable Asymmetry: Subagents Inherit Permissions, Not Skills

Here is the detail worth calling out on its own, because it cuts against intuition: subagents do not automatically inherit Skills from a parent session. Each Subagent starts with a clean context -- if a Subagent needs a Skill to do its job, that Skill must be explicitly listed in the Subagent's own configuration; it is never assumed to carry over from the parent just because the parent had it loaded.

But subagents do inherit the parent session's permission and tool-access context -- permission scope is not reset at delegation. So the same delegation boundary treats two adjacent things completely differently: Skills reset to a clean slate, permissions carry forward unchanged. A Subagent wired up to do a task that depends on a specific Skill will silently lack it unless you register that Skill against the Subagent directly -- while that same Subagent inherits whatever permission scope the parent already had, for better or worse.

Common exam traps

• Assuming a Subagent automatically has access to whatever Skills its parent session had loaded. It does not -- Skills must be explicitly registered per Subagent.
• Assuming the inheritance rule is symmetric (either everything carries over, or nothing does). It isn't: permissions carry over at delegation, Skills do not. This asymmetry is exactly what gets tested.
• Treating a Skill as functionally the same as an always-loaded CLAUDE.md-style file. A Skill's whole design point is loading on demand when the description matches, not being resident in every turn.
• Forgetting that Messages API Skills usage requires *both* beta headers together (code-execution-2025-08-25 and skills-2025-10-02), and that the Skill then executes inside the code-execution container rather than your own application's environment.