AI-assisted Apex with Glade

Use this prompt for any Apex feature, bug fix, or refactor. It makes the AI agent work from the same local loop a developer would use: test first, run Glade, fix the smallest source slice, and prove the same command passes.

Where to put it

Paste the long prompt into a global skill, repository instruction file, or agent memory. Good places include a user-level AI skill, a project AGENTS.md, CLAUDE.md, or similar repository instruction file.

Use the prompt at the global level when most AI work touches Apex. Use it at the repository level when only one Salesforce DX project needs the rule. Keep project-specific commands outside the global prompt unless every project uses the same test naming and branch shape.

Global skill prompt

Use Glade from the Salesforce DX project root when developing Apex.

This applies to any Apex feature, bug fix, refactor, trigger, service class,
selector, batch, queueable, schedulable, Visualforce controller, LWC Apex
controller, or Apex test change.

Default workflow:

1. Inspect the requested change and the existing Apex tests.
2. Run local setup checks:
   mkdir -p reports
   glade doctor --project .
   glade config validate --project .
3. For a bug fix or new behavior, write the smallest failing Apex test first.
   - Do not edit production Apex until a Glade test fails for the expected reason.
   - Prefer one focused test method that names the behavior.
   - Use existing test factories and fixtures when they exist.
   - For a behavior-preserving refactor, first record a passing baseline instead.
4. Prove the red step (or refactor baseline) with the narrowest Glade command:
   glade test --project . --class <TestClass> --method <TestMethod> --json --no-progress
5. Quote the exact command and the failing diagnostic for a bug or new behavior;
   for a refactor, record the named passing baseline instead.
6. Make the smallest production change that should pass that test.
7. Rerun the same focused Glade test until it passes.
8. Run source checks:
   glade check --project . --format json --output reports/glade-check.json --no-progress
9. Run affected tests before claiming success:
   glade test changed --project . --since origin/main --json --no-progress > reports/glade-test-changed.json
10. Summarize the proof with commands, exit status, and the changed Apex files.

Rules:
- Use Glade before a Salesforce deploy or org validation pass.
- Do not connect to a Salesforce org for the first pass unless the user asks.
- Check what Glade runs locally before treating unsupported platform services as bugs.
- If Glade reports an unsupported feature, say so and keep Salesforce as the validation gate.
- Do not rewrite valid Salesforce behavior to satisfy a Glade limitation. Report the mismatch and use authorized Salesforce validation for that path.
- Salesforce remains the validation gate for live auth, hosted service engines, deploy/retrieve, exact Lightning Experience behavior, Streaming, Pub/Sub, GraphQL, and exact production governor accounting.
- Do not invent one-off local escape hatches. Let the failing test and Glade diagnostic drive the change.

Task prompt

Use this shorter prompt when you want the agent to apply the global rule to one piece of work:

Implement this Apex change with TDD and Glade.

Start from the Salesforce DX project root. For a bug or new behavior, write the smallest
failing Apex test first. For a behavior-preserving refactor, retain a passing baseline.
Check that baseline with:

glade test --project . --class <TestClass> --method <TestMethod> --json --no-progress

Then make the smallest source change, rerun the same focused test, run:

mkdir -p reports
glade check --project . --format json --output reports/glade-check.json --no-progress
glade test changed --project . --since origin/main --json --no-progress > reports/glade-test-changed.json

Report the exact commands and diagnostics. Do not claim success until the Glade
commands pass or you have named the unsupported Salesforce boundary.
Do not rewrite valid Salesforce behavior to satisfy a Glade limitation.

How it should behave

Local test isolation is not an OS security sandbox. Core local checks do not upload source to a Glade service, but custom code, plugins, imports, and an external AI provider may use the network. Review what you authorize and do not send proprietary source or credentials to a provider without permission.

The agent should return the test it added or changed, the initial failing command for a bug or new behavior (or passing baseline for a refactor), the production change, and the commands that passed at the end.

For a bug fix, the first failing test should reproduce the bug. For a new feature, the first failing test should describe the smallest useful behavior. For a refactor, the first Glade pass should preserve behavior before source movement starts, then affected tests should run after the movement.

Use the affected tests, local testing, Apex language compatibility, and support map guides when the agent needs a narrower test selector, the reserved-identifier contract, or a clear local runtime boundary.