Home › Agent Skills › Excel skill (skill_id: xlsx)
Agent Skills · Build

Excel skill (skill_id: xlsx)

Creates and edits .xlsx workbooks — multi-sheet, formulas, charts — rather than dumping a CSV in the response.

In one line

The xlsx skill writes real workbooks with live formulas, but it does it inside a sandbox with no internet, so anything the pre-installed libraries cannot do, it cannot do.

Why you'd careThe problem it solves

You asked for "a spreadsheet with a summary tab and a chart" and got a markdown table. Or worse, you got a CSV — which has no tabs, no formulas, no charts, and no formatting, and which the finance person you sent it to has to rebuild by hand. The specific thing that makes a workbook a workbook is structure that plain text cannot carry: multiple sheets, cells that recalculate, a chart object anchored to a range, number formats that survive being opened in Excel. The xlsx skill exists to close exactly that gap. What surprises people is the second half of the story: the workbook is built by Python running in a locked-down container, and the container's constraints become your constraints. Knowing them up front is the difference between a clean first run and a confusing failure.

ConceptWhat it is

The Excel skill is an Anthropic-authored skill directory for producing and editing .xlsx workbooks — multiple sheets, formulas, cell formatting, charts — and for reading a workbook you upload. Like its siblings, it is referenced by ID rather than installed: {"type": "anthropic", "skill_id": "xlsx"} in container.skills, alongside the code-execution tool.

Where it sits relative to its neighbours is worth being precise about. Against the pptx and docx skills, it is the same mechanism pointed at a different file format — nothing about the loading, execution or retrieval path differs. Against a code-execution request with no skill declared, the difference is instructional: Claude can already drive openpyxl unaided, but the skill supplies conventions for things models get wrong unprompted — where to put a summary sheet, when to write a formula string rather than a computed value, how to anchor a chart.

The moving parts: the skill directory on the container filesystem; the container's pre-installed Python environment, which is fixed; the workbook file itself, which lives on the container disk and never enters the context window; and the Files API, which is the only exit path. The context window sees the prompt, the skill instructions once loaded, and whatever the scripts print — not the spreadsheet.

How it worksThe mechanics

Same progressive-disclosure ladder as the other document skills: metadata always loaded, SKILL.md read on trigger, bundled scripts executed via bash with only stdout entering context. The interesting mechanics here are the container's, because they set the ceiling on what the skill can produce.

Anthropic's code-execution documentation describes the container as an isolated instance with roughly 1 CPU, 5 GiB of RAM and 5 GiB of disk, running Python 3.11, and states plainly that it has no internet access. The pre-installed set relevant to workbooks is: openpyxl and xlsxwriter for the file format, pandas and numpy for the data, matplotlib for chart images, plus scipy, statsmodels and scikit-learn if the analysis needs them.

Here the sources agree, and it sets the ceiling. The row this page is built from records that on the API surface the sandbox has no network access and no runtime package installation, and Anthropic's own code-execution page says the same: “The container has no internet access, so Claude can't download or install additional packages at runtime: only the pre-installed libraries are available.” Treat the pre-installed list as the hard boundary before you design around a dependency.

Containers persist and can be reused: read response.container.id and pass it back on the next request to keep the files it holds. Reuse composes with container.skills in the same request — the skills guide's multi-turn example passes {"id": ..., "skills": [...]} as one object.

At a glanceSee it

Excel skill (skill_id: xlsx) diagram

The xlsx path from uploaded data to a downloadable workbook, bounded by a sandbox with no egress.

Where it runsSurfaces and availability

SurfaceStatusNotes
Claude CodeNoConfirmed — the pre-built document Skills "are not available in Claude Code". Claude Code can still write workbooks (it has Bash and your local Python), but that is your environment and your openpyxl, not Anthropic's skill. Source: Agent Skills overview → Claude Code (platform.claude.com/docs/en/agents-and-tools/agent-skills/overview).
Claude API / Messages APIYesConfirmed, generally available — the primary surface for this skill. container.skills + the code_execution tool, with no beta header. Sources: docs/en/build-with-claude/skills-guide; docs/en/build-with-claude/overview.
Managed AgentsYesConfirmed, Beta. {"type": "anthropic", "skill_id": "xlsx"} on the agent object; the session inherits it. Anthropic's docs do use xlsx as the worked example, on a "Financial Analyst" agent. Note the real cap is per session, not per agent: up to 500 skills counted across every agent in the session. Source: Managed Agents → Skills (docs/en/managed-agents/skills).
Claude Desktop / claude.aiYesConfirmed for claude.ai, which is named in the pre-built Skills list. A Skill enabled there is not thereby available to your API key — the docs are explicit that custom Skills do not sync across surfaces. Desktop-app parity is not separately stated. Source: Agent Skills overview → Available Skills and Cross-surface availability.
Claude Agent SDKNoCorrected from Unverified. In the SDK, "you create skills as files on disk. The SDK doesn't provide a programmatic API for registering them"; discovery is from ~/.claude/skills/, .claude/skills/ and plugins, with no hosted skill_id entry point. Source: code.claude.com/docs/en/agent-sdk/skills.
Claude Platform on AWSYesConfirmed, Beta. Anthropic-operated; named alongside the Claude API in both the pre-built Skills list and the platform matrix. Sources: Agent Skills overview; docs/en/build-with-claude/overview.
Amazon BedrockNoConfirmed — and confirmed for the stated reason. In the platform matrix Bedrock is absent from both the Agent Skills row and the code-execution row, so the whole mechanism is missing, not just the skill. Source: docs/en/build-with-claude/overview.
Google Vertex AINoConfirmed, same two rows: Google Cloud has no code-execution tool, therefore no container for a skill to live on. Source: docs/en/build-with-claude/overview.
Microsoft FoundryYesConfirmed, Beta, with the deployment-type condition: Agent Skills is listed under "Additional features not supported when hosted on Azure", so it needs a Hosted-on-Anthropic deployment; Hosted-on-Azure returns 400 by design. Source: docs/en/build-with-claude/claude-in-microsoft-foundry.
OpenAI / Google Agent SkillsNoNo skill under the identifier xlsx; that ID is Anthropic's. Corrected: the equivalent there is not merely a folder you write — OpenAI "maintains a set of first-party skills that can be referenced by id", and names openai-spreadsheets as its example, which is a first-party workbook skill under a different name. Google's Skill Registry likewise ships Google-managed built-in skills. Sources: developers.openai.com/api/docs/guides/tools-skills; docs.cloud.google.com/gemini-enterprise-agent-platform/build/skill-registry.

The dependency chain is what to take away, and it is now visible in one table: Anthropic's feature matrix lists Agent Skills and code execution on exactly the same three platforms, and skills require the code-execution tool. So the availability of the Excel skill really is the availability of Anthropic's sandbox, and any surface question about skills reduces to "does this platform run Anthropic's container?" If yours does not, you are writing the openpyxl yourself — which is fine, and often less work than people assume. The one caveat this table now records: on a non-Anthropic skills surface you may not be starting from zero either, since OpenAI ships a first-party spreadsheets skill of its own. Checked against primary sources 2026-07-25.

ExampleIn the real world

An analyst uploads transactions_q3.csv — 40,000 rows, one row per invoice — and asks for a workbook with a raw data sheet, a summary sheet showing revenue by region and month, and a bar chart of the top ten customers.

The request declares skill_id: "xlsx" plus the code-execution tool, and attaches the CSV as a container input. Claude loads SKILL.md once the request matches, then writes a script: pandas reads the CSV, a pivot produces the summary, openpyxl writes both sheets, and the summary cells for totals are written as =SUM(B2:B13) rather than as computed numbers — so the workbook still recalculates when the analyst edits a row. The chart is added as a native chart object anchored to the summary range, not pasted in as an image.

Stdout is a dozen lines: row counts, sheet names, the output path. The 40,000 rows never touch the context window, which is the whole point of running this in a sandbox instead of asking the model to emit the data.

The analyst downloads q3_revenue.xlsx by file ID, opens it, changes a single invoice amount on the raw sheet, and watches the summary total update. That last detail is what separates the skill's output from a CSV.

Not thisWhat it is often confused with

  • Not a CSV writera CSV has one sheet, no formulas, no formatting and no charts. If a CSV is genuinely all you need, skip the skill; the model can emit one in the response.
  • Not a data warehouse querythe container has no network. It cannot reach your database. Data gets in by being uploaded as a file, or not at all.
  • Not a calculation engine you can trust blindlyClaude wrote the pandas, and the pandas can be wrong. The skill guarantees a valid .xlsx, not a correct analysis. Check the numbers the way you would check a junior analyst's.
  • Not a tool with a schemathere is no write_sheet(name, rows) function. Claude writes Python and runs it; the sheet layout is a generative decision, not a parameter you set.
  • Not RAG over spreadsheetsthe skill produces and edits workbooks. Searching a corpus of them for an answer is a retrieval problem and a different architecture.

LimitsWhen not to reach for it

  • The output format is fixed and repeats daily.A deterministic openpyxl script in your own pipeline is cheaper, faster and testable. Use Claude to build that script once, not to rebuild the workbook every run.
  • The workbook needs live data.No egress from the sandbox means no API pulls, no database reads. Fetch on your side and upload the result.
  • You need a specific library that is not pre-installed.Runtime installs do not work in the API sandbox, so treat the pre-installed list as the hard boundary and pick a different approach if your dependency is outside it.
  • The answer is one number.Provisioning a container to deliver a single figure in a spreadsheet cell is theatre. Return the number.
  • The data is regulated and cannot leave your boundary.Uploading it to Anthropic's Files API and mounting it in Anthropic's container is a data-movement decision; make it deliberately, not as a side effect of wanting a chart.
Checked

Verified 2026-09-12. Moves on a scale of months. Re-check before you depend on it. Provider: Anthropic.

A living map of modern AI — kept current every morning