
Generating Apex
Scaffold Salesforce Apex abstract base classes with sharing, timeouts, and extension hooks for integration services.
Overview
Generating-apex is an agent skill for the Build phase that scaffolds Salesforce Apex abstract base classes for integration and service extension patterns.
Install
npx skills add https://github.com/forcedotcom/afv-library --skill generating-apexWhat is this skill?
- Abstract with sharing Apex class template with DEFAULT_TIMEOUT_MS
- Documents subclass responsibilities for endpoint and headers
- Structured sections for constants, protected state, constructor, and abstract methods
- Salesforce callout example using named credentials pattern
- Merge-conflict style stub signals hand-editing after generation
- Default timeout constant DEFAULT_TIMEOUT_MS = 30000 in template
Adoption & trust: 1.4k installs on skills.sh; 512 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need another Salesforce integration class but lack a consistent abstract base with sharing, timeouts, and documented extension points.
Who is it for?
Salesforce developers and indie consultancies spinning up multiple callout-based services with shared base behavior.
Skip if: Non-Salesforce backends, LWC-only frontends, or teams that already ship a finalized enterprise integration framework without Apex stubs.
When should I use this skill?
Creating or extending Salesforce Apex integration families that need a shared abstract base with documented subclass hooks.
What do I get? / Deliverables
You get a structured Apex abstract class skeleton ready for subclass-specific endpoints, headers, and integration logic.
- Apex abstract class file with extension points for endpoints and headers
- Documented subclass example for Salesforce REST callouts
Recommended Skills
Journey fit
How it compares
Apex class template generator, not a full Salesforce DX deploy or security review skill.
Common Questions / FAQ
Who is generating-apex for?
Salesforce builders and solo consultants using the AFV library who want repeatable abstract Apex patterns for HTTP and API integrations.
When should I use generating-apex?
During build backend when adding a new integration service class that should extend a shared abstract base with sharing and timeout defaults.
Is generating-apex safe to install?
Generated code still needs your org’s security and review standards; check the Security Audits panel on this Prism page for the parent repository.
SKILL.md
READMESKILL.md - Generating Apex
/** <<<<<<< Updated upstream * @description Abstract base class for {describe the family of classes this serves}. ======= * Abstract base class for {describe the family of classes this serves}. >>>>>>> Stashed changes * Provides common behavior and defines extension points for subclasses. * Subclasses must implement the abstract methods to provide specific behavior. * * @example * // Extending this abstract class: * public class SalesforceIntegrationService extends {ClassName} { * protected override String getEndpoint() { * return 'callout:Salesforce_API/services/data/v62.0'; * } * * protected override Map<String, String> getHeaders() { * return new Map<String, String>{ * 'Content-Type' => 'application/json' * }; * } * } */ public abstract with sharing class {ClassName} { // ─── Constants ─────────────────────────────────────────────────────── private static final Integer DEFAULT_TIMEOUT_MS = 30000; // ─── Protected State ───────────────────────────────────────────────── protected Integer timeoutMs; // ─── Constructor ───────────────────────────────────────────────────── /** * Initializes the base class with default configuration */ protected {ClassName}() { this.timeoutMs = DEFAULT_TIMEOUT_MS; } // ─── Abstract Methods (must be implemented by subclasses) ──────────── /** * Returns the endpoint URL for this integration. * Subclasses must provide their specific endpoint. * @return The endpoint URL as a String */ protected abstract String getEndpoint(); /** * Returns the HTTP headers for this integration. * Subclasses define their own required headers. * @return Map of header name to header value */ protected abstract Map<String, String> getHeaders(); // ─── Virtual Methods (can be overridden by subclasses) ─────────────── /** * Hook called before the main operation executes. * Override to add pre-processing logic. * Default implementation does nothing. * @param context Map of contextual data */ protected virtual void beforeExecute(Map<String, Object> context) { // Default: no-op — override in subclass if needed } /** * Hook called after the main operation completes. * Override to add post-processing logic. * Default implementation does nothing. * @param context Map of contextual data * @param result The result from the operation */ protected virtual void afterExecute(Map<String, Object> context, Object result) { // Default: no-op — override in subclass if needed } // ─── Template Method (common workflow) ─────────────────────────────── /** * Executes the operation using the template method pattern. * Calls beforeExecute → doExecute → afterExecute in sequence. * @param context Map of data needed for the operation * @return The result of the operation */ public Object execute(Map<String, Object> context) { beforeExecute(context); Object result; try { result = doExecute(context); } catch (Exception e) { handleError(e); throw e; } afterExecute(context, result); return result; } // ─── Protected Helpers ─────────────────────────────────────────────── /** * Core execution logic — override this for the main operation. * Default implementation throws — subclass must provide implementation. * @param context Map of data needed for the operation * @return The result of the operation */ protected virtual Object doExecute(Map<String, Object> context) { throw new UnsupportedOperationException( 'Subclass must override doExecute()'