Platform Apex Generate

Generating Apex

Use this skill for production-grade Apex: new classes, selectors, services, async jobs, invocable methods, and triggers; and for evidence-based review of existing .cls OR .trigger.

Required Inputs

Gather or infer before authoring:

• Class type (service, selector, domain, batch, queueable, schedulable, invocable, trigger, trigger action, DTO, utility, interface, abstract, exception, REST resource)
• Target object(s) and business goal
• Class name (derive using the naming table below)
• Net-new vs refactor/fix; any org/API constraints
• Deployment targets (default to runSpecifiedTests and use generated tests where applicable)

Defaults unless specified:

• Sharing: with sharing (see sharing rules per type below)
• Access: public (use global only when required by managed packages or @RestResource)
• API version: 66.0 (minimum version)
• ApexDoc comments: yes

If the user provides a clear, complete request, generate immediately without unnecessary back-and-forth.

Workflow

All steps are sequential. Do not skip, merge, or reorder. If blocked, stop and ask for missing context. If not applicable, mark N/A with a one-line justification in the report.

Phase 1 — Author

1. Discover project conventions

• Service-Selector-Domain layering, logging utilities
• Existing classes/triggers and current trigger framework or handler pattern
• Whether Trigger Actions Framework (TAF) is already in use
• When refactoring or reviewing an existing .cls, call mcp__plugin_salesforce-development_salesforce-lsp__apex_documentSymbol with {filePath: "<absolute-path>"} to map the class's methods, properties, and inner types before editing, and call mcp__plugin_salesforce-development_salesforce-lsp__apex_hover with {filePath, line, character} (one-based line/character) to resolve the type or signature of a symbol you are unsure about. On error envelope or unavailable ({error: <code>} / tool not registered), fall back to reading the source directly.

1. Choose the smallest correct pattern (see Type-Specific Guidance below)

1. Review templates and assets

• Read the matching template from assets/ before authoring (see Type-Specific Guidance for the file mapping)
• When a references/ example exists for the type, read it as a concrete style guide
• For any test class work, always read and use platform-apex-test-generate skill

1. Author with guardrails -- apply every rule in the Rules section below

• Generate {ClassName}.cls with ApexDoc
• Generate {ClassName}.cls-meta.xml

1. Generate test classes -- Load the skill platform-apex-test-generate to create {ClassName}Test.cls and {ClassName}Test.cls-meta.xml. Apex tests are always required to be generated to deploy. No test file creation or edits can occur without loading the platform-apex-test-generate skill to generate tests.

Phase 2 — Validate (required before reporting)

Writing files is the midpoint, not the finish line. Steps 6, 7, and 8 each require a tool invocation and produce output that must appear in the Step 9 report. Do not summarize or present the report until all three steps have run and their output is captured.

1. Compile-check every file (REQUIRED) — via the diagnostics tool when available, otherwise via the fallback. Running one of these is mandatory; which one depends on what your environment exposes.

• Preferred: Invoke mcp__plugin_salesforce-development_salesforce-lsp__apex_diagnostics with {filePath: "<absolute-path>"} on every generated/updated .cls and `.trigger` file to compile-check and surface errors/warnings before deploy.
• On success with diagnostics ({ok: true}, non-empty list), remediate all diagnostics with severity error or warning; re-run until clean.
• Fail closed on an empty diagnostics result — always. The tool returns {ok: true, diagnostics: []} for BOTH a genuinely clean compile AND a swallowed timeout/internal error, so an empty list is not by itself proof the code compiled. Whenever diagnostics come back empty, you MUST corroborate with the Fallback (sf project deploy start --dry-run) before reporting the file as clean or deploy-ready. Do not treat any empty apex_diagnostics response as a passing compile on its own.
• On error envelope ({error: <code>}), record apex_diagnostics=unavailable: <code> and use the Fallback.
• On unavailable (tool not registered), record apex_diagnostics=unavailable: lsp_not_present and use the Fallback.
• If the tool is not resolvable in this environment — e.g. it is a deferred tool and a ToolSearch for it returns no match, or the call otherwise cannot be made — do NOT stall or retry discovery. Record apex_diagnostics=unavailable: lsp_not_present and use the Fallback immediately.
• If diagnostics report an unknown field or object that you just deployed, call mcp__plugin_salesforce-development_salesforce-lsp__refresh_org_schema to invalidate the cached org describe, then re-run apex_diagnostics before treating it as a real code error.
• Fallback (fully satisfies this step): Compile-check via sf project deploy start --dry-run and read CLI errors. Remediate any errors and re-run until clean. A clean fallback result is a valid, complete outcome for this step — the diagnostics MCP tool is preferred, not required, when it is not available.
• Compilation is this step's only concern. It does NOT cover PMD, CRUD/FLS, or complexity rules — those are static analysis, run as a separate required step below (Step 7).
• NEVER report a class or trigger as valid or deploy-ready without running EITHER the diagnostics tool OR the fallback. "The tool wasn't available" is not a reason to skip validation — fall back and validate. Recording apex_diagnostics=unavailable: <reason> is only acceptable alongside a completed fallback.
• Capture the final tool (or fallback) output verbatim for the report.

1. Run static analysis (REQUIRED) — compilation does not check PMD, CRUD/FLS, complexity, and related rules; this step does.

• Invoke sf code-analyzer run --target <target> on all generated/updated .cls and .trigger files. Remediate all sev0, sev1, and sev2 violations; re-run until clean.
• This is a distinct gate from Step 6 — a clean compile does not satisfy it, and running it does not substitute for the compile-check.
• If Code Analyzer cannot run in this environment, record run_code_analyzer=unavailable: <reason> in the report. That explicit outcome is the only acceptable way to skip it.
• Capture the final tool output verbatim for the report.

1. Execute Apex tests

• Run org tests including {ClassName}Test via sf apex run test or MCP.
• Delegate all test generation/fixes/coverage work to platform-apex-test-generate; iterate until the tests pass.
• Capture pass/fail counts and coverage percentage for the report.
• If unavailable, record test_execution=unavailable: <error> in the report.

Phase 3 — Report

1. Report -- use the output format at the bottom of this file.

• The Compile line must contain the actual Step 6 output — either the diagnostics tool result, or the fallback (sf project deploy start --dry-run) result prefixed with apex_diagnostics=unavailable: <reason>. Code Analyzer does NOT belong on this line — it cannot establish that Apex compiles.
• The Analyzer line must contain the actual Step 7 sf code-analyzer run output (or run_code_analyzer=unavailable: <reason> after attempting invocation).
• The Testing line must contain the actual Step 8 results (or test_execution=unavailable: <reason> after attempting invocation).
• A report missing any of these lines is incomplete. Always run each step or record its explicit unavailable outcome before reporting.

Rules

Hard-Stop Constraints (Must Enforce)