Apex Class

Generate well-structured, production-ready Apex classes for Salesforce development.

Scope

Generates:

• •Service classes (business logic layer)
• •Selector / query classes (SOQL encapsulation)
• •Domain classes (SObject-specific logic)
• •Batch Apex classes (Database.Batchable)
• •Queueable Apex classes (Queueable, optionally Finalizer)
• •Schedulable Apex classes (Schedulable)
• •DTO / wrapper / request-response classes
• •Utility / helper classes
• •Custom exception classes
• •Interfaces and abstract classes

Does NOT generate:

• •Triggers (use a trigger framework skill)
• •Unit tests (use a test writer skill)
• •Aura controllers
• •LWC JavaScript controllers

Gathering Requirements

Before generating code, gather these inputs from the user (ask if not provided):

1. •Class type — Service, Selector, Batch, Queueable, Schedulable, Domain, DTO, Utility, Interface, Abstract, Exception
2. •Class name — or enough context to derive a meaningful name
3. •SObject(s) involved — if applicable
4. •Business requirements — plain-language description of what the class should do
5. •Optional preferences:
   • •Sharing model (with sharing, without sharing, inherited sharing)
   • •Access modifier (public or global)
   • •API version (default: 62.0)
   • •Whether to include ApexDoc comments (default: yes)

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

Code Standards — ALWAYS Follow These

Separation of Concerns

• •Service classes contain business logic. They call Selectors for data and may call Domain classes for SObject-specific behavior.
• •Selector classes encapsulate all SOQL queries. Services never contain inline SOQL.
• •Domain classes encapsulate SObject-specific logic (field defaults, validation, transformation).
• •Keep classes focused on a single responsibility.

Bulkification

• •All methods must operate on collections (List, Set, Map) by default.
• •Never accept a single SObject when a List<SObject> is appropriate.
• •Provide convenience overloads for single-record callers only when it makes the API cleaner, and have them delegate to the bulk method.

Governor Limit Safety

• •No SOQL or DML inside loops. Ever.
• •Collect IDs/records first, query/DML once outside the loop.
• •Use Limits class checks in batch/bulk operations where appropriate.
• •Prefer Database.insert(records, false) with error handling in batch contexts.

Sharing Model

• •Default to with sharing unless the user specifies otherwise.
• •If without sharing or inherited sharing is used, add an ApexDoc @description comment explaining WHY.

Naming Conventions

ApexDoc Comments

Include ApexDoc on every public and global method and on the class itself:

/**
 * @description Brief description of what the class does
 * @author Generated by Apex Class Writer Skill
 */

/**
 * @description Brief description of what the method does
 * @param paramName Description of the parameter
 * @return Description of the return value
 * @example
 * List<Account> results = AccountService.deduplicateAccounts(accountIds);
 */

Null Safety

• •Use guard clauses at the top of methods for null/empty inputs.
• •Use safe navigation (?.) where appropriate.
• •Return empty collections rather than null.

Constants

• •No magic strings or numbers in logic.
• •Use private static final constants or a dedicated constants class.
• •Use Label. custom labels for user-facing strings when appropriate.

Custom Exceptions

• •Each service class should define or reference a corresponding custom exception.
• •Inner exception classes are preferred for simple cases: public class AccountServiceException extends Exception {}
• •Include meaningful error messages with context.

Error Handling

• •Catch specific exceptions, not generic Exception unless re-throwing.
• •Log errors meaningfully (assume a logging utility exists or stub one).
• •In batch contexts, use Database.SaveResult / Database.UpsertResult with partial success.

Output Format

For every class, produce TWO files:

1. •{ClassName}.cls — The Apex class source code
2. •{ClassName}.cls-meta.xml — The metadata file

Meta XML Template

<?xml version="1.0" encoding="UTF-8"?>
<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>{API_VERSION}</apiVersion>
    <status>Active</status>
</ApexClass>

Default apiVersion is 62.0 unless the user specifies otherwise.

Class Type–Specific Instructions

Service Classes

• •Read and follow: templates/service.cls
• •Stateless — no instance variables holding mutable state
• •All public methods should be static unless there's a compelling reason for instance methods
• •Delegate queries to a Selector class
• •Wrap business logic errors in a custom exception

Selector Classes

• •Read and follow: templates/selector.cls
• •One Selector per SObject (or per logical query domain)
• •Return List<SObject> or Map<Id, SObject>
• •Accept filter criteria as method parameters, not hardcoded
• •Include a private method that returns the base field list to keep DRY

Domain Classes

• •Read and follow: templates/domain.cls
• •Encapsulate field-level defaults, derivations, and validations
• •Operate on List<SObject> — designed to be called from triggers or services
• •No SOQL or DML — only in-memory SObject manipulation

Batch Classes

• •Read and follow: templates/batch.cls
• •Implement Database.Batchable<SObject> and optionally Database.Stateful
• •Use Database.QueryLocator in start() for large datasets
• •Handle partial failures in execute() using Database.SaveResult
• •Implement meaningful finish() — at minimum, log completion

Queueable Classes

• •Read and follow: templates/queueable.cls
• •Implement Queueable and optionally Database.AllowsCallouts
• •Accept data through the constructor — queueables are stateful
• •For chaining, include guard logic to prevent infinite chains
• •Optionally implement Finalizer for error recovery

Schedulable Classes

• •Read and follow: templates/schedulable.cls
• •Implement Schedulable
• •Keep execute() lightweight — delegate to a Batch or Queueable
• •Include a static method that returns a CRON expression for convenience
• •Document the expected schedule in ApexDoc

DTO / Wrapper Classes

• •Read and follow: templates/dto.cls
• •Use public properties — no getters/setters unless validation is needed
• •Include a no-arg constructor and optionally a parameterized constructor
• •Implement Comparable if sorting is needed
• •Keep them serialization-friendly (no transient state unless intentional)

Utility Classes

• •Read and follow: templates/utility.cls
• •All methods public static
• •Class should be public with sharing with a private constructor to prevent instantiation
• •Group related utilities (e.g., StringUtil, DateUtil, CollectionUtil)
• •Every method must be side-effect-free (no DML, no SOQL)

Interfaces

• •Read and follow: templates/interface.cls
• •Define the contract clearly with ApexDoc on every method signature
• •Use meaningful names that describe the capability: INotificationService, IRetryable

Abstract Classes

• •Read and follow: templates/abstract.cls
• •Provide default implementations for common behavior
• •Mark extension points as protected virtual or protected abstract
• •Include a concrete example in the ApexDoc showing how to extend

Custom Exceptions

• •Read and follow: templates/exception.cls
• •Extend Exception
• •Keep them simple — Apex exceptions don't support custom constructors well
• •Name them descriptively: AccountServiceException, IntegrationTimeoutException

Generation Workflow

1. •Determine the class type from the user's request
2. •Read the corresponding template from templates/
3. •Read relevant examples from examples/ if the class type has one
4. •Apply the user's requirements to the template pattern
5. •Generate the .cls file with full ApexDoc
6. •Generate the .cls-meta.xml file
7. •Present both files to the user
8. •Include a brief note on design decisions if any non-obvious choices were made

Anti-Patterns to Avoid

• •❌ SOQL or DML inside loops
• •❌ Hardcoded IDs or record type names (use Schema.SObjectType or Custom Metadata)
• •❌ God classes that mix query + logic + DML
• •❌ public fields on service classes
• •❌ Returning null from methods that should return collections
• •❌ Generic catch (Exception e) without re-throwing or meaningful handling
• •❌ Business logic in Batch start() methods
• •❌ Tight coupling between classes — use interfaces for extensibility
• •❌ Magic strings or numbers
• •❌ Methods longer than ~40 lines — break them into private helpers