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:
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 |
1---2name: sf-apex3description: Generates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.4license: MIT5---6
7# sf-apex: Salesforce Apex Code Generation and Review
8
9Use 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.
10
11## When This Skill Owns the Task
12
13Use `sf-apex` when the work involves:
14- Apex class generation or refactoring
15- trigger design and trigger-framework decisions
16- `@InvocableMethod`, Queueable, Batch, Schedulable, or test-class work
17- review of bulkification, sharing, security, testing, or maintainability
18
19Delegate elsewhere when the user is:
20- editing LWC JavaScript / HTML / CSS → [sf-lwc](../sf-lwc/SKILL.md)
21- building Flow XML or Flow orchestration → [sf-flow](../sf-flow/SKILL.md)
22- writing SOQL only → [sf-soql](../sf-soql/SKILL.md)
23- deploying or validating metadata to orgs → [sf-deploy](../sf-deploy/SKILL.md)
24
25---
26
27## Required Context to Gather First
28
29Ask for or infer:
30- class type: trigger, service, selector, batch, queueable, schedulable, invocable, test
31- target object(s) and business goal
32- whether code is net-new, refactor, or fix
33- org / API constraints if known
34- expected test coverage or deployment target
35
36Before authoring, inspect the project shape:
37- existing classes / triggers
38- current trigger framework or handler pattern
39- related tests, flows, and selectors
40- whether TAF is already in use
41
42---
43
44## Recommended Workflow
45
46### 1. Discover local architecture
47Check for:
48- existing trigger handlers / frameworks
49- service-selector-domain conventions
50- related tests and data factories
51- invocable or async patterns already used in the repo
52
53### 2. Choose the smallest correct pattern
54| Need | Preferred pattern |
55|---|---|
56| simple reusable logic | service class |
57| query-heavy data access | selector |
58| single object trigger behavior | one trigger + handler / TAF action |
59| Flow needs complex logic | `@InvocableMethod` |
60| background processing | Queueable by default |
61| very large datasets | Batch Apex or `Database.Cursor` patterns |
62| repeatable verification | dedicated test class + test data factory |
63
64### 3. Author with guardrails
65Generate code that is:
66- bulk-safe
67- sharing-aware
68- CRUD/FLS-safe where applicable
69- testable in isolation
70- consistent with project naming and layering
71
72### 4. Validate and score
73Evaluate against the 150-point rubric before handoff.
74
75### 5. Hand off deploy/test next steps
76When org validation is needed, hand off to:
77- [sf-testing](../sf-testing/SKILL.md) for test execution loops
78- [sf-deploy](../sf-deploy/SKILL.md) for deploy / dry-run / verification
79
80---
81
82## Generation Guardrails
83
84Never generate these without explicitly stopping and explaining the problem:
85
86| Anti-pattern | Why it blocks |
87|---|---|
88| SOQL in loops | governor-limit failure |
89| DML in loops | governor-limit failure |
90| missing sharing model | security / data exposure risk |
91| hardcoded IDs | deployment and portability failure |
92| empty `catch` blocks | silent failure / poor observability |
93| string-built SOQL with user input | injection risk |
94| tests without assertions | false-positive test suite |
95
96Default fix direction:
97- query once, operate on collections
98- use `with sharing` unless justified otherwise
99- use bind variables and `WITH USER_MODE` where appropriate
100- create assertions for positive, negative, and bulk cases
101
102See [references/anti-patterns.md](references/anti-patterns.md) and [references/security-guide.md](references/security-guide.md).
103
104---
105
106## High-Signal Build Rules
107
108### Trigger architecture
109- Prefer **one trigger per object**.
110- If TAF is already installed and used, extend it instead of inventing a second trigger pattern.
111- Triggers should delegate logic; avoid heavy business logic directly in trigger bodies.
112
113### Async choice
114| Scenario | Default |
115|---|---|
116| standard async work | Queueable |
117| very large record processing | Batch Apex |
118| recurring schedule | Scheduled Flow or Schedulable |
119| post-job cleanup | Finalizer |
120| long-running Lightning callouts | `Continuation` |
121
122### Testing minimums
123Use the **PNB** pattern for every feature:
124- **Positive** path
125- **Negative** / error path
126- **Bulk** path (251+ records where relevant)
127
128### Modern Apex expectations
129Prefer current idioms when available:
130- safe navigation: `obj?.Field__c`
131- null coalescing: `value ?? fallback`
132- `Assert.*` over legacy assertion style
133- `WITH USER_MODE` and explicit security handling where relevant
134
135---
136
137## Output Format
138
139When finishing, report in this order:
1401. **What was created or reviewed**
1412. **Files changed**
1423. **Key design decisions**
1434. **Risk / guardrail notes**
1445. **Test guidance**
1456. **Deployment guidance**
146
147Suggested shape:
148
149```text
150Apex work: <summary>
151Files: <paths>
152Design: <pattern / framework choices>
153Risks: <security, bulkification, async, dependency notes>
154Tests: <what to run / add>
155Deploy: <dry-run or next step>
156```
157
158---
159
160## LSP Validation Note
161
162This skill supports an LSP-assisted authoring loop for `.cls` and `.trigger` files:
163- syntax issues can be detected immediately after write/edit
164- the skill can auto-fix common syntax errors in a short loop
165- semantic quality still depends on the 150-point review rubric
166
167Full guide: [references/troubleshooting.md](references/troubleshooting.md#lsp-based-validation-auto-fix-loop)
168
169---
170
171## Cross-Skill Integration
172
173| Need | Delegate to | Reason |
174|---|---|---|
175| describe objects / fields first | [sf-metadata](../sf-metadata/SKILL.md) | avoid coding against wrong schema |
176| seed bulk or edge-case data | [sf-data](../sf-data/SKILL.md) | create realistic test datasets |
177| run Apex tests / fix failing tests | [sf-testing](../sf-testing/SKILL.md) | execute and iterate on failures |
178| deploy to org | [sf-deploy](../sf-deploy/SKILL.md) | validation and deployment orchestration |
179| build Flow that calls Apex | [sf-flow](../sf-flow/SKILL.md) | declarative orchestration |
180| build LWC that calls Apex | [sf-lwc](../sf-lwc/SKILL.md) | UI/controller integration |
181
182---
183
184## Reference Map
185
186### Start here
187- [references/patterns-deep-dive.md](references/patterns-deep-dive.md)
188- [references/security-guide.md](references/security-guide.md)
189- [references/bulkification-guide.md](references/bulkification-guide.md)
190- [references/testing-patterns.md](references/testing-patterns.md)
191
192### High-signal checklists
193- [references/code-review-checklist.md](references/code-review-checklist.md)
194- [references/anti-patterns.md](references/anti-patterns.md)
195- [references/naming-conventions.md](references/naming-conventions.md)
196
197### Specialized patterns
198- [references/trigger-actions-framework.md](references/trigger-actions-framework.md)
199- [references/automation-density-guide.md](references/automation-density-guide.md)
200- [references/flow-integration.md](references/flow-integration.md)
201- [references/triangle-pattern.md](references/triangle-pattern.md)
202- [references/design-patterns.md](references/design-patterns.md)
203- [references/solid-principles.md](references/solid-principles.md)
204
205### Troubleshooting / validation
206- [references/troubleshooting.md](references/troubleshooting.md)
207- [references/llm-anti-patterns.md](references/llm-anti-patterns.md)
208- [references/testing-guide.md](references/testing-guide.md)
209
210---
211
212## Score Guide
213
214| Score | Meaning |
215|---|---|
216| 120+ | strong production-ready Apex |
217| 90–119 | good implementation, review before deploy |
218| 67–89 | acceptable but needs improvement |
219| < 67 | block deployment |