Mode d’emploi
- Copiez la commande et examinez le paquet avant de l’installer dans votre environnement agent.
- Consultez le document original pour les outils, identifiants et environnements requis.
- Décrivez les entrées et le livrable souhaité ; comparez la sortie aux sources.
npx skills add https://github.com/forcedotcom/sf-skills --skill platform-quick-deployAvant de commencer
- L’installation n’inclut ni abonnement au modèle, ni quota API, ni accès aux fichiers.
- Étoiles et installations reflètent l’activité, pas un test indépendant de qualité ou de sécurité.
Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.
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




