sf-apex: Salesforce Apex Code Generation and Review Skill

sf-apex: Salesforce Apex Code Generation and Review

Use this skill when the user needs production Apex: new classes, triggers, selectors, services, async jobs, invocable methods, test classes, or evidence-based review of existing .cls / .trigger code.

When This Skill Owns the Task

Use sf-apex when the work involves:

Apex class generation or refactoring
trigger design and trigger-framework decisions
@InvocableMethod, Queueable, Batch, Schedulable, or test-class work
review of bulkification, sharing, security, testing, or maintainability

Delegate elsewhere when the user is:

editing LWC JavaScript / HTML / CSS → sf-lwc
building Flow XML or Flow orchestration → sf-flow
writing SOQL only → sf-soql
deploying or validating metadata to orgs → sf-deploy

Required Context to Gather First

Ask for or infer:

class type: trigger, service, selector, batch, queueable, schedulable, invocable, test
target object(s) and business goal
whether code is net-new, refactor, or fix
org / API constraints if known
expected test coverage or deployment target

Before authoring, inspect the project shape:

existing classes / triggers
current trigger framework or handler pattern
related tests, flows, and selectors
whether TAF is already in use

Recommended Workflow

1. Discover local architecture

Check for:

existing trigger handlers / frameworks
service-selector-domain conventions
related tests and data factories
invocable or async patterns already used in the repo

2. Choose the smallest correct pattern

| Need | Preferred pattern | |---|---| | simple reusable logic | service class | | query-heavy data access | selector | | single object trigger behavior | one trigger + handler / TAF action | | Flow needs complex logic | @InvocableMethod | | background processing | Queueable by default | | very large datasets | Batch Apex or Database.Cursor patterns | | repeatable verification | dedicated test class + test data factory |

3. Author with guardrails

Generate code that is:

bulk-safe
sharing-aware
CRUD/FLS-safe where applicable
testable in isolation
consistent with project naming and layering

4. Validate and score

Evaluate against the 150-point rubric before handoff.

5. Hand off deploy/test next steps

When org validation is needed, hand off to:

sf-testing for test execution loops
sf-deploy for deploy / dry-run / verification

Generation Guardrails

Never generate these without explicitly stopping and explaining the problem:

| Anti-pattern | Why it blocks | |---|---| | SOQL in loops | governor-limit failure | | DML in loops | governor-limit failure | | missing sharing model | security / data exposure risk | | hardcoded IDs | deployment and portability failure | | empty catch blocks | silent failure / poor observability | | string-built SOQL with user input | injection risk | | tests without assertions | false-positive test suite |

Default fix direction:

query once, operate on collections
use with sharing unless justified otherwise
use bind variables and WITH USER_MODE where appropriate
create assertions for positive, negative, and bulk cases

See references/anti-patterns.md and references/security-guide.md.

High-Signal Build Rules

Trigger architecture

Prefer one trigger per object.
If TAF is already installed and used, extend it instead of inventing a second trigger pattern.
Triggers should delegate logic; avoid heavy business logic directly in trigger bodies.

Async choice

| Scenario | Default | |---|---| | standard async work | Queueable | | very large record processing | Batch Apex | | recurring schedule | Scheduled Flow or Schedulable | | post-job cleanup | Finalizer | | long-running Lightning callouts | Continuation |

Testing minimums

Use the PNB pattern for every feature:

Positive path
Negative / error path
Bulk path (251+ records where relevant)

Modern Apex expectations

Prefer current idioms when available:

safe navigation: obj?.Field__c
null coalescing: value ?? fallback
Assert.* over legacy assertion style
WITH USER_MODE and explicit security handling where relevant

Output Format

When finishing, report in this order:

What was created or reviewed
Files changed
Key design decisions
Risk / guardrail notes
Test guidance
Deployment guidance

Suggested shape:

Apex work: <summary>
Files: <paths>
Design: <pattern / framework choices>
Risks: <security, bulkification, async, dependency notes>
Tests: <what to run / add>
Deploy: <dry-run or next step>

LSP Validation Note

This skill supports an LSP-assisted authoring loop for .cls and .trigger files:

syntax issues can be detected immediately after write/edit
the skill can auto-fix common syntax errors in a short loop
semantic quality still depends on the 150-point review rubric

Full guide: references/troubleshooting.md

Cross-Skill Integration

| Need | Delegate to | Reason | |---|---|---| | describe objects / fields first | sf-metadata | avoid coding against wrong schema | | seed bulk or edge-case data | sf-data | create realistic test datasets | | run Apex tests / fix failing tests | sf-testing | execute and iterate on failures | | deploy to org | sf-deploy | validation and deployment orchestration | | build Flow that calls Apex | sf-flow | declarative orchestration | | build LWC that calls Apex | sf-lwc | UI/controller integration |

Reference Map

Start here

High-signal checklists

Specialized patterns

Troubleshooting / validation

Score Guide

| Score | Meaning | |---|---| | 120+ | strong production-ready Apex | | 90–119 | good implementation, review before deploy | | 67–89 | acceptable but needs improvement | | < 67 | block deployment |

Agent Skills: sf-apex: Salesforce Apex Code Generation and Review

Install this agent skill to your local

Skill Files