/platform-environment-validate

name: platform-environment-validate
description: "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)."
allowed-tools:
  - Bash
  - Read

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 instanc