How to use the Salesforce Developer agent skill

What the Salesforce Developer skill makes the agent do

An agent skill is a folder with a SKILL.md file and optional reference documents. When a skill is installed and your request matches its description, the agent loads those instructions and follows them while it works. This skill is written for Salesforce development.

Once installed, the agent writes and debugs Apex code, builds Lightning Web Components, optimizes SOQL queries, and sets up triggers, batch jobs, platform events and integrations. It steers toward bulk-safe patterns that avoid Salesforce governor limits, and it suggests Salesforce DX and CI/CD deployment practices. It also includes test-class examples.

• Apex classes, triggers and a service-layer pattern
• Lightning Web Components (HTML, JavaScript and meta XML files)
• SOQL and SOSL query optimization and relationship queries
• Batch Apex, async processing and error handling
• REST callouts and integration patterns
• Salesforce DX project setup, scratch orgs and deployment

How do you install the Salesforce Developer skill?

Download the ZIP file from the skill page on this site and unzip it. You can install it in one of two ways.

For a personal install, unzip it into ~/.claude/skills/. To make it available only inside one project, unzip it into that project's .claude/skills/ folder.

If you use the Claude apps, you can instead upload the skill under Settings → Capabilities → Skills.

• Personal: unzip into ~/.claude/skills/
• Single project: unzip into the project's .claude/skills/
• Claude apps: Settings → Capabilities → Skills, then upload

How do you trigger the skill with natural requests?

You do not need a special command. Describe the Salesforce task in plain language, and the agent will use the skill when your request matches its description. The skill's trigger words include Salesforce, Apex, Lightning Web Components, LWC, SOQL, SOSL, Salesforce DX, governor limits, triggers, platform events and CRM integration.

Be specific about the object, the business rule and the volume of records. Mentioning bulk processing or governor limits helps the agent choose bulk-safe patterns.

• Write an Apex trigger on Account that copies the parent's name into a description field, and make it bulk-safe.
• Build an LWC counter component I can place on a record page.
• Optimize this SOQL query that runs inside a loop over Contacts.
• Create a batch job that updates Contacts with no email, in chunks of 200.
• Set up a Salesforce DX project with scratch org config and a CI/CD deployment outline.

What do the examples look like?

The skill's examples show the bulk-safe approach. In the trigger example, the code collects parent IDs, runs one query outside the loop, and then sets values from a map. The incorrect version runs a query inside the loop, which the skill marks as a governor limit violation.

The batch example implements Database.Batchable and uses Database.update(scope, false) so that one failed record does not stop the whole batch. The test-class example inserts 200 records to cover a bulk scenario and checks the results with System.assert.

• Bulkified trigger handler with one query outside the loop
• Batch Apex class started with Database.executeBatch(..., 200)
• Test class with @TestSetup and a 200-record bulk test
• Selective SOQL with indexed fields and relationship queries

What do you need before you start?

You need a Salesforce org to test against. A Developer Edition org is suitable for testing. The guidance refers to Salesforce CLI and Salesforce DX tooling for deployment, so install those if you plan to deploy code from a project.

The skill itself does not run scripts and does not use the network. Its rules require test classes with at least 90% code coverage, including bulk scenarios.

• A Salesforce org or Developer Edition for testing
• Salesforce CLI / Salesforce DX tooling for deployment
• An MIT-licensed skill, so you can use and modify it under those terms

What safety checks should you apply?

Review all generated Apex and metadata before it reaches a shared or production org. Generated code can break existing workflows or violate sharing rules, so a human should check it. The skill's own rules say to skip nothing on field-level security or sharing rules, and to avoid hard-coded IDs and credentials.

Declarative configuration that Flow or admin tools can handle does not need code. Use the skill for work that really needs Apex or LWC.

• Test in a sandbox or Developer Edition org first
• Read the test classes and confirm they cover bulk scenarios
• Check that field-level security and sharing rules are respected
• Confirm no IDs or credentials are hard-coded
• Do not use it for non-Salesforce platforms

What tips help you get better results?

Ask for the whole chain: the trigger, the handler, the test class and the deployment steps. Ask the agent to explain any governor limit it is worried about, and ask it to use async processing such as batch or queueable for long-running work.

If the output is not what you want, name the pattern you expect, such as a service class or a selective query on an indexed field.

• Name the object, fields and expected record volume
• Ask for a test class with a 200-record bulk test
• Ask for async processing when work is long-running
• Review the output as you would a pull request