The Best Salesforce CLAUDE.md Template (Copy-Paste Ready)

Every time you start a new Claude Code session, Claude reads your CLAUDE.md file before doing anything else. For most projects, a generic CLAUDE.md is enough. For Salesforce, it is absolutely essential — and the generic templates floating around online won't cut it.

This post gives you a complete, production-ready Salesforce CLAUDE.md template you can drop into any project right now, plus a breakdown of why each section matters.

What Is CLAUDE.md and Why Does Salesforce Need a Special One?

CLAUDE.md is a Markdown file in your project root that Claude Code reads at the start of every session. It acts as a persistent briefing — telling Claude who you are, what stack you're on, and how to behave in your codebase.

Salesforce development is uniquely complex: custom API names, governor limits, deployment pipelines, managed package namespaces, and org-specific quirks that no AI knows by default. Without a CLAUDE.md tailored to Salesforce, you will spend the first 10 minutes of every session re-explaining your org. With a good one, Claude starts writing production-quality Apex and SOQL from line one.

The Complete Salesforce CLAUDE.md Template

Copy this into a file called CLAUDE.md in the root of your Salesforce project. Fill in the bracketed sections for your org:

# Salesforce Project — Claude Code Context

## Org Overview
- Org Type: [Production / Developer / Sandbox / Scratch]
- API Version: [e.g. 61.0]
- Edition: [Enterprise / Unlimited / Professional]
- Industry: [e.g. Manufacturing, Healthcare, Non-Profit]

## Deployment
- Method: [SFDX / ANT / Change Sets]
- Pipeline: [GitHub Actions / Bitbucket / Jenkins / None]
- Target sandbox alias: [e.g. dev, qa, uat]

## Apex Conventions
- Trigger pattern: [One trigger per object + handler class / fflib / custom]
- Naming: [e.g. AccountTrigger.trigger, AccountTriggerHandler.cls]
- Test class suffix: [e.g. _Test or Test suffix]
- Always bulkify: yes — all trigger logic must handle 200+ records
- Governor limit awareness: always check SOQL inside loops

## Managed Packages Installed
- [e.g. Conga Composer (apttus), DocuSign (dfsle), Copado (copado)]

## Custom Object Naming Conventions
- All custom objects use __c suffix (standard Salesforce convention)
- Our namespace prefix: [e.g. myco__ or none]
- Junction objects follow pattern: Object1Object2__c

## Key Custom Objects (most used)
- [List your top 5-10 custom objects and their purpose here]
- Example: Service_Contract__c — customer service agreements, linked to Account

## Integrations
- [List external systems integrated: e.g. SAP, HubSpot, Stripe, custom ERP]

## Do Not Do
- Never use SOQL inside for loops
- Never hardcode IDs (use custom metadata or custom settings)
- Never deploy directly to production — always go sandbox → UAT → prod

Section-by-Section Breakdown

Org Overview

The org type and edition matter more than you'd think. Claude handles Production and Scratch orgs very differently — Scratch orgs allow risky operations that would be catastrophic in Production. The edition tells Claude which features are available (e.g., Process Builder isn't in Professional Edition).

Apex Conventions

This is the highest-impact section. If your team uses the fflib framework, Claude needs to know — otherwise it'll generate vanilla trigger handlers that break your architecture. Specifying your test class naming convention means Claude generates test classes that match your existing structure from day one.

Managed Packages

Without knowing your installed packages, Claude will hallucinate field names from managed packages — it'll write DocuSign__Status__c instead of the real dfsle__Status__c namespace prefix. Listing your packages eliminates an entire category of hallucination.

Do Not Do

The "Do Not Do" section is a hard guardrail. Claude takes these seriously — listing SOQL-in-loops as a forbidden pattern will prevent governor limit violations in generated code, even for junior team members who don't know to check.

Keeping Your CLAUDE.md Up to Date

A CLAUDE.md is only as useful as it is current. The most common mistake is writing it once and forgetting it. Add a note to your sprint retrospective to update the custom objects section whenever a new object goes live. Keep it in version control so updates are tracked.

A good rule of thumb: your CLAUDE.md should be the first file a new developer reads to understand the project. If it would confuse a new hire, it will confuse Claude too.

CLAUDE.md vs AiOS: Do You Need Both?

The CLAUDE.md template above is a great starting point — but it has one big limitation: you have to maintain it manually. The Salesforce AI OS (AiOS) skill automates all of this. It crawls your org's metadata and generates a structured, always-current knowledge base that Claude reads automatically.

Use the template if you want something working today with zero setup. Use AiOS if you want it to stay accurate as your org evolves. The two are complementary — AiOS generates a richer version of everything in this template, plus the full field-level detail that would be impractical to write by hand.

Get the Full AiOS Setup

The Salesforce AI OS is free, open source, and installs in under 60 seconds with $ claude /aios-setup. It automatically generates a CLAUDE.md-style knowledge base from your live org metadata — custom objects, fields, flows, Apex classes, and more. Sign up at radix2tech.com/salesforce-ai-os to get the GitHub skill link sent to your inbox.