Cómo usar
- Copia el comando y revisa el paquete antes de instalarlo en tu entorno de agente.
- Consulta las herramientas, credenciales y entornos necesarios en el documento original.
- Describe las entradas y el resultado deseado; contrasta la salida con las fuentes.
npx skills add https://github.com/forcedotcom/sf-skills --skill platform-quick-deployAntes de empezar
- La instalación no incluye suscripción al modelo, cuota API ni permisos sobre tus archivos.
- Las estrellas e instalaciones reflejan actividad, no una prueba independiente de calidad o seguridad.
Contenido del repositorio de origen con títulos, ejemplos, código, tablas, enlaces e imágenes preservados.
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




