
platform-environment-validate
Validate and configure the local Salesforce development environment. Runs a prerequisite scan across required tools with per-tool status and offers to install or update missing items. Use when the user asks to 'check my setup', 'validate tools', 'verify prerequisites', 'am I set up correctly', or reports a tool is missing or not working. DO NOT TRIGGER for org auth (/salesforce-development:login), deployment problems (platform-metadata-deploy), or status checks (/salesforce-development:status).
- Installs
- 2.7K
- Last 24h
- +14
- Trending rank
- #7301
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/forcedotcom/sf-skills --skill platform-environment-validate- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads platform-environment-validate automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Validating: Salesforce Development Environment
Validate all required prerequisites and surface a clear, actionable status report. This skill is on-demand — it does not run automatically on session start. Run it explicitly to check or repair your local setup.
Phase 1: Prerequisite Scan
Run the tool check:
${CLAUDE_PLUGIN_ROOT}/scripts/sf-context check-tools
The output is a JSON object with a tools array (plus a diagnostic block on any critical failure).
The banner is painted for you — do not reproduce it. When check-tools runs, the plugin paints the framed "Ready to build on Salesforce?" banner deterministically on the visible channel — one status row per tool, the footer verdict, and the wayfinding footer — exactly like the SessionStart banner. It is a Tier-1 surface: read the JSON for your own understanding, but do NOT reproduce, redraw, or re-render the banner. Add only a short read of what the result means for the user, then go to Phase 2.
The painted banner looks like this (illustrative — the version/message text in each row comes straight from the JSON: version for 🟢, message + fix hint for 🟡/🔴, the note for ℹ️; the values below show the style, not fixed strings):
──────────────────────────────────────────────────────────────
Ready to build on Salesforce? checking your toolchain…
──────────────────────────────────────────────────────────────
🟢 Salesforce CLI v2.144.6
🟢 Code Analyzer v5.14.0 · JIT, auto-installs on first use
🟢 Node.js v22.11.0 LTS
🟢 NPM v10.9.0
🟢 Git v2.50.1
🟢 Salesforce MCP (config) .mcp.json + proxy present
🟢 Salesforce MCP (endpoint) org instance reachable
ℹ️ Salesforce MCP (process) confirm with /mcp or /doctor
🟢 Source Tracking enabled
──────────────────────────────────────────────────────────────
✓ toolchain ready (skill: platform-environment-validate)
Each row's status dot carries the state — 🔴 critical (missing or below minimum — Salesforce development cannot proceed), 🟡 warn (installed but outdated, non-LTS, or misconfigured), 🟢 ok, ℹ️ info (a contextual note that can't be auto-verified, e.g. MCP process health) — and the framed footer gives the verdict plus the single most relevant Next: step. The JSON status field is the source of truth per tool; use these states when you write your short read.
If the banner did not paint (an older Claude Code build, or a paint fallback), do not hand-render it from the JSON. Print it with the deterministic renderer instead:
${CLAUDE_PLUGIN_ROOT}/scripts/sf-context readiness-banner
This reads the same scan result check-tools just recorded and prints the identical framed banner — rows in fixed order, the footer verdict, and the "you don't memorize commands here" wayfinding footer with its Next: step — so ordering, padding, counts, and next-step selection are decided once in the script, never re-derived by hand. The check-tools JSON stays the authoritative, machine-readable result.
Deterministic results — do NOT override a failure: the JSON report
is the authoritative, machine-readable result. If a tool reports 🔴/🟡, report it
as-is. Do not re-run the tool a different way (PowerShell, a raw shell probe,
a different command) and then present the result as 🟢 — a fallback that happens
to find the tool does not mean the deterministic check passed. A failed check
must stay failed until that same check-tools check passes. When the report
includes a diagnostic block (attached on any critical failure), surface it: it
carries the platform, active shell, working directory, plugin root, and the
resolved executable paths — the fastest way to see why a tool didn't resolve
(e.g. a Windows sf.cmd not on PATH). The diagnostic is secret-free by design;
never add tokens or org auth to it.
MCP is reported as three distinct rows — never inferred from one another:
Salesforce MCP (config) (is .mcp.json + the sf-mcp-proxy.bundled.js present?),
Salesforce MCP (endpoint) (is the platform endpoint reachable?), and
Salesforce MCP (process) (is the MCP process actually healthy?). The process row
is reported as ℹ️ informational (not a warning) — this script cannot see the
MCP subprocess that Claude Code owns, so a green config/endpoint must not be
presented as a working MCP. Confirm process health with /mcp or /doctor. The
endpoint row probes the org instance URL as a connectivity proxy, not the
platform-MCP endpoint itself.
Tools Checked
| Tool | Minimum Requirement | Verification |
|---|---|---|
| Salesforce CLI | Present, and on the latest release | sf --version (🟡 when an update is available) |
| Code Analyzer plugin | Installed or JIT-registered | sf plugins inspect @salesforce/plugin-code-analyzer, falling back to the CLI's oclif.jitPlugins registry |
| Node.js | >= 18 (even/LTS) | node --version |
| NPM | >= 3.10 | npm --version |
| Git | Must be present | git --version |
| Salesforce MCP (config) | .mcp.json configured + proxy bundle present | Plugin root .mcp.json check + sf-mcp-proxy.bundled.js presence |
| Salesforce MCP (endpoint) | Org instance URL reachable (connectivity proxy) | HTTP probe of org instance URL |
| Salesforce MCP (process) | ℹ️ informational — not verifiable here | Confirm with /mcp or /doctor |
| Source Tracking | Enabled for connected org | sf project deploy preview |
All external tools (sf, npm, node, git) are launched through a single
cross-platform resolver: shutil.which (PATHEXT-aware) finds the tool,
and a Windows .cmd/.bat shim (sf.cmd, npm.cmd) is invoked via a
COMSPEC-wrapped argv array — never a shell string — so this scan and
/salesforce-development:org detect sf/npm/the default org correctly on
Windows, macOS, and Linux.
Code Analyzer is a JIT plugin — registered ≠ installed. The Salesforce CLI
declares @salesforce/plugin-code-analyzer as a "just-in-time" (JIT) plugin: it
is only physically installed the first time a sf code-analyzer command runs.
Until then, sf plugins inspect fails for it even though it is fully
available to the user. The check therefore treats JIT registration as success —
if inspect returns no version, it falls back to the CLI's own
oclif.jitPlugins registry (read from the root entry of sf plugins --json) and
reports 🟢 with the pinned version and a note that it auto-installs on first use.
Only a plugin that is neither installed nor JIT-registered is 🔴 critical.
Phase 2: Install / Update
If all green: Confirm setup is complete. The user is ready to develop.
If warnings or critical items exist: Present the user with options:
Some tools need attention. What would you like to do?
[1] Fix all items
[2] Choose which items to fix
[3] Skip for now
For each tool the user wants to fix, provide the correct install/update command for their OS. Do not run install commands automatically — show the command and ask the user to confirm before running it.
Install / Update Commands by Tool
Salesforce CLI — not installed:
# macOS/Linux (npm)
npm install --global @salesforce/cli
# macOS (Homebrew)
brew install sf
Salesforce CLI — update:
sf update
Code Analyzer plugin — not installed:
sf plugins install @salesforce/plugin-code-analyzer
Code Analyzer plugin — update:
sf plugins update @salesforce/plugin-code-analyzer
Node.js — not installed or below minimum:
# macOS (nvm — recommended, installs LTS)
nvm install --lts && nvm use --lts
# macOS (Homebrew)
brew install node
# Windows — download from https://nodejs.org (LTS version)
NPM — update:
npm install --global npm@latest
Git — not installed:
# macOS (Xcode CLT)
xcode-select --install
# macOS (Homebrew)
brew install git
# Windows — download from https://git-scm.com
Source Tracking — not enabled:
sf org enable tracking --target-org <alias>
Salesforce MCP — misconfigured: If .mcp.json is missing or empty, reload the plugin:
/reload-plugins
Important Notes
- After installing a tool that modifies PATH (Node.js, SF CLI), the user may need to exit and restart Claude Code for the change to take effect.
- Source Tracking requires a connected org — if no org is configured, prompt to run
/salesforce-development:loginfirst. - For org authentication issues (expired session, wrong org, INVALID_SESSION_ID), run
/salesforce-development:logininstead of this skill. - SF CLI outdated → 🟡 in the readiness scan: readiness means latest. When the CLI's cached update check reports a newer release,
check-toolsreports the Salesforce CLI as 🟡 (installed but outdated) with the correct update command, rather than 🟢. Unlike the session-start notice below, this warning ignores the per-version no-nag gate — an explicit readiness scan always reports the factual state — but it still honors the hard opt-outSFDX_SKIP_CLI_UPDATE_CHECK=1. - SF CLI update notice at session start: when the CLI reports an available update, the
sf-context detectSessionStart hook surfaces it once and asks the agent to offer the update (sf update, ornpm install --global @salesforce/cli@latestfor npm-global installs). Declining or a failed update records a per-version no-nag gate (.sf/sf-cli-update-state.json) so the same version won't nag again, but a newer release will re-prompt. SetSFDX_SKIP_CLI_UPDATE_CHECK=1to disable the check entirely.
FAQ
What does the platform-environment-validate skill do?
Validate and configure the local Salesforce development environment. Runs a prerequisite scan across required tools with per-tool status and offers to install or update missing items. Use when the user asks to 'check my setup', 'validate tools', 'verify prerequisites', 'am I set up correctly', or reports a tool is missing or not working. DO NOT TRIGGER for org auth (/salesforce-development:login), deployment problems (platform-metadata-deploy), or status checks (/salesforce-development:status).
How do I install platform-environment-validate?
Run npx skills add https://github.com/forcedotcom/sf-skills --skill platform-environment-validate in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/platform-environment-validate/ (personal) or .claude/skills/platform-environment-validate/ (project).
Which AI agents can use platform-environment-validate?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is platform-environment-validate safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains platform-environment-validate?
It is published by forcedotcom in forcedotcom/sf-skills. It has 2,677 recorded installs.
More from forcedotcom/sf-skills
platform-apex-generate
forcedotcom/sf-skills
Primary Apex authoring skill for class generation, refactoring, and review. ALWAYS ACTIVATE when the user mentions Apex, .cls, triggers, or asks to create/refactor a class (service, selector, domain, batch, queueable, schedulable, invocable, DTO, utility, interface, abstract, exception, REST resource). Use this skill for requests involving SObject CRUD, mapping collections, fetching related records, scheduled jobs, batch jobs, trigger design, @AuraEnabled controllers, @RestResource endpoints, custom REST APIs, or code review of existing Apex.
platform-apex-test-generate
forcedotcom/sf-skills
Use to generate and validate Apex test classes with TestDataFactory patterns, bulk testing (251+ records), mocking, assertions, and disciplined test-fix loops. Use when creating Apex test classes (for triggers, services, controllers, batch jobs, queueables, and callouts), improving coverage, debugging or fixing failing Apex tests, or running test/coverage analysis. Triggers on Test.cls files, sf apex run test, coverage reports. Do NOT trigger for production Apex (use platform-apex-generate) or Jest/LWC tests.
platform-apex-test-run
forcedotcom/sf-skills
Apex test execution, coverage analysis, and test-fix loops with 120-point scoring. Use when the user runs Apex tests, checks code coverage, fixes failing tests, or touches Test.cls / Test.cls files. DO NOT TRIGGER when writing Apex production code (use platform-apex-generate), Agentforce agent testing (use agentforce-test), or Jest/LWC tests (use experience-lwc-generate).
platform-apex-logs-debug
forcedotcom/sf-skills
Salesforce debug log analysis and troubleshooting with 100-point scoring. TRIGGER when: user analyzes debug logs, hits governor limits, reads stack traces, or touches .log files from Salesforce orgs. DO NOT TRIGGER when: running Apex tests (use platform-apex-test-run), generating or fixing Apex code (use platform-apex-generate), or Agentforce session tracing (use agentforce-observe).
platform-soql-query
forcedotcom/sf-skills
Use when the user needs SOQL/SOSL authoring or optimization: natural-language-to-query generation, relationship queries, aggregates, query-plan/selectivity analysis, and performance or safety improvements. TRIGGER when the user writes, optimizes, or debugs SOQL/SOSL, touches .soql files, or asks about relationship queries, aggregates, or query performance. DO NOT TRIGGER for bulk data operations (use platform-data-manage), Apex DML logic (use platform-apex-generate), or report/dashboard queries.
platform-metadata-deploy
forcedotcom/sf-skills
Salesforce DevOps automation using sf CLI v2. TRIGGER when: user deploys metadata, validates a deploy or does a dry-run, deploys to a Production org, quick-deploys a validated job ID, ships/promotes to prod, creates/manages scratch orgs or sandboxes, sets up CI/CD pipelines, or troubleshoots deployment errors with sf project deploy. DO NOT TRIGGER when: writing Apex code, building LWC components (use experience-lwc-generate), creating metadata definitions (use platform-custom-object-generate), deleting metadata from an org (use platform-destructive-deploy), or querying org data (use platform-data-manage).
Popular devops & cloud skills
microsoft-foundry
microsoft/azure-skills
Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure
azure-diagnostics
microsoft/azure-skills
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
azure-prepare
microsoft/azure-skills
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
azure-ai
microsoft/azure-skills
Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.
azure-deploy
microsoft/azure-skills
Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.
azure-validate
microsoft/azure-skills
Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.