TL;DR: If you’re a Salesforce admin or developer, install SF-Skills today. It’s the set of skills Salesforce publishes and maintains for AI coding tools, and it’s one command: npx skills add forcedotcom/sf-skills. The rest of this post is why.
Day 3 was the roadmap for me. The Agentforce roadmap session covered what’s being built and planned for release over the next six to twelve months, and the biggest item is preview orgs.
A preview org is a copy of a sandbox that exists for a day. An agent working in a git worktree, a second checkout of the same codebase where it can make changes without touching yours, deploys to that copy, and you log in and look at what it did. The practice is borrowed from Heroku, whose review apps stand up a running copy of an application for every proposed change. That made our review faster because you could log in to the thing instead of reading the change and imagining it.
This solves the last mile of human verification. An agent can already write the code and open the pull request. What it couldn’t do was hand you a working org to click through before you said yes.
Pair that with the expanded tooling they showed for operationalizing the agentic lifecycle (reporting, triaging failures, deployment tooling) and the speed of ADLC on platform, the agentic development lifecycle, is going to be incredible.
The second thing is the through line of every session I sat in today: SF-Skills. A skill is a packaged task an AI tool already knows how to run in your org. SF-Skills is the repository of them, published and maintained by Salesforce, and they’re doing the work to keep the skills validated and professional. In a headless world, where an outside client reaches into your org instead of a screen, this is the central location where they’re publishing new capabilities. Installing with npx, one command from the terminal, will make upgrades easy. Admins and developers should be using them.
On Tuesday I asked what a skill is at the artifact level and how you’d ship one you wrote yourself. I’m reframing that question. For managing your Salesforce org, the starting place is don’t. Don’t write your own skills. Salesforce is publishing and maintaining the official ones, and those are the ones to use. What’s left of Tuesday’s question is the narrower one, what the artifact itself is, for the day you do need one of your own.
One hint once you’ve installed it. If you run the Salesforce Development plugin in Claude Code, its usage telemetry is on by default, and so is the Salesforce CLI’s. Both have a switch. Inside the plugin it’s /salesforce-development:telemetry off, and setting SF_DISABLE_TELEMETRY=true in your environment turns off both at once.
Claudeforce will be governed. Skills and permissions run through admins. Same goes for quick pages. Yesterday I wrote about the managed package that can’t ship with its MCP configuration ready to turn on, and the admin who ends up bridging that gap. This is the same answer from the roadmap side. The admin is where the control sits, so the admin’s work is the work to plan first.
Dave’s Day 3 dispatch, from the Architect’s Chair, is here.
Responses