Salesforce Agent Skills: the open format that makes a coding agent build the way your org does

Point any coding agent at a Salesforce org and ask it to write a trigger, and you learn the same lesson twice a day: the model knows Apex the language, and it does not know Apex your way. It writes a trigger with logic in the trigger body instead of a handler. It queries in a loop. It skips WITH USER_MODE, invents a test with SeeAllData=true, and builds an LWC that ignores every SLDS token your design system standardized on. None of it is wrong the way a syntax error is wrong. It’s wrong the way a new contractor is wrong on day one — plausible, confident, and not how this shop does things. So you paste the conventions into the prompt. Again. And again tomorrow, in the next session, from scratch.

Agent Skills are the fix for exactly that, and in the Summer ‘26 wave Salesforce did something worth paying attention to: instead of inventing a proprietary way to feed conventions to its own coding agent, it open-sourced a library of Salesforce development skills built on the open Agent Skills format — the same SKILL.md format Claude Code, Cursor, Codex, and other coding agents already read. This post is what a skill actually is under the hood, how the format keeps a hundred skills from bloating your context window, how you install and use the Salesforce library, and — the part everyone gets muddled — the difference between an Agent Skill, an MCP server, and an Agentforce Action, which live at three completely different layers.

What a skill actually is: a folder with a SKILL.md

Strip away the branding and an Agent Skill is almost aggressively simple: it’s a directory whose only required file is SKILL.md — a Markdown file with a YAML frontmatter block on top and instructions below. That’s it. Optionally, the folder carries three sibling directories the instructions can reach for:

• scripts/ — executable code the skill can run (Python, Bash, JavaScript)
• references/ — deeper reference docs loaded only when needed
• assets/ — templates, schemas, lookup data

The frontmatter is where the intelligence lives. Two fields are mandatory — name and description — and the description is doing far more work than its name suggests. In the Salesforce library it’s written as an explicit dispatch string: not just “what this skill does” but when to use it and when not to. Here’s the shape, drawn from the actual agentforce-generate skill in the library:

---
name: agentforce-generate
description: >
  Build, modify, optimize, debug, and deploy Agentforce agents.
  TRIGGER when: the user asks to create or change an agent, topic, or action.
  DO NOT TRIGGER when: the user wants a plain Apex class or an LWC with no agent involved.
metadata:
  version: "0.11"
  minApiVersion: "66.0"
  relatedSkills:
    - agentforce-observe
    - platform-apex-generate
  cliTools:
    - tool: ["sf"]
      semver: ">=2.139.6"
    - tool: ["python3"]
      semver: ">=3.10.0"
---

# Instructions the coding agent follows once this skill triggers…

If that TRIGGER when / DO NOT TRIGGER when pattern looks familiar, it should: it’s the same discipline that decides whether an Agentforce agent picks the right topic. A skill is selected by its description the way an agent routes to a subagent by its classification description — the quality of that one string is most of what decides whether the right skill fires at the right moment. Write a vague description and the agent either ignores a skill it should have used or fires one it shouldn’t. The metadata block (version, minimum API version, related skills, and the CLI tools the skill shells out to, pinned by semver) is a Salesforce convention layered on top of the open spec — the spec itself only insists on name and description.

Progressive disclosure: why a hundred skills cost almost nothing idle

The obvious objection to “install a big library of skills” is context bloat. If every skill’s full instructions loaded into the model at all times, a hundred skills would drown the context window and you’d pay for tokens you never use. The format is built specifically to avoid that, through progressive disclosure in three tiers:

1. At startup, the agent loads only each skill’s name and description — on the order of a hundred tokens per skill. That’s enough for the agent to know what exists and when each one applies, and nothing more.
2. On trigger, when a task matches a skill’s description, the agent loads that skill’s full SKILL.md body — kept deliberately small, on the order of a few thousand tokens — and follows it.
3. On demand, files under scripts/, references/, and assets/ are pulled in only if the instructions actually call for them.

The effect is that a large library sits nearly free in the background — a table of contents the agent consults — and only the one skill you’re actually using pays its full token cost. This is the mechanical reason the approach scales to the roughly one hundred skills the Salesforce library ships (a count that will drift — treat it as “a lot,” not a fixed number), spanning far more than Apex. A representative slice of what’s in there:

• Platform / metadata: platform-apex-generate, platform-apex-test-generate, platform-custom-object-generate, platform-permission-set-generate, platform-metadata-deploy
• Agentforce: agentforce-generate, agentforce-test, agentforce-observe
• Flow & automation: automation-flow-generate
• Data 360: data360-query, data360-harmonize, data360-segment, and data360-code-extension-generate — which writes exactly the kind of Data 360 Code Extension Python a coding agent would otherwise get subtly wrong
• LWC & design system: experience-lwc-generate, design-systems-slds-apply, design-systems-slds-validate
• DX & DevOps: dx-code-analyzer-run, dx-org-manage, plus OmniStudio, Commerce, Mobile, and Integration families

Installing and using the library

The library is published in Salesforce’s forcedotcom GitHub organization and installed with the open-source skills CLI. The command that every version of the README prints today is:

npx skills add forcedotcom/sf-skills

Two honest caveats before you run it. First, this library is moving fast — it’s been reorganized and, by some signals, renamed as it consolidates around Agentforce Vibes, so confirm the current repository path from Salesforce’s own docs rather than trusting a link (including this one) to still be canonical. Second, the skills CLI is a community tool (from Vercel Labs), not a Salesforce product, and its install-path handling has had rough edges — skills can land in a directory your coding agent doesn’t actually scan. After installing, verify the skills appear where your specific tool looks for them (.claude/skills/ for Claude Code, for instance) before assuming they’re active.

Where this gets genuinely nice is portability. If you use Agentforce Vibes, Salesforce’s own agentic coding assistant, the skills come pre-packaged and auto-updated — nothing to install. But because the format is the open Agent Skills spec and not a Vibes-only thing, the same skill also works in Claude Code, Cursor, Codex, and OpenCode. You define your org’s conventions once and they follow you across whichever coding agent you or your teammates prefer. That’s the whole argument for Salesforce adopting an open format instead of a captive one: your investment in encoding “how we build” isn’t locked to a single vendor’s IDE.

The line everyone blurs: Skill vs. MCP vs. Action

Here’s the confusion that sends teams building in the wrong place, because Salesforce ships all three and the names bleed together. An Agent Skill, an MCP server, and an Agentforce Action are three different things at three different layers, and getting them straight is most of understanding this space.

• An Agent Skill is author-time instruction. It tells a coding agent how to build something the way your org wants — the patterns, the conventions, the steps. It’s knowledge, loaded into the model’s context. It doesn’t, by itself, touch your org.
• An MCP server is the execution transport. When the coding agent actually needs to do something against your org — retrieve metadata, run a query, deploy — it goes through Model Context Protocol tools. The Salesforce DX MCP Server is what lets a coding agent drive your org; a runtime agent’s MCP connections are the same idea for a deployed agent. Skills say what and how; MCP tools execute. They’re complementary — a good skill’s instructions often culminate in calling an MCP tool.
• An Agentforce Action (inside a Topic) is a runtime building block of a deployed agent. It’s what a live agent serving your customers invokes mid-conversation — a Flow, an Apex method, a prompt template. It has nothing to do with how the agent was coded; it’s part of what the agent does in production. This is the layer covered in custom Apex actions for Agentforce.

The one-sentence version: Agent Skills make your coding agent build better; MCP lets it reach your org; Actions and Topics are what the finished, deployed agent runs. And none of these is AgentExchange, which is the marketplace where you buy prebuilt runtime agent actions and integrations — a different economy entirely from a free, open-source library of coding conventions. If you’ve been treating “skills,” “MCP,” “actions,” and “AgentExchange” as loose synonyms for “the AI extensibility stuff,” this is the map that unblurs them.

What this doesn’t fix

Two things to keep honest before you wire your team’s workflow around it.

Skills raise the floor; they don’t remove the review. A skill makes generated Apex far more likely to follow your trigger framework and your test conventions — that’s real, and it’s worth a lot. But independent hands-on reviews of Salesforce’s coding agent land on the same verdict every senior engineer already suspects: it gets you roughly 80% of the way in seconds, and 80% is not production-ready. The generated LWC still needs a human to check the accessibility, the edge cases, the governor-limit behavior under bulk. A skill is a very good junior who’s read your style guide, not a senior who’s owned the codebase for three years. Treat its output as a strong first draft, run it through the same Apex security and quality bar you’d apply to any commit, and review it.

The library is fast-moving, not a stable API. Salesforce’s own README says it plainly: skills may be renamed, restructured, or removed between releases, and they don’t carry the stability guarantees a GA platform API does. Agentforce Vibes 2.0, where much of this is centered, is a Developer Preview at the time of writing. So don’t hardcode skill names into CI, don’t build irreversible automation on a specific skill’s existence, and expect the shape of the library to shift release to release. This is early, genuinely useful infrastructure — treat it as early.

The takeaway

Agent Skills solve a small, constant, real problem: a coding agent that knows the language but not your house rules, and a developer re-teaching it those rules every session. Encoding them once, in an open SKILL.md format that any coding agent can read, turns “re-paste our conventions” into “the conventions are just there” — and progressive disclosure means a whole library of them costs almost nothing until the moment one is needed.

The strategic point is the openness. Salesforce could have built a proprietary skills mechanism welded to Agentforce Vibes; instead it adopted the same format the rest of the coding-agent ecosystem uses, which means the work you put into capturing how your team builds Salesforce isn’t a bet on one IDE. Start by installing the Salesforce library and watching which skills fire on your real tasks. Then, where your org’s conventions diverge from the defaults — your naming, your trigger framework, your particular SLDS usage — write your own skills in the same format, because the highest-value skills are the ones that encode your standards, not the generic ones. Keep the review discipline, keep an eye on the churn, and you’ve got a coding agent that finally builds the way your org actually does. Making that agent’s output trustworthy enough to ship — reviewed, governed, and matched to your standards — is exactly the engineering bar our Agentforce and platform practice holds every build to.

Understanding the basics

What is an Agent Skill in the Salesforce context?

An Agent Skill is a self-contained folder — a required SKILL.md file (YAML frontmatter plus Markdown instructions), optionally with scripts/, references/, and assets/ — that teaches a coding agent how to do a specific task the way you want it done. Salesforce open-sourced a library of these for Salesforce development (Apex, LWC, Flow, Data 360, metadata, and more), built on the open Agent Skills format so the same skill works in Agentforce Vibes, Claude Code, Cursor, Codex, and other tools. The description field is written as a trigger rule that tells the agent when to use the skill, and progressive disclosure means only the skills you actually use load their full instructions.

How is an Agent Skill different from an MCP server or an Agentforce Action?

They live at three layers. An Agent Skill is author-time knowledge — it tells a coding agent how to build something correctly, but doesn’t touch your org itself. An MCP server is the execution transport the coding agent uses to actually reach your org (retrieve metadata, run a query, deploy). An Agentforce Action is a runtime building block of a deployed agent — what a live agent invokes mid-conversation to do something for a customer. Skills improve how code is generated; MCP lets the agent reach the platform; Actions are what the finished agent runs. AgentExchange, separately, is the marketplace for buying prebuilt runtime actions — not the same thing as an open skills library.

Do I still need to review code a skilled coding agent generates?

Yes — fully. Skills meaningfully raise the quality floor: generated code is far more likely to follow your conventions, frameworks, and design-system tokens. But independent reviews consistently find that a coding agent gets you roughly 80% of the way and that the remaining 20% — accessibility, edge cases, bulk/governor-limit behavior, security enforcement — still needs a human. Treat skilled output as a strong first draft, run it through the same security and quality review you’d apply to any commit, and never ship it unread. And because the skills library is fast-moving and not GA-stable, don’t hardcode skill names into automation.

---

Want your coding agent generating Apex, LWC, and Flow that actually matches your org’s standards — and reviewed to a bar you can ship? Talk to us. Encoding how a team builds on Salesforce, and holding AI-generated code to the same engineering bar as everything else, is exactly the work we do.