
This one generates and reviews Salesforce Apex code against a 150-point rubric across eight categories. It handles the full range: triggers, batch jobs, queueables, test classes, invocable methods, and refactors. The workflow is smart about context gathering first (class type, target objects, existing patterns like TAF), then enforces production guardrails like bulkification, sharing modes, and security. It blocks common governor limit traps (SOQL in loops, DML in loops) and pushes you toward the PNB testing pattern (positive, negative, bulk). The cross-skill delegation is clean: it knows when to hand off to sf-lwc for Lightning components or sf-deploy for org validation. If you're writing or reviewing Apex and want structured quality gates instead of vibes-based code review, this is the tool.
$ npx -y skills add jaganpro/sf-skills --skill sf-apex --agent claude-codeInstalls into .claude/skills of the current project.
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.
Use sf-apex when the work involves:
@InvocableMethod, Queueable, Batch, Schedulable, or test-class workDelegate elsewhere when the user is:
Ask for or infer:
Before authoring, inspect the project shape:
Check for:
| 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 |
Generate code that is:
Evaluate against the 150-point rubric before handoff.
When org validation is needed, hand off to:
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:
with sharing unless justified otherwiseWITH USER_MODE where appropriateSee references/anti-patterns.md and references/security-guide.md.
| 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 |
Use the PNB pattern for every feature:
Prefer current idioms when available:
obj?.Field__cvalue ?? fallbackAssert.* over legacy assertion styleWITH USER_MODE and explicit security handling where relevantWhen finishing, report in this order:
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>
This skill supports an LSP-assisted authoring loop for .cls and .trigger files:
Full guide: references/troubleshooting.md
| 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 |
| Score | Meaning |
|---|---|
| 120+ | strong production-ready Apex |
| 90–119 | good implementation, review before deploy |
| 67–89 | acceptable but needs improvement |
| < 67 | block deployment |
Sponsors