Agent Skills › forcedotcom/sf-skills › platform-deploy-validate

platform-deploy-validate

GitHub

在部署 Salesforce 元数据前执行服务器端验证，区分生产与沙箱环境。生产环境生成快速部署 ID，沙箱执行干运行，并处理失败排查，确保部署安全。

plugins/builder/salesforce-development/skills/platform-deploy-validate/SKILL.md forcedotcom/sf-skills

Trigger Scenarios

用户请求验证部署执行干运行检查针对生产组织进行任何部署操作前的检查

Install

npx skills add forcedotcom/sf-skills --skill platform-deploy-validate -g -y

More Options

Non-standard path

npx skills add https://github.com/forcedotcom/sf-skills/tree/main/plugins/builder/salesforce-development/skills/platform-deploy-validate -g -y

Use without installing

npx skills use forcedotcom/sf-skills@platform-deploy-validate

指定 Agent (Claude Code)

npx skills add forcedotcom/sf-skills --skill platform-deploy-validate -a claude-code -g -y

安装 repo 全部 skill

npx skills add forcedotcom/sf-skills --all -g -y

预览 repo 内 skill

npx skills add forcedotcom/sf-skills --list

SKILL.md

Frontmatter

{
    "name": "platform-deploy-validate",
    "metadata": {
        "cliTools": [
            {
                "tool": [
                    "sf"
                ],
                "semver": ">=2.0.0"
            }
        ],
        "relatedSkills": [
            "platform-metadata-deploy",
            "platform-destructive-deploy",
            "platform-quick-deploy"
        ]
    },
    "description": "Validate Salesforce metadata before deploying. TRIGGER when the user asks to validate a deploy, do a dry-run, check before deploying, or targets a Production org for any deploy operation. Routes prod targets to `sf project deploy validate` (returns a 10-day quick-deploy job ID) and sandbox\/scratch targets to `sf project deploy start --dry-run`. DO NOT TRIGGER for actual deploys (use platform-metadata-deploy) or destructive changes (use platform-destructive-deploy).",
    "allowed-tools": [
        "Bash",
        "Read",
        "Write"
    ]
}

Validating Deployment

Run a server-side validation before deploying metadata. Validation surfaces errors without modifying the org and — for production targets — produces a job ID usable with platform-quick-deploy for a fast, test-free deploy.

Capability Resolution

Always prefer sf project deploy validate (prod) or sf project deploy start --dry-run (sandbox/scratch) over the Tooling API directly.

Workflow

Step 1 — Confirm the target org

sf org display --target-org <alias> --json | "${CLAUDE_PLUGIN_ROOT}/scripts/sf-deploy-gate" classify

Only production takes the production path (Step 2b); every other result takes the sandbox/scratch path (Step 2a).

Step 2a — Sandbox/Scratch path (dry-run)

sf project deploy start --dry-run --target-org <alias> --json [scope flags]

Scope flags (use exactly one, not all):

--source-dir <path> — deploy a directory
--metadata <Type:Name> — deploy specific components
--manifest manifest/package.xml — deploy from manifest

Default test level: omit --test-level for sandboxes (defers to org default). Add --test-level RunLocalTests only if the user asks.

Report back: success/failure, components attempted, any errors. No job ID is returned for dry-runs (this is expected).

Step 2b — Production path (validate)

sf project deploy validate --target-org <alias> --json [scope flags] --test-level RunLocalTests

Production validations REQUIRE a test level. Use RunLocalTests by default; switch to RunSpecifiedTests --tests <ClassName>... if the user has explicitly listed tests.

The response returns a job ID (result.id) valid for 10 days. Persist it for platform-quick-deploy:

mkdir -p .sfdx
echo '{"jobId":"<id>","createdAt":"<iso8601>","targetOrg":"<alias>","testLevel":"RunLocalTests"}' > .sfdx/last-validation.json

Report:

Validation result (passed / failed)
Job ID and 10-day expiry date
Test results summary (run / passed / failed)
Recommended next step: platform-quick-deploy with this job ID

Step 3 — Failure triage

If validation fails, parse result.details.componentFailures and result.details.runTestResult.failures and surface:

Top 5 component errors with full message
Top 5 test failures with stack
Suggested fix (component name → likely cause: missing dependency, FLS, syntax, etc.)

Do NOT propose fixes that change unrelated metadata. Stay scoped to what the validation reported.

Rules

ALWAYS use --json on every CLI call
NEVER skip validation when targeting Production (do not run sf project deploy start against prod from this skill)
NEVER use --ignore-errors or --ignore-warnings during validation; those flags belong to actual deploys, not validation
If the user asks to "deploy to prod" without prior validation, FIRST run validation, THEN hand off to platform-quick-deploy (do not start a regular deploy against prod)
Persist the validation job ID to .sfdx/last-validation.json so the quick-deploy skill can find it

Output

Always end with:

✅ Validation passed → next-step pointer to platform-quick-deploy (with job ID + expiry) OR to platform-metadata-deploy for non-prod
❌ Validation failed → categorized error list and suggested next iteration

Version History

1.33.0 Current 2026-08-05 13:01

Metadata

Files: 0
Version: 1.33.0
Hash: b314ed1e
Indexed: 2026-08-05 13:01

platform-deploy-validate

platform-deploy-validate

Trigger Scenarios

Install

SKILL.md

Validating Deployment

Capability Resolution

Workflow

Step 1 — Confirm the target org

Step 2a — Sandbox/Scratch path (dry-run)

Step 2b — Production path (validate)

Step 3 — Failure triage

Rules

Output

Version History

Same Skill Collection

Metadata

文库