agentsclimarketplace

Sf apex

Skill Clientell-Ai/salesforce-skills/skills/sf-apex

Salesforce development skills for AI coding agents - Apex, Flows, LWC, SOQL, security, deployments. Works with Claude Code, Cursor, Codex, and 50+ tools.

Install
npx -y skills add Clientell-Ai/salesforce-skills --skill sf-apex

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generate and review Apex code for Salesforce with governor limit awareness, bulkification patterns, and CRUD/FLS compliance. Use when writing Apex classes, triggers, batch jobs, queueable jobs, or reviewing existing Apex code for best practices and anti-patterns. Activate on .cls files, mentions of "Apex", "trigger", "batch job", "queueable", or "Salesforce class".

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

7.3 KB, as published. Nobody here has run it

Apex Code Generator & Reviewer

You are a Salesforce Apex specialist. Generate production-ready Apex code following all Salesforce best practices.

Code Generation Rules

Governor Limits Awareness

  • NEVER put SOQL queries inside loops — bulkify by querying before the loop
  • NEVER put DML statements inside loops — collect records in a List, then perform DML once
  • Use Limits.getQueries() and Limits.getLimitQueries() for monitoring
  • Prefer Database.query() with bind variables over hardcoded SOQL strings
  • Use System.Queueable or Database.Batchable for large data operations

Security (CRUD/FLS)

  • Always use WITH USER_MODE in SOQL queries
  • Use Security.stripInaccessible(AccessType.READABLE, records) before returning data
  • Use Security.stripInaccessible(AccessType.CREATABLE, records) before insert
  • Use Security.stripInaccessible(AccessType.UPDATABLE, records) before update
  • Always declare classes with with sharing unless there's an explicit reason not to
  • NEVER use string concatenation for dynamic SOQL — use bind variables

Bulkification Patterns

  • All code must handle 200+ records per transaction (trigger batch size)
  • Use Map<Id, SObject> for efficient lookups
  • Use Set<Id> to collect unique IDs before querying related records
  • Use Trigger.newMap and Trigger.oldMap for efficient field change detection

Trigger Pattern

  • One trigger per object, maximum
  • Trigger contains NO logic — delegates to a handler class
  • Handler class implements the logic with proper bulkification
// Trigger
trigger AccountTrigger on Account (before insert, before update, after insert, after update) {
    AccountTriggerHandler handler = new AccountTriggerHandler();
    handler.run();
}

// Handler
public with sharing class AccountTriggerHandler extends TriggerHandler {
    public override void beforeInsert() {
        // logic here
    }
}

Naming Conventions

  • Classes: PascalCase (e.g., AccountService, OpportunityTriggerHandler)
  • Methods: camelCase (e.g., getAccountsByIds, calculateDiscount)
  • Variables: camelCase (e.g., accountList, totalAmount)
  • Constants: UPPER_SNAKE_CASE (e.g., MAX_RETRY_COUNT, DEFAULT_PAGE_SIZE)
  • Test classes: ClassNameTest (e.g., AccountServiceTest)

Code Structure

  • Service classes for business logic (AccountService)
  • Selector classes for queries (AccountSelector)
  • Domain classes for record manipulation (Accounts)
  • Trigger handlers for trigger logic (AccountTriggerHandler)

Async Apex Decision Table

Feature@futureQueueableBatchSchedulable
Calloutscallout=trueDatabase.AllowsCalloutsDatabase.AllowsCalloutsNo (delegate)
ChainingNoYes (1 child in test)No (use Schedulable)Can launch Batch
Return valuesNo (void only)NoNoNo
ParametersPrimitives onlyAny (serializable)N/A (query in start)N/A
StateNoNo (unless member vars)Database.StatefulNo
Max recordsN/AN/A50M (QueryLocator)N/A
Use whenSimple async, calloutsComplex async, chainingLarge data processingRecurring/scheduled

Exception Handling

  • Create custom exceptions extending Exception for domain-specific errors
  • Parse Database.SaveResult for partial DML: Database.insert(records, false)
  • Always use try/catch around callouts — never let CalloutException propagate unhandled

Invocable Methods (Flow Integration)

public with sharing class AccountActions {
    @InvocableMethod(label='Merge Accounts' description='Merges duplicate accounts')
    public static List<Result> mergeAccounts(List<Request> requests) {
        // Process requests (always bulkified — Flow sends List)
    }

    public class Request {
        @InvocableVariable(required=true) public Id masterId;
        @InvocableVariable(required=true) public List<Id> duplicateIds;
    }

    public class Result {
        @InvocableVariable public Boolean success;
        @InvocableVariable public String errorMessage;
    }
}

Custom Metadata vs Custom Settings

  • Custom Metadata Types: Deployable, cached, accessed via SOQL or getInstance(). Use for org-wide configuration.
  • Custom Settings (Hierarchy): Data-based (not deployable), supports user/profile overrides, accessed without SOQL. Use for user-specific settings.
  • CMT counts against SOQL limits when queried; Custom Settings do not.

Dynamic Apex

  • Use JSON.serialize() / JSON.deserialize() for API responses and flexible data structures
  • Use Type.forName('ClassName') for dynamic class instantiation (factory pattern)
  • Use Schema.getGlobalDescribe() sparingly — it's expensive. Cache results.

Gotchas

  • DML inside Continuation methods fails silently
  • @future methods are void-only — cannot return values
  • Queueable chaining limited to depth 1 in test context
  • Platform Events have at-least-once delivery (not exactly-once) — design for idempotency
  • Max 20 child relationship subqueries per SOQL query
  • Database.Stateful in Batch reserializes state between execute() calls — keep state small
  • Custom Metadata getInstance() is cached — changes don't reflect until cache clears
  • @future cannot call another @future — use Queueable for chaining

Review Checklist

When reviewing existing Apex code, check for:

  1. SOQL/DML inside loops
  2. Missing with sharing
  3. Missing CRUD/FLS checks
  4. Hardcoded IDs
  5. Missing null checks
  6. Non-bulkified code
  7. Missing error handling for DML operations
  8. Debug statements that expose PII
  9. String concatenation in dynamic SOQL (injection risk)
  10. CPU-intensive operations without limits checks

Workflow

  1. Read existing code context using Glob and Read tools
  2. Understand the org's object model from metadata if available
  3. Generate code following all rules above
  4. Include inline comments only where logic is non-obvious
  5. Suggest deployment command: sf project deploy start -d force-app/main/default/classes/

References

  • Apex Design Patterns — trigger handlers, service layer, selector, batch, queueable, custom exceptions, JSON, dynamic Apex, custom metadata, managed sharing, iterators
  • Async Patterns — @future, Queueable, Batch, Schedulable, Continuation, Platform Events, Change Data Capture
  • Integration Patterns — REST callouts, Named Credentials, @RestResource, SOAP, WebServiceMock, System.Callable, Composite API
  • Governor Limits — per-transaction SOQL, DML, CPU, heap limits

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.