Why Salesforce Developers and Admins Need Agent Skills

Every time an admin or developer opens a fresh conversation with an AI coding assistant to help with Salesforce work, the same context has to get re-established: which objects are off-limits, what a deploy checklist actually requires, how the org names its custom fields, which report to run before touching a permission set. Skip re-explaining any of it, and the assistant doesn't know something's missing. It just does the task without the constraint, and nobody notices until the constraint mattered.

A Skill is the fix for exactly this: a packaged set of instructions an AI assistant loads automatically when a task matches what it covers, instead of relying on whoever's driving the session to re-explain the same rules every time. A checklist that lives in someone's memory only works when that person remembers to say it out loud, to every AI session, every time. A checklist that lives in a file gets applied whether anyone remembers to mention it or not. That's the actual argument for a Skill: not convenience, consistency.

The concept isn't specific to one vendor. Several AI coding tools now support some version of a persistent, project-level instructions file that works this way. Claude's implementation, called Agent Skills, is the one this piece works through in detail.

What an Agent Skill actually is

In Claude's implementation, a Skill is a folder containing a SKILL.md file (the instructions, in plain Markdown) and, optionally, scripts or reference files it needs. Its name and a short description stay in Claude's context by default, cheap to keep around. The full instructions only load when the task at hand actually matches what the Skill covers. That's the mechanism: cheap to have many Skills sitting available, and each one only costs context when it's relevant.

That matching is Claude's own judgment, not a guarantee. A Skill only fires when the task's phrasing lines up with how its description is written, so a vague or generic description can miss a task that should have triggered it. Write the description around the actual words someone would use to ask for the thing, and confirm a Skill actually triggers before relying on it for anything that matters.

Skills are currently in beta on the Claude API, and available today in Claude Code, where a project can keep a library of them and Claude decides which ones apply as work comes up. A minimal one is just a short file:

---

name: deploy-checklist

description: Use before marking any Salesforce change ready to promote to production.

---

Before calling a change ready to promote:

1. Run the validation report for every object the change touches.

2. Confirm it was tested in the QA sandbox, not only in Dev.

3. Check whether any changed field is referenced by a Flow outside this project.

That's the whole shape: a name, a description Claude matches against the task at hand, and instructions underneath. Anthropic's own Agent Skills documentation covers the full format, including how to add scripts or reference files alongside the instructions. In Claude Code specifically, a Skill is just a folder under .claude/skills/ in the project (or ~/.claude/skills/ for one that follows a developer across projects). Claude discovers and uses it automatically, with no separate install step.

This is a different mechanism from a project's CLAUDE.md file, which Claude Code also supports and which many teams already use for the same problem. CLAUDE.md loads in full at the start of every session, whether or not the current task needs it. A Skill's name and description stay resident the same way, but its actual instructions only load when a task matches, so a team can keep a dozen Skills for a dozen different situations without paying the context cost of all of them on every request the way a growing CLAUDE.md eventually does. Use CLAUDE.md for what's true on every task; use a Skill for what's only true on some of them.

Skills are not the same thing as tools or MCP

It's easy to conflate the two. Tools and MCP connections (MCP is the protocol that lets an AI client like Claude reach out to a system like Salesforce in the first place; Salesforce's own Hosted MCP Servers is one example) are about capability: what Claude is able to do, like querying a Salesforce object or calling an Apex action. A Skill doesn't grant any new capability. It's the judgment layer on top: what to check before making that call, what the org's own conventions are, what "done" looks like for a specific kind of task.

Put together, an MCP connection gives Claude the ability to touch a Salesforce org at all; a Skill is what tells it how that particular org wants the work done. Neither one substitutes for the other. An AI client that can technically reach an org's data with no packaged sense of that org's own rules is exactly the gap this piece is arguing needs closing.

Not the same thing as an Agentforce Topic or Action, either

One clarification for anyone searching inside Salesforce's own documentation: Agentforce's building blocks are Topics (renamed Subagents as of a Salesforce terminology update in April 2026) and Actions, not Skills. They're a different vendor's concept for a different layer, configuring what a Salesforce-native agent can do inside an org. Claude's Agent Skills are about how an external AI client like Claude approaches a task, including one working against a Salesforce org through MCP. The two aren't interchangeable, and a search for "Agentforce Skills" won't land on this.

Where the need actually shows up in Salesforce work

The concrete version: a Skill can package the checklist an org already has, but doesn't want to re-type every time. A few examples of the kind of thing that fits:

• A deploy checklist: which validations to run, which sandbox to test in first, what "safe to promote" means for this specific org.

• Field and object naming conventions, so generated Apex or Flow logic matches what the team already has instead of introducing a second pattern.

• A standing rule about what an AI agent should never touch directly, such as production data outside a sandbox, without a human explicitly signing off first.

None of that requires new Salesforce configuration. It's a text file that travels with the project, checked into source control like anything else the team maintains. Without it, each of those three things depends on whoever's driving the AI session that day remembering to mention them, which is precisely the failure mode a packaged checklist exists to remove.

Know where a Skill comes from

A Skill's instructions get real reach once they're paired with a tool connection, and that's why where a Skill comes from matters. Anthropic's own guidance is direct about this: use Skills only from sources you trust, because a malicious one can direct Claude to invoke tools or run code in ways that don't match what the Skill claims to do, and a Skill from an unknown source needs a thorough audit before use, not just a skim. Paired with an AI session that also has MCP access into a Salesforce org, an untrusted or compromised Skill becomes an instruction set with real reach into the org, and Claude will act on it.

That's a different risk than an over-permissioned integration user, and the difference is worth being precise about. An MCP connection with broad object access is dangerous because of what it's allowed to touch. A malicious Skill is dangerous because of what it can talk a permitted session into doing with that same access: quietly widening a query's scope, chaining two individually-authorized calls into a destructive sequence, or normalizing a step an admin would have stopped to think about if a human had typed it instead. Vetting a Skill's instructions and auditing a session's actual permissions are both real checks, and neither substitutes for the other. Permission Sets Reporting Helper and Fields Access Explorer cover the permissions side, showing exactly what a permission set or profile grants; reading a Skill's SKILL.md before trusting it covers the other. Do both before pairing a broadly-capable AI session with an org that has real data in it.

For the MCP side of this same picture, see What Admins Should Know About Salesforce MCP. For the broader access-governance work that AI-agent adoption raises, see the Agentforce readiness checklist and the rest of that series. Or start at the Power User Toolkit overview.

A Skill costs nothing to have sitting unused, and costs everything to skip when it actually mattered. Write down what the team already knows once, instead of relying on whoever's driving the session that day to remember to say it.

Get Power User Toolkit on Salesforce AppExchange →