How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/forcedotcom/sf-skills --skill platform-quick-deployBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
Quick Deploying to Prod
Promote a validated deploy to a Production org using the job ID from a prior sf project deploy validate. No tests re-run, no components re-validated — just the promotion.
Preconditions (gate strictly)
Before doing ANYTHING, verify all four:
- Target is Production
Confirm the target really is production with the gate's classifier, which resolves the org the same way the deploy hook does (returns production|sandbox|scratch|trial|unknown):
"${CLAUDE_PLUGIN_ROOT}/scripts/sf-deploy-gate" bucket <alias>Production means not a scratch org or sandbox (no -- or test.salesforce.com host marker) and not a trial/Developer Edition org (orgfarm-*, *.develop.my.salesforce.com, *.pc-rnd.* hosts, or a future trial expiration date, as on SDOs). A Dev Hub with none of those signals is production.
If target is NOT production (classifier returns anything other than production) → STOP and redirect to platform-metadata-deploy (which handles non-prod natively). unknown means the org type could not be confirmed (usually an incomplete org record). Say so plainly: the deploy gate still allows the deploy, auto-deploy on save stays off for that org, and re-authenticating with sf org login web usually restores the classification.
- A validation exists
- Read
.sfdx/last-validation.jsonif it exists (left there byplatform-deploy-validate) - OR ask the user for the job ID
- OR fall back to
--use-most-recent(validates within last 3 days)
- Validation is fresh enough
- Explicit
--job-id: must be ≤10 days old per Salesforce's quick-deploy window --use-most-recent: must be ≤3 days old- If the recorded
createdAtexceeds the window → STOP and runplatform-deploy-validatefirst
- Explicit user confirmation
- Print a confirmation block (alias, instance URL, edition, validated component count, test results) and ask: "Confirm deploy to PRODUCTION? (yes/no)"
- Do NOT proceed without an explicit "yes"
Workflow
Step 1 — Display the production confirmation banner
Format exactly:
┌─ PRODUCTION DEPLOY ─────────────────────────────┐
│ Org alias: <alias> │
│ Instance: <instanceUrl> │
│ Edition: <edition> │
│ Validation ID: <jobId> │
│ Validated: <createdAt> (X days ago) │
│ Components: <componentCount> queued │
│ Tests: <run>/<passed>/<failed> │
└─────────────────────────────────────────────────┘
Confirm deploy to PRODUCTION? (yes/no)Step 2 — Run the quick deploy
After "yes":
sf project deploy quick --job-id <id> --target-org <alias> --wait 30 --jsonOr with --use-most-recent if the user opted in.
The quick deploy will:
- Promote the validated components to the org
- NOT re-run tests (per Salesforce platform behavior)
- Return final deploy status
Step 3 — Capture the deploy report
After completion, persist for audit:
mkdir -p .sfdx/deploy-history
sf project deploy report --job-id <id> --target-org <alias> --json > ".sfdx/deploy-history/<id>.json"Surface to the user:
- ✅ Deploy succeeded — components deployed, time taken
- ⚠️ Deploy failed — error summary; recommend looking at the report
Step 4 — Post-deploy guidance
After a successful prod deploy, suggest:
- Smoke-test critical paths in the org (provide direct URLs if known)
- Monitor the prod environment for the next 30 min
- Check Setup → Deployment Status to confirm
- If anything regressed: prepare a rollback plan (re-deploy the previous version's package)
Rules
- NEVER run
sf project deploy startagainst a Production target (always validate then quick-deploy) - NEVER use
--ignore-errorsor--ignore-warningson production - NEVER auto-confirm — require an explicit "yes" from the user
- NEVER quick-deploy a job ID older than its validity window — re-validate instead
- ALWAYS persist the deploy report to
.sfdx/deploy-history/for the audit trail - If the prod-check hook denies the operation, do NOT bypass it — surface the denial to the user and recommend
platform-deploy-validatefirst




