SfSkills — Salesforce AI Skill Library

The universal Salesforce knowledge layer for AI coding assistants.

Drop this into Claude Code, Cursor, Aider, Windsurf, or any AI tool and get role-accurate, source-grounded Salesforce guidance — for every role, every cloud, every task.

978 skills · 75 agents · shared Apex/LWC/Flow templates · golden evals · live-org MCP server. 1097+ skills planned across 5 roles × 16 clouds. Live progress: docs/queue-progress.md.

What Makes This Different

Three layers that turn generic LLMs into Salesforce-literate agents:

1. Skills (skills/<domain>/<skill>/) — 978 structured guides. Every skill carries source-grounded instructions, code examples, gotchas, WAF mapping, and a per-skill list of LLM anti-patterns the model must refuse to produce.
2. Shared canon — One set of reusable building blocks the skills all point at, so the AI never reinvents them:
   • templates/ → TriggerHandler, ApplicationLogger, SecurityUtils, HttpClient, TestDataFactory, LWC skeleton, Flow fault paths, Agentforce actions.
   • standards/decision-trees/ → Routing for automation, async, integration, and sharing decisions — agents consult these before writing code.
   • evals/ → Golden P0 cases for flagship skills. Output quality is testable, not vibes-based.
3. Live-org MCP server (mcp/sfskills-mcp/) — 38 tools across skill / agent / template / decision-tree search + retrieval, live-org metadata + SOQL (Apex classes / triggers, LWC bundles, custom fields, objects, validation rules, permission sets, named credentials, approvals, orgs), 5 probes (Apex refs, Flow refs, matching rules, permset shape, automation graph) with progress notifications, task-to-agent routing (suggest_agent), health diagnostic, atomic envelope persistence. Plus 68 MCP prompts (every commands/*.md wrapper — /refactor-apex, /audit-router, …) and 5 MCP resource shapes (sfskills://catalog, sfskills://skill/{id}, sfskills://agent/{name}, sfskills://decision-tree/{name}, sfskills://template/{path}). Every tool carries honest annotations (readOnlyHint, destructiveHint, openWorldHint, idempotentHint) so MCP-aware clients can auto-approve safely. An AI agent reads this library and asks your actual org "does this already exist?" via your sf CLI auth. No secrets handled in-process. Jump to setup ↓

Who This Is For

Supported AI Tools

Live-org validation (Wave 9)

Every probe, agent, and skill in this repo is verified against a live Salesforce org via three automated harnesses:

• Layer 1 — Probe SOQL correctness (every SOQL query executes against a real org)
• Layer 2 — Agent smoke tests (42/42 runtime agents pass structural + dependency checks)
• Layer 3 — Skill factuality sampling (200-skill sample, 0 fabricated field references)

Re-runnable on any dev/scratch org:

python3 scripts/validate_probes_against_org.py --target-org <alias>
python3 scripts/smoke_test_agents.py --target-org <alias>
python3 scripts/validate_skill_factuality.py --target-org <alias> --sample 200

Reports land in docs/validation/. See docs/validation/README.md for what each layer catches.

Installing just one agent (not the whole library)

If you only need a specific agent in another project (e.g. user-access-diff):

python3 scripts/export_agent_bundle.py --agent user-access-diff --rewrite-paths --out ./my-export
# Drop ./my-export/user-access-diff/ into .cursor/agents/ or .claude/agents/

The bundle carries the AGENT.md plus every probe, skill, template, and shared doc it needs — with paths auto-rewritten to resolve inside the bundle. See docs/installing-single-agents.md.

5-Minute Setup

# 1. Clone
git clone https://github.com/PranavNagrecha/AwesomeSalesforceSkills.git
cd AwesomeSalesforceSkills

# 2. Install dependencies
python3 -m pip install -r requirements.txt

# 3a. Claude Code — works automatically via CLAUDE.md. Just open the repo.

# 3b. Cursor / Windsurf / Aider / Augment — export and copy:
python3 scripts/export_skills.py --platform cursor   # or windsurf | aider | augment | all
cp -r exports/cursor/.cursor/ /path/to/your/sf-project/

# 4. Search what's in the library
python3 scripts/search_knowledge.py "trigger recursion"
python3 scripts/search_knowledge.py "permission sets" --domain admin

Want your AI to see your actual org too? Install the MCP server below.

What a Skill Looks Like

Every skill is a structured guide an AI follows end-to-end. Example for apex/trigger-framework:

trigger-framework/
├── SKILL.md              ← the AI's instructions: modes, gather questions, step-by-step
├── references/
│   ├── examples.md       ← real code examples with test classes
│   ├── gotchas.md        ← non-obvious platform behaviors
│   └── well-architected.md  ← WAF pillar mapping + official sources
├── templates/
│   └── trigger-framework-template.md  ← deployable scaffold
└── scripts/
    └── check_trigger.py  ← local validator (stdlib only, no pip)

Skills are plain markdown. They work in any AI tool that can read a file.

Shared Templates

Canonical, copy-pasteable Salesforce building blocks live under templates/:

templates/
├── apex/              TriggerHandler, TriggerControl, BaseDomain/Service/Selector,
│                      ApplicationLogger, SecurityUtils, HttpClient
├── apex/tests/        TestDataFactory, TestRecordBuilder, MockHttpResponseGenerator,
│                      TestUserFactory, BulkTestPattern
├── apex/cmdt/         Trigger_Setting__mdt, Logger_Setting__mdt
├── apex/custom_objects/  Application_Log__c (+ fields)
├── lwc/               jest.config.js, component-skeleton/ (bundle + tests),
│                      patterns/ (wire, imperative, LDS form)
├── flow/              RecordTriggered_Skeleton, FaultPath_Template, Subflow_Pattern
└── agentforce/        AgentSkeleton.json, AgentActionSkeleton.cls, AgentTopic_Template.md

Every skill in this repo references these canonical files instead of re-inventing scaffolds. AI tools reading the skills get one consistent implementation of each Salesforce idiom — testable, version-pinned, and deployable.

Drop the files you need into your SFDX project under force-app/main/default/ and rename. See templates/README.md for the layout and dependency order.

Covered Skills

See the full catalog: docs/SKILLS.md

Using Skills in Practice

Ask your AI to use a specific skill

"Use the trigger-framework skill to build an Account trigger handler"
"Follow the batch-apex-patterns skill to review this batch class"
"Apply the permission-set-architecture skill to this org assessment"

Let the AI find the right skill

"My trigger is firing twice on the same record update"
→ AI searches, finds recursive-trigger-prevention skill, applies it

"Why can't my user see the field even though they have object access?"
→ AI searches, finds soql-security + permission-set-architecture, applies both

Search skills yourself

python3 scripts/search_knowledge.py "my flow is hitting limits"
python3 scripts/search_knowledge.py "callout timeout" --domain integration
python3 scripts/search_knowledge.py "data skew performance" --domain data

Request a Missing Skill

Three ways:

Run the /request-skill command — Ask the AI to follow commands/request-skill.md. It asks 4 questions, checks existing coverage, and adds an entry to BACKLOG.yaml.

Add directly to the queue — Append an entry to BACKLOG.yaml:

- id: your-skill-name
  status: TODO
  skill: your-skill-name
  domain: <domain>
  summary: "What it does. NOT for what it doesn't cover."
  history: []

Open a GitHub issue — Title: [Skill Request] <domain>: <skill-name>. Describe the use case, the role, and which cloud it applies to.

Contribute a Skill

See CONTRIBUTING.md for the full workflow.

The short version:

# 1. Check it doesn't already exist (lexical + semantic)
python3 scripts/search_knowledge.py "<your topic>"
python3 scripts/audit_duplicates.py --domain <domain>     # full pairwise

# 2. Scaffold it (--strict refuses to create near-duplicates)
python3 scripts/new_skill.py <domain> <skill-name> --strict

# 3. Fill every TODO in the generated files
#    — Reference templates/ for any Apex/LWC/Flow scaffolds (don't inline your own)
#    — Cite standards/decision-trees/ if your skill recommends a technology

# 4. Sync and validate
python3 scripts/skill_sync.py --skill skills/<domain>/<skill-name>
python3 scripts/validate_repo.py
python3 evals/scripts/run_evals.py --structure          # if you added a golden eval

# 5. Open a PR

Every skill must pass three gates before merging:

• Structural gate — validate_repo.py exits 0. The full list of gates with file:line links lives in standards/validation-gates.md (generated).
• Canon gate — scaffolds reference templates/; technology choices cite standards/decision-trees/; any @InvocableMethod or agent action uses templates/agentforce/AgentActionSkeleton.cls as the base shape
• Quality gate — standards/skill-content-contract.md (source grounding, content depth, agent usability, contradiction check, freshness) plus references/llm-anti-patterns.md populated with real failure modes for that skill. The semantic-duplicate check fires as a WARN; review docs/reports/duplicate-candidates.md before merging if the WARN names your new skill.

Flagship skills additionally carry a golden eval under evals/golden/ with 3+ P0 cases.

Update an Existing Skill

Found something wrong? Source changed? Platform behavior updated?

# Edit the skill files
# Then:
python3 scripts/skill_sync.py --skill skills/<domain>/<skill-name>
python3 scripts/validate_repo.py
# Open a PR with what changed and why

Or tell the AI:

"The trigger-framework skill is missing guidance for the new Flow-triggered Apex pattern in Spring '25"

The Currency Monitor agent will handle it if you flag it during a release cycle.

Standards and Rules

Agents: Build-time vs Run-time

This repo ships two classes of agents, both as instruction files (agents/<name>/AGENT.md) that any agentic AI can follow (Claude Code, Codex, Cursor, Windsurf, or any MCP client).

The contract every agent follows: agents/_shared/AGENT_CONTRACT.md. The full roster: agents/_shared/RUNTIME_VS_BUILD.md.

Run-time Agents (the ones you call)

Each agent takes concrete inputs, composes skills + templates + decision-trees + (optional) live-org probes, and returns a PR-ready report or plan. Three invocation modes — all fire the same AGENT.md:

1. Slash command — ask your AI to follow commands/<name>.md
2. Direct read — point any AI at agents/<name>/AGENT.md
3. MCP — call get_agent(name) on the SfSkills MCP server; the server returns the instructions for your model to execute

Every run-time agent follows the same 8-section contract (including a mandatory Process Observations block that flags healthy, concerning, and ambiguous patterns in the org while producing the output), cites every skill / template / decision-tree it used, and never writes to your org.

Developer + architecture tier (11)

Admin accelerators — Tier 1 (7)

Workflow Rule / Process Builder / Approval Process migration is now handled by the consolidated automation-migration-router — see /automation-migration-router.

Strategic — Tier 2 (9)

Vertical + governance — Tier 3 (10)

Full list + source-skill map: agents/_shared/SKILL_MAP.md.

How the library itself gets built

The build-time agents live in the same agents/ tree. They're the skill factory:

BACKLOG.yaml                     what needs to be built (machine-readable)
      │
      ▼
agents/orchestrator/             routes TODOs to the right builder
      │
      ├── agents/task-mapper/           researches Cloud × Role task universes
      ├── agents/content-researcher/    grounds every claim in Tier 1–3 sources
      ├── agents/admin-skill-builder/   builds Admin + BA skills
      ├── agents/dev-skill-builder/     builds Apex / LWC / Flow / Integration / DevOps
      ├── agents/data-skill-builder/    builds data modeling, migration, SOQL
      ├── agents/architect-skill-builder/  builds solution design + WAF review
      ├── agents/code-reviewer/         canon-gate review (templates, decision-trees, evals)
      ├── agents/validator/             structural + quality gates before every commit
      ├── agents/currency-monitor/      flags stale skills after each SF release
      ├── agents/org-assessor/          audits a target org against the library
      └── agents/release-planner/       assembles release notes from skill deltas

Operators drive the system via slash commands under commands/ (invoke by asking the AI to "follow commands/<name>.md"):

Source Hierarchy

Every claim in every skill is grounded against a 4-tier trust ladder. When sources disagree, the lower tier loses. Defined in standards/source-hierarchy.md.

• Tier 1 — Official Salesforce docs (ground truth)
• Tier 2 — Trailhead, Salesforce Architects blog, Salesforce Ben
• Tier 3 — Andy in the Cloud, Apex Hours, Salesforce Stack Exchange
• Tier 4 — Community signal (context only, never the basis for a claim)

Roadmap

Shipped in v1:

• [x] 978 skills across Admin, Apex, LWC, Flow, OmniStudio, Agentforce, Security, Integration, Data, Architect, DevOps
• [x] Shared templates (Apex handler framework, logger, security utils, HTTP client, test factories, LWC skeleton, Flow fault paths, Agentforce action shell)
• [x] Decision trees for automation, async, integration, and sharing selection
• [x] Golden evals for 10 flagship skills (30 P0 cases)
• [x] MCP server exposing the library + live-org lookups

In flight toward v2 (1119+ planned):

• [ ] Per-cloud tagging across every skill (clouds: [...] in registry)
• [ ] Expand golden evals from 10 → 40 flagship skills
• [ ] Role-specific landing pages (Admin, BA, Developer, Data, Architect)
• [ ] Deeper cloud coverage: Sales, Service, Experience, Marketing, Revenue (CPQ), Field Service, Health, FSC, Nonprofit, Commerce, CRM Analytics, MuleSoft
• [ ] Currency monitor — automated staleness flagging after each Salesforce release

Live queue: BACKLOG.yaml (machine-readable) · docs/queue-progress.md (generated dashboard) · MASTER_QUEUE.md (intro + agent workflow)

Maintainer

Pranav Nagrecha — Salesforce Technical Architect

Version: 1.0.0 | Last Updated: April 2026

Issues → GitHub Issues Skill requests → /request-skill in Claude Code or open an issue with [Skill Request] prefix

MCP Server (live-org context)

The mcp/sfskills-mcp/ package exposes this library and your real Salesforce org to any MCP-capable AI tool so the agent can answer "does this trigger framework already exist in my org?" without asking you.

Fifteen tools, all read-only:

Install

# From the repo root
python3 -m pip install -e mcp/sfskills-mcp

# Authenticate via the Salesforce CLI (no secrets enter the MCP server)
sf org login web --alias my-dev
sf config set target-org=my-dev

Connect your AI tool

The server speaks the standard MCP stdio transport, so it drops into every modern AI coding tool with a single snippet. Quick start for Cursor (~/.cursor/mcp.json or project-scoped .cursor/mcp.json):

{
  "mcpServers": {
    "sfskills": {
      "command": "python3",
      "args": ["-m", "sfskills_mcp"],
      "env": { "SFSKILLS_REPO_ROOT": "/absolute/path/to/AwesomeSalesforceSkills" }
    }
  }
}

→ Full setup guide for every MCP-capable AI tool — Claude Code, Claude Desktop, Cursor, Windsurf, Zed, VS Code (Copilot Agent), Cline, Continue, Sourcegraph Cody, OpenAI Codex CLI, Gemini CLI, Goose, LibreChat, Open WebUI, JetBrains AI Assistant, 5ire, and the generic stdio transport — with per-client pitfalls, verification steps (MCP Inspector), troubleshooting, and the security model.

See mcp/sfskills-mcp/README.md for tool schemas, validate_against_org probe routing, and design notes.