Claude Skills: what they are, which to enable, and when to use them

Two different things get called "Skills," and the confusion costs people real time. This guide separates them, because you configure them in different places for different reasons.

Tools are capabilities: web search, code execution, file creation. Claude either has access to them or it doesn't.

Skills are folders of instructions, scripts and resources that Claude loads when a task calls for them. A skill teaches Claude how your organisation does something — how you format a customer report, what your brief template looks like, which steps your close process runs through. Skills went generally available with their own API in August 2026, and they work the same way across Claude.ai, Claude Code and the API.

The short version: tools are what Claude can reach. Skills are what Claude knows about your way of working.

The tools that matter most for operators

Web search. Claude searches the internet and works current information into its response, with citations. On when you need current information — pricing, recent news, live documentation.

Code execution. Claude writes and runs code in a sandbox. This is what makes data analysis real rather than estimated: paste a CSV, ask for the numbers, and Claude computes them rather than predicting them. If your work touches data at all, keep this on.

File creation. Claude produces downloadable files rather than text in a chat window. This runs in the same sandbox as code execution.

Deep Research. Claude spends extended time across multiple sources and returns a cited report. For thorough investigation, not quick questions — slower and more expensive, but a qualitatively different output.

The Skills that matter most

The document Skills. PPTX, XLSX and DOCX are Anthropic-managed Skills that run in the code execution sandbox and produce real Office files — an actual PowerPoint deck, not a text outline of one. This is the clearest example of the distinction: file creation is the tool, and the document Skills are what teach Claude to produce a properly formatted deck with it.

Your own Skills. This is where the leverage is, and where most teams have done nothing. A skill is a SKILL.md file plus whatever scripts and templates it needs. Claude reads it only when the task calls for it, so having twenty skills available costs you nothing in context until one is relevant.

Good first candidates are the things you explain to Claude repeatedly: your report format, your QBR structure, your incident write-up template, the specific way your team scopes a project. If you have found yourself pasting the same instructions three times, that is a skill.

Where each one is configured

Tools are toggled per conversation from the message bar, or set per Project so everyone working in that Project gets the same capabilities. Project-level is better for team consistency — the marketing Project always has web search on, the data Project always has code execution on.

Skills are attached to a Project, or provisioned organisation-wide by an admin on Team and Enterprise plans. Organisation-level Skills update centrally, which matters: when your report format changes, you edit one skill rather than asking forty people to update their instructions.

On Enterprise, skills and plugins go through security scanning to detect malicious content before they are made available — worth knowing if you are planning to accept skills built by people outside your team.

When to turn tools OFF

This is the part most people miss.

Turn off web search when working with internal documents. If you have loaded your product documentation into a Project and want answers from it, web search can pull in conflicting or outdated material from the internet. Disable it to keep Claude on your content.

Turn off connectors you are not using. Every active connector is a live surface Claude can reach, and several of them can now write, not just read. Scope them to what this Project actually needs.

Skills need no equivalent discipline. Because Claude loads a skill only when the task calls for it, an unused skill costs nothing. Do not prune your skill library the way you prune tools — the tradeoff is different.

The practical setup for a team admin

1. Create one Project per team function.
2. Enable the relevant tools per Project — CS gets web search and file creation, the data team gets code execution, marketing gets web search and Deep Research.
3. Write two or three Skills for the formats your organisation produces most, and provision them organisation-wide rather than per Project.
4. Document what is enabled and why, so people don't randomly toggle things.
5. Set a review point. Skills go stale the same way documentation does — if your report template changed in March and the skill still describes the February version, Claude will confidently produce the wrong format.

The goal: each person opens their Project with exactly the capabilities they need, and Claude already knows how your organisation does the work.

Further reading

• Equipping agents for the real world with Agent Skills — what Skills are and how to design them
• Introducing Skills — the announcement, with what ships built in
• Build production agents with computer use, the Skills API, and the Files API — the August 2026 GA release
• Tool use overview — the tools side, including which run on Anthropic's infrastructure
• Advanced tool use — tool search and programmatic tool calling, for when you have too many tools to fit in context