sf-apex

$27

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

• references/patterns-deep-dive.md

• references/security-guide.md

• references/bulkification-guide.md

• references/testing-patterns.md

High-signal checklists

• references/code-review-checklist.md

• references/anti-patterns.md

• references/naming-conventions.md

Specialized patterns

• references/trigger-actions-framework.md

• references/automation-density-guide.md

• references/flow-integration.md

• references/triangle-pattern.md

• references/design-patterns.md

• references/solid-principles.md

Troubleshooting / validation

• references/troubleshooting.md

• references/llm-anti-patterns.md

• references/testing-guide.md

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