Salesforce Shipped 41 Claude Skills. It Is Not a Winter '27 Feature, and That Matters.

A Post Crossed My Feed Claiming Winter '27 Ships a Claude Plugin. Half of That Is True.

The post said Salesforce is launching a toolkit for Claude with 41 skills as part of the Winter '27 release. It got a lot of engagement, and I understand why. It arrived the same week as the release notes, it names a real number, and the diagram looked official.

The number is right. The release framing is not, and the gap between those two things is more interesting than the announcement would have been.

So rather than argue with a screenshot, I cloned the repository and read it. What follows comes from the source at commit ba78d387, not from anyone's summary of it.

What It Actually Is, and Where It Actually Comes From

The plugin is called salesforce-development. It lives in the repository forcedotcom/sf-skills, it is version 1.11.0, it is Apache-2.0 licensed, and it contains exactly 41 skills across 975 files and about 12 megabytes.

Here is the part that undoes the release story. That repository was created on 7 November 2025. Salesforce announced the skills library on its developer blog on 9 June 2026. The most recent push before I looked was 18 August 2026. The wider repository now holds 138 skills, of which the plugin bundles 41 as a foundation layer. None of this appears in the Winter '27 release notes, because none of it is a Winter '27 feature.

You install it in Claude Code with two commands: plugin marketplace add forcedotcom/sf-skills, then plugin install salesforce-development@salesforce. For other tools that support the open skills format, it is npx skills add forcedotcom/sf-skills. Notice what is absent from both: an org, a release, a sandbox, a maintenance window.

My best guess at how the confusion started is boring. Somebody installed it during release-notes week and assumed the two events were connected. That is an easy mistake, and it is worth correcting precisely because the truth is the better story.

Salesforce's AI Tooling Has Left the Release Train

For as long as I have worked on this platform, one clock governed everything. Three releases a year. Release Updates you can defer until you cannot. Sandbox preview windows. A maintenance calendar you check before you promise anyone a date. I wrote about the Winter '27 version of that calendar yesterday.

There is now a second clock, and it runs at a completely different speed.

The repository README says so directly. I am quoting it in full because it is the most important sentence in this post: "Expect frequent changes. The Salesforce skills library is evolving rapidly as we refine patterns and incorporate feedback. Skills may be renamed, restructured, or removed between releases — they do not follow the same stability guarantees as GA platform APIs."

Read that as a Salesforce professional and it should stop you. Renamed, restructured, or removed. No GA stability guarantee. That is not how anything else on this platform behaves, and it is stated openly rather than buried.

The version numbers tell the same story. The plugin is at 1.11.0 while the library it draws from is at 1.38.0. Those move independently, and neither is tied to Winter '27, Spring '27, or anything else with a season in its name.

Practically, this changes two things. You cannot put "the skills library" on a release-readiness checklist, because it does not have a readiness date. And pinning a version is now your problem, not Salesforce's, in a way it never was for the Metadata API.

The Hooks Are the Most Interesting Thing in Here

Everyone will count the skills. The skills are fine. The hook configuration is where somebody clearly thought hard.

Before any deploy command runs, a PreToolUse hook fires verify-org. Before deploy start or deploy quick specifically, a second hook runs a production check. Before any project delete, a destructive-operation gate runs. Deploy and validate also trigger an LSP precheck, backed by a bundled Apex and SOQL language server exposed over MCP, which means your Apex gets type-checked before it is allowed near an org.

Sit with that design for a second. Salesforce assumed that an AI agent with a terminal and org credentials would eventually try to deploy to production, and they built the guardrail before the incident rather than after it. I have watched enough humans do exactly that without a guardrail to appreciate the sequencing.

There is a subtler hook I like even more. On every Edit, Write, and MultiEdit, and on raw commands like apex run, project retrieve, and data query, a skills-first advisory fires. It exists to fight the model's instinct to freelance a solution instead of using the skill that already encodes the right pattern. That is a plugin author who has watched a language model confidently improvise Salesforce metadata and decided to do something structural about it.

The plugin also ships six subagents and eleven slash commands. The one worth knowing about is architecture-review: read-only by contract, restricted to Read, Bash, Glob, Grep, and Skill, and it grades a project against Salesforce Well-Architected across the Trusted, Easy, and Adaptable pillars with file and line evidence. Its own instructions say it never edits, deploys, or deletes. A review agent that cannot change your code is a review agent you can actually run on a client project.

Where the Coverage Is Uneven

Now the part I did not expect to find.

I assumed going in that this would be a pro-code story: deep Apex support, thin support for the declarative work admins actually do. That assumption was wrong, and I want to say so plainly before I make the narrower point.

| Skill | Lines | Files |
| --- | --- | --- |
| platform-custom-field-generate | 471 | 2 |
| agentforce-generate | 462 | 94 |
| platform-apex-generate | 448 | 19 |
| automation-flow-generate | 374 | 1 |
| platform-custom-object-generate | 296 | 2 |
| platform-sharing-rules-generate | 268 | 6 |
| platform-apex-test-generate | 209 | 7 |
| platform-permission-set-generate | 188 | 1 |
| platform-validation-rule-generate | 76 | 1 |

The declarative skills hold up. Custom fields get more attention than Apex does. Flow generation runs to 374 lines. This is not a clicks-versus-code grievance.

It is one outlier. The validation rule skill is 76 lines and a single file, with no references and no assets, making it the shortest authoring skill in the plugin. And when I grepped all 41 skills for the things a validation rule actually gets wrong, I found nothing. PRIORVALUE returns zero hits across the entire plugin. CASESAFEID does not appear in the validation rule skill. Neither does any guidance on comparing a 15-character Salesforce ID to an 18-character one.

That specific omission matters more than its size suggests. Salesforce IDs come in both lengths, and comparing one form to the other does not throw an error. It silently evaluates false. A validation rule that checks OwnerId against a stored value, or compares PRIORVALUE of a lookup, will look correct in review, deploy without complaint, and quietly never fire. I keep that trap written down in my own working notes because it has cost me time before.

It is exactly the kind of rule an agent will write confidently and wrong, and this plugin currently has nothing in it that would stop that.

The Telemetry Default

Worth one paragraph, stated flatly.

Telemetry is on by default. The plugin captures session starts, skill dispatches, agent dispatches, MCP tool successes and failures, command failures, and API exceptions, buffers them, and flushes on session end. There is a telemetry slash command, and its documentation describes turning it off as "a true hard-off when disabled (nothing captured, buffered, or sent)" that honors the standard SF_DISABLE_TELEMETRY and DO_NOT_TRACK environment variables.

That is a reasonable implementation and an honest description of it. The consultant point is simply this: decide your position before you install this on a client machine, not after somebody in security asks you what it sends.

What I Am Not Saying

I read this plugin. I have not shipped a project with it.

Nothing above is a verdict on output quality. I have not put its Apex generation in front of a code reviewer, or checked whether its flow skill produces automation I would sign off on. Those are the questions that actually matter and I cannot answer them yet.

I also want to be careful about the table in the previous section. Line counts are a proxy for depth, not a measurement of it. A tight 76-line skill could in principle outperform a sprawling 448-line one. What I can say without hedging is narrower and still real: a specific, well-known, silent-failure trap in validation rules is absent from the text of all 41 skills. That is an absence you can verify with grep, and it is different from an opinion about quality.

What To Do Right Now

1. Install it against a scratch org project, not a client repository. Run the status and discovery commands first and read what it reports about your environment before you let it touch metadata. Treat the first session as reconnaissance.

2. Decide your telemetry position before it lands on a client machine. It defaults on. The hard-off is real and documented. Make that a deliberate choice you can explain, rather than a default you inherited.

3. Pin a version. The README tells you skills get renamed, restructured, and removed without GA guarantees. Record the plugin version and the library release you validated against, so that when a skill changes underneath you, you know what changed.

4. Do not let it write validation rules unreviewed. Check every generated rule for ID-length comparisons yourself, and wrap anything touching record IDs in CASESAFEID. That gap is in the plugin today, and it fails silently, which is the worst way for a rule to fail.

Wondering whether to put an AI agent anywhere near your org's deployment path? Let's talk — I will help you decide what to automate and what to keep behind a human.