sf-skills: Salesforce's patterns packaged for coding agents

What an agent skill actually is, according to the README

The README defines the format before it describes the content. Agent Skills package executable workflows, scripts and reference material into self-contained directories, and this repository follows the open Agent Skills specification at agentskills.io. The claim is that it works with OpenCode, Claude Code, Codex, Cursor and other tools that support skills, rather than only with Salesforce's own product.

Each skill is a folder with one required file and three optional ones. `SKILL.md` is required and holds instructions plus YAML front matter. `scripts/` is optional and holds executable scripts in Python, Bash or JavaScript. `references/` is optional extra documentation. `assets/` is optional and holds templates, schemas and lookup data.

That structure is the interesting part, because it explains how a coding agent gets better at a platform. A skill is not a paragraph of context. It is a working directory with instructions you can follow, scripts you can run, and data files you can read, which is a much stronger input than a paragraph of prose about how metadata types work.

The coverage list reads like a Salesforce navigation bar

The README describes the scope as skills for Agentforce agents, Lightning apps, Flow, Apex, SOQL, Lightning Web Components, UI bundles, objects and fields, permission sets and related areas. That is a useful summary of the Salesforce platform as a developer actually meets it, ordered from declarative to imperative: permission sets and metadata first, then declarative tools, then code.

The tree shows the same shape in directory names. `skills/platform-apex-generate/` and `skills/platform-custom-object-generate/` and `skills/automation-flow-generate/` are visible at the top of the structure diagram, with the rest following behind an ellipsis. The naming convention is a platform prefix, a category, and a verb, which tells you these are generation workflows rather than general explanations. That is a deliberate choice: a skill named for generating an Apex class is invoked when you want one, not when you merely want to discuss Apex.

The repository is published as `@salesforce/afv-skills`, described in `package.json` as Salesforce skills for Agentforce Vibes, with `skills/` as the only directory included in the published package. Samples are synced into the repo rather than published, which keeps the npm artifact small.

Two install paths, one of them automatic

The usage table draws a clear line. For Agentforce Vibes, skills are auto-installed and auto-updated. For everything else, including OpenCode, Claude Code, Codex and Cursor, you run one command:

npx skills add forcedotcom/sf-skills

The difference matters for anyone building a repeatable workflow. Auto-install means your Salesforce environment is not a thing you pin, it is a thing that tracks. The npx path means the version lives in your own repository and your own dependency list, which is what you want if your agent setup is reproducible or if you run it in CI.

There is also a `.nvmrc` at the repository root and `sfdx-project.json` alongside `package.json` and `package-lock.json`, which tells you the sync tooling for samples expects an SFDX project context. The repository language on the metadata side is Python, which is consistent with skills that ship executable scripts rather than only markdown.

Sample apps kept in sync by a nightly job

The `samples/` directory is a live mirror of npm packages rather than hand-written examples. The README names `samples/ui-bundle-template-app-react-sample-b2e/` as tracking the npm package `@salesforce/ui-bundle-template-app-react-sample-b2e`, updated nightly and on manual trigger via GitHub Actions. The `examples` list in the repository metadata shows six entries, including native-mobile-rental-tenant-app and separate b2e and b2x variants plus experimental webapp templates.

To run the same sync locally from the repository root:

npm install
npm run sync-react-b2e-sample

The action runs the same commands and opens a pull request when the package version changes, which is a much better arrangement than committing vendor code by hand. The devDependencies in `package.json` pin four of the tracked templates at specific versions, two at `^12.4.4` and two experimental ones at `^1.117.1`, so the mirror has a declared expected state.

What this buys a reader is working reference code. A UI bundle sample is one of those things that is easy to describe and awkward to get right, so having the actual template in the repository, refreshed on a schedule, is worth more than another paragraph of documentation.

Weekly releases, and a license that changed under it

The release cadence is fast and the notes are short. The newest tag is 1.56.0, published on 2026-09-18, and its body reads as a single line: release 9 new skills and update 37 skills. The tag before it, 1.55.0, came out on 2026-09-15. Three days apart, with a minor version bump each time, is a release train rather than a curated cadence.

The README is direct about what that means. It warns to expect frequent changes, says skills may be renamed, restructured or removed between releases, and says explicitly that they do not follow the same stability guarantees as GA platform APIs. It also warns that if you have forked or synced the repository, upstream changes may conflict with local modifications, and states that this repository is always the source of truth.

One detail deserves attention if you plan to redistribute anything. The repository metadata reports the license as Apache-2.0 and the tree has `LICENSE.txt`, but the `package.json` in the root declares `CC-BY-NC-4.0`, a non-commercial Creative Commons license. That is not a contradiction you can resolve from the README, so if you are building the skills into a commercial product, ask Salesforce which terms apply.

Who this is for, and what it will not tell you

The honest audience is someone whose agent is about to write Salesforce code without a Salesforce developer reviewing every line. In that setting the value is real: an agent that knows the current conventions for a Lightning Web Component, or the correct way to declare a custom object, or how to write a permission set, produces code that matches what the platform expects rather than what a generic model remembers from training.

The limit is the same one that applies to any pattern catalog. A skill can tell you the shape of the right thing, not whether your org has a validation rule that blocks it, whether a managed package already owns that API name, or whether your sandbox has the feature enabled. The repository also carries `CODEOWNERS`, `CONTRIBUTING.md`, `SECURITY.md` and a `CHANGELOG.md`, so governance is present, and there is a `plugins/` directory and a `.claude-plugin/` entry for tool-specific packaging.

For a Salesforce developer, the most valuable thing here may be reading the skills as documentation. They are a curated, frequently refreshed description of how the vendor expects work on its platform to be done, and they are updated weekly by the people who maintain it.

Editorial conclusion

sf-skills works because it stops at describing Salesforce in prose. The skills are directories with a required SKILL.md, optional scripts, references and assets, so an agent working on an Apex trigger or an LWC bundle gets the same instructions a Salesforce developer would follow. The warning at the top of the README is the part to plan around: skills may be renamed, restructured or removed without the stability guarantees of a GA platform API, so pin the package version if you depend on it. Install it with a single npx command, read one skill directory end to end, and you will know whether your agent is getting real platform knowledge or generic advice.

Frequently asked questions

Official sources

1. forcedotcom/sf-skills on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases