PowerPoint skill (skill_id: pptx)

Why you'd careThe problem it solves

You asked Claude for a deck and got a markdown outline: bold headings, nested bullets, a line that says [Slide 3]. The person you were sending it to wanted a file they could open in PowerPoint or Google Slides and edit. The gap is not model capability — Claude reasons about slide structure fine — it is that nothing in an ordinary Messages API response can be a binary file. Producing one means code has to run somewhere: a library like python-pptx, a template to start from, a filesystem to write to. The pptx skill is Anthropic's packaged answer: the instructions and the scripts ship together and execute inside the sandbox. The catch is that the sandbox is the only place the skill exists, which rules out several surfaces you may have assumed were covered.

ConceptWhat it is

The PowerPoint skill is an Anthropic-authored skill directory that Claude loads on the code-execution container: a SKILL.md instruction file plus bundled scripts and templates for creating, editing, and analysing .pptx files. You do not install it or write it. You name it on the request as {"type": "anthropic", "skill_id": "pptx"} and Anthropic mounts it.

Two boundaries matter. First, a skill is not a tool. A tool is a JSON schema the model fills in and your harness executes; a skill is instructional context plus files, and the only tool actually running here is code_execution. Claude reads the skill, then writes and runs Python. Second, a hosted skill is not a custom skill. Hosted skills are Anthropic's, referenced by a short string ID. Custom skills are yours, registered through the Skills API or dropped into a folder, and the two are selected by different mechanisms.

The moving parts are worth naming, because each one is a place things break: the skill directory on the container filesystem; the progressive-disclosure ladder that decides how much of it enters the context window; the code-execution container that owns the working filesystem; and the Files API, which is the only way the finished deck reaches you. Remove any one and you get prose about slides instead of slides.

How it worksThe mechanics

Progressive disclosure is the load-bearing mechanic. Only the skill's YAML name and description sit in context by default — roughly 100 tokens per skill, per the level table in Anthropic's docs. When your request matches that description, Claude reads the full SKILL.md. Bundled scripts are never read into context at all: Claude runs them with bash and only stdout comes back. That is why declaring several document skills at once costs almost nothing.

The Messages API call has two required parts beyond an ordinary request — the skill in container and the code_execution tool — and omitting either one is the usual failure:

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    container={"skills": [
        {"type": "anthropic", "skill_id": "pptx", "version": "latest"}
    ]},
    tools=[{"type": "code_execution_20260521", "name": "code_execution"}],
    messages=[{"role": "user", "content": "Create a 3-slide deck on Q3 churn."}],
)

Note that there is no betas argument. All three code execution tool versions are generally available and Skills left beta on 2026-08-19, so no beta header is required. Older examples still send code-execution-2025-08-25 and skills-2025-10-02; both remain valid opt-ins, but a request that keeps sending skills-2025-10-02 keeps getting the beta response shapes. The tool type version (code_execution_20260521 at the time of writing) and that legacy header date are two different version strings on two different clocks. They look alike and they do not move together; copying one into the other's slot is a 400.

Claude then writes Python against python-pptx, runs it in the container, and the deck lands on the container filesystem. The response carries a file ID for it. Retrieve the bytes with the Files API — GET /v1/files/{id}/content, or client.files.download(file_id) — which is out of beta and needs no beta header. If you skip that step you have a file ID and no file.

At a glanceSee it

How a request naming skill_id pptx becomes a downloadable deck, and where it dead-ends.

Where it runsSurfaces and availability

The pattern holds and is now checkable in one place: in Anthropic's platform feature matrix the Agent Skills row and the code-execution row cover exactly the same three platforms — Claude API, Claude Platform on AWS, Microsoft Foundry. Hosted document skills follow the sandbox, not the model. Every surface that runs Anthropic's container has them; every surface that only proxies inference does not. If your deployment is on Bedrock or Vertex for compliance reasons, deck generation is something you build yourself, and that deck-shaped hole is the strongest single argument for keeping a first-party API path open alongside. Checked against primary sources 2026-07-25.

ExampleIn the real world

A revenue-ops team wants a monthly churn readout the CS lead can edit before the QBR. The request declares skill_id: "pptx", the code-execution tool, and uploads churn_2026_07.csv as a container input. The prompt is one paragraph: six slides, title slide with the month, a cohort table, a chart of net revenue retention by segment, two slides of narrative, and a closing slide listing the three accounts most at risk.

Claude sees only the skill's description until the word "slides" matches it, then reads SKILL.md. It writes a Python file that loads the CSV with pandas, builds the chart with matplotlib, and assembles the deck with python-pptx following the skill's layout guidance. It runs the script; the first attempt overflows a text box, the traceback comes back as stdout, and it edits and re-runs. Roughly 40 lines of stdout enter the context window; the several hundred lines of generated Python do not.

What the user gets back is a short message — "six slides, chart on slide 3" — and a file ID. Their application calls the Files API, writes churn-july.pptx to disk, and the CS lead opens it in PowerPoint and rewrites two bullets. Nothing about the deck is a screenshot or a rendering; the shapes are editable objects.

Not thisWhat it is often confused with

• Not a toolthere is no create_slide function with an input schema. The skill is instructions plus files; the only tool in the request is code_execution, and Claude writes the slide code itself.
• Not a template engineyou are not filling placeholders in a fixed deck. Claude decides the structure. If you need brand-exact output, supply your own template file and say so in the prompt; the skill will not guess your house style.
• Not a rendering serviceit produces an editable .pptx, not a PNG or a PDF of slides. If you want a picture of a deck you are asking the wrong component.
• Not an MCP servernothing connects out. The skill is files mounted on Anthropic's container, not a process you host and Claude dials into over a protocol.
• Not available by default in Claude CodeClaude Code loads skills from your filesystem. A hosted skill_id is a Messages API concept and has no CLI equivalent; the CLI's bundled skills are a different, separately curated set.

LimitsWhen not to reach for it

• The user wants text, not a file.If the answer will be read in a chat window, the skill adds container startup and a Files API round trip for nothing. Ask for markdown.
• You need pixel-exact brand compliance.Generative layout will drift from your design system. Reach for a deterministic template fill in your own code, and use Claude to write the content that goes into it.
• You are on Bedrock or Vertex.There is no fallback flag — skills are absent from those surfaces. Generate the content on your current platform and run python-pptx yourself.
• The deck is one slide of a number.The overhead is real. Below roughly three slides, a hand-rolled python-pptx call in your own service is faster and cheaper than provisioning a container.
• You need the deck inside a strict latency budget.Container start plus a write-run-fix loop is seconds to tens of seconds. Do it asynchronously and hand the user a file when it lands.

RelatedGo deeper