Context Engineering Series · Part 5
Part 1 gave Claude memory, Part 2 showed what happens without it, and Part 3 connected it to your systems. This one is about getting it to actually build Salesforce... with the 65 skills I had installed when I wrote this, the sf CLI, and a language the model had never seen.
The stack I ended up with turns "write me an Apex class" into production code that comes back with a 150-point validation score, and the agent I built on it, further down this page, took zero clicks in Agent Builder.
Claude already knows Salesforce, it can write Apex, design Flows, and scaffold LWC components. Ask it for an async job, though, and it might hand you @future methods when Queueable with a Finalizer is the recommended pattern, because training data has a cutoff and doesn't reflect the platform features, API changes, and deprecations that came after it. That's the outdated part.
A lot of what it knows is also approximate. It has the Apex syntax down, but unless you prompt for it, it won't enforce governor limits or sharing model defaults or CRUD/FLS checks, and you get code that compiles fine and may not survive a security review. Those gaps compound once you're in production.
Agent Script is a different kind of problem, because it wasn't in the training data at all and nothing about the output looks off. It's Salesforce's language for authoring Agentforce agents, and it launched in 2025, after the training cutoff of the models I was using, so Claude had never seen it. It pattern-matches from Python instead and hands you Agent Script that looks syntactically reasonable, with 4-space indentation and subagents and actions all defined. It compiles in your head, and then it fails on the platform. Have you ever tried to figure out why a .agent file won't work when nobody in the conversation, you or Claude, has the actual language spec? It's a dead end.
Each layer compensates for the one above it, and the bottom layer, the Agent Script reference files, carries what the model I was building with had no way of knowing.
Apex, LWC, Flow, SOQL, the metadata API, and platform concepts like governor limits and the sharing model. It's the foundation, broad but imprecise, and it can be out of date on anything that shipped after the cutoff.
This is live org execution. Instead of generating code from memory, Claude runs commands against a real Salesforce org to deploy, test, validate, and preview, using these:
I had 65 of these installed as of this build, 30 from Salesforce's official forcedotcom/afv-library and 35 community skills. They're structured workflows with templates, scoring rubrics, hard-stop constraints, and validation pipelines, and when one of them conflicts with training data, the skill wins. This is where the 150-point Apex scoring comes from, along with 14 class templates, the safety reviews, and the code analyzer integration.
Everything Claude knows about Agent Script comes from 24 reference docs and 18 asset files inside the skill. The execution model, the syntax rules, the anti-patterns, and the known issues weren't in the training data of the model I was building with, so for this one language the skill is the only source Claude has to work from. It also carries a 100-point rubric, a safety review across seven categories, and the hub-and-spoke FSM pattern the agents are built around.
Thirty of mine came from Salesforce's official AFV library, forcedotcom/afv-library, which the Agentforce Vibes team maintains. Those are production-grade generators with templates, scoring, and validation built in, so they're what actually creates the code and metadata. The other 35 are the sf-* community skills that come pre-installed with Claude Code. They cover Data Cloud, Industries, architecture review, debugging, SOQL optimization, and whatever the AFV library didn't cover when I installed it... more reviewers than builders, and you really do need both kinds.
Here's how the 65 broke down by category when I counted them:
| Agentforce | 3 | Build, test, observe agents |
| Apex | 3 | Generate, test, refactor |
| UI Bundle | 10 | React apps on Salesforce |
| Metadata | 8 | Objects, fields, pages, tabs |
| Data Cloud | 7 | Connect to activate |
| Industries | 7 | OmniStudio, CME, EPC |
| Flow | 1 | MCP 3-step pipeline |
| Utility | 26 | Deploy, debug, SOQL, docs |
I built an intelligence platform with 7 Agentforce topics and 63 agent actions, and every one of those actions had to be wired to an Apex invocable method by hand in the Agent Builder UI. That meant scanning Apex classes for @InvocableMethod myself, mapping I/O parameters through trial and error, and debugging routing through Setup UI logs, with no version control on any of the agent configuration. It took weeks across multiple sessions.
Three skills replace that entire workflow. The first is /developing-agentforce. You describe the agent in natural language, it scans the project for @InvocableMethod and marks each action EXISTS or NEEDS STUB, then it generates the .agent file and the backing logic, with stubs for whatever's missing and I/O typed from the skill's reference docs. It previews with mocked actions, previews again live, and only then publishes, scoring the agent against a 100-point rubric and running a safety review on the way.
/testing-agentforce handles validation with ad-hoc preview testing (Mode A), batch test specs in YAML (Mode B), a safety verdict per conversation, direct action execution over REST, and regression suites you can run in CI/CD. When something fails it goes into a fix loop, capped at three iterations. /observing-agentforce is the monitor-and-improve side. It queries STDM from Data Cloud, analyzes session traces, classifies the issue, reproduces it in preview, then edits, validates, and re-publishes, and it watches for regressions, where before I'd have been digging through Setup UI logs.
Agent Builder defaults actions to isLocal=true, so they run mocked instead of connected to real data, and you usually find that out at publish time after a round of manual testing. The skill pipeline catches it earlier. It previews first with mocked actions to test routing, then switches to --use-live-actions to verify that real data flows, and the publish checkpoint won't clear until a live-action preview passes.
The way we split the work is that the SE describes what they want and Claude builds it, with a checkpoint in front of every irreversible action. I'll say something like "build an agent for order status," the skill activates from context, and Claude generates, validates, and previews on its own, since construction and validation run autonomously. Then it stops so I can review and approve, because design and go/no-go decisions stay with the human, and only after I sign off does it publish, activate, and verify. The .agent file sits in git the whole time, so every change is diffable and reviewable.
Most Salesforce development work maps to one of seven skill sequences, and you don't have to pick them yourself, you describe what you need and the right skills activate. For an Agentforce agent it's /developing-agentforce into /generating-apex into /testing-agentforce, which takes you from the Agent Spec through scanning the backing logic, generating stubs, validating, previewing mocked and then live, and publishing. Writing Apex is shorter, /generating-apex and then /generating-apex-test, in a 3-phase workflow that authors the code, validates it with the code analyzer and tests, and reports back with a score.
For metadata, /generating-lightning-app orchestrates all of it, objects, fields, validation rules, pages, tabs, apps, and permission sets, in that order. React on Salesforce works the same way, with /building-ui-bundle-app orchestrating 10 skills to scaffold the app, wire up data access, build features, add Agentforce chat, and deploy to an Experience Site. A Data Cloud pipeline (connect, prepare, harmonize into DMOs, segment, activate, retrieve) runs on the seven /sf-datacloud-* skills, which exist only on the sf-* side. The last two playbooks, Industries and DevOps, pair /sf-industry-* for OmniStudio work (OmniScripts, FlexCards, IPs) with /sf-deploy and /switching-org for deployment, org switching, and architecture review.
The Meridian agent is a full 7-topic, 68-action Agentforce agent, and I built it from scratch and published it to a live org entirely through the Agent Script CLI... while I was outside doing yard work.
It took six iterations and about three hours, and the skills didn't get it right on the first try. Each failure came back early with an error I could act on, which training data alone had never given me, so I knocked out one wrong structure at a time until the sixth attempt published.
A few tools did the unblocking. The Salesforce Docs MCP was the breakthrough, searching the live docs mid-session and finding the canonical two-level pattern that the model's training data didn't have. sf agent validate ran the server compiler and gave me exact line numbers with "did you mean?" suggestions, and instead of guessing at the Flow I/O, I extracted the actual schemas from 38 flow files programmatically. The Tooling API handled the cleanup, deleting an orphaned action, assigning permissions, and querying metadata without my ever opening a browser.
The full set I used: /sf-ai-agentscript for the DSL reference, validator, and architecture patterns, /developing-agentforce for the metadata lifecycle and safety review, the salesforce-docs MCP for live doc search, sf agent validate/publish for server-side compilation and deploy, sf data create record for programmatic permission assignment, and sf api request rest to reach the Tooling API for the orphan cleanup.
What came out the other end is the Meridian Intelligence Agent, with 7 persona topics and 68 actions bound, published to a live Salesforce org with sf agent publish authoring-bundle. It's version-controlled in git, diffable and reproducible, and it needed no Agent Builder UI at all.
You can skip all five failures. Download the Agent Script rules file, drop it in ~/.claude/rules/, and your Claude starts from our 6th iteration, the one that worked.
Or grab the full starter kit with git clone https://github.com/jtehrani84/claude-code-se-starter-kit.git
If you have Claude Code and the Salesforce CLI, you're about 60 seconds from the full stack.
labs.agentforce.com gives you instant headless access to Agentforce from Claude Code, Codex, Cursor, or Vibes, with no org provisioning and no setup screens, so you can connect and start building in minutes.
This installs the official Salesforce skills (30 when I set it up) in under 30 seconds. Run it again every month or so to pick up whatever's been added.
That points Claude at your Salesforce org, and any skill that needs org access, like preview, deploy, or test, uses the connection.
Skills trigger on their own based on context, so there's no need to memorize commands.
Salesforce colleagues, there's an internal Slack canvas with the full toolkit, including Agentforce Labs access, the ADLC plugin, ADL Data Libraries, Custom Scorers, and Custom Connections skills. Search "Build Fast with Coding Agents" in Slack or ask your CKO channel.
Wiki, CLAUDE.md, hooks, rules
From wrong to expert
Connecting to your systems
Thinking in graphs
The Salesforce development stack
When the files act as one system
A harness that grades its work
Safe, portable, human-gated
Autonomy on a leash
Where the harness belongs
Part 6 asks what happens when all these files start behaving like one system: From Memory to an Operating System →