platform-quick-deploy
Deploy validated metadata to a Production Salesforce org without re-running tests. TRIGGER when the user wants to deploy to production, says 'quick deploy', 'promote', 'ship to prod', or has just validated and wants to push the change live. REQUIRES a recent `sf project deploy validate` job ID (≤10 days old, ≤3 days for --use-most-recent). DO NOT TRIGGER for sandbox/scratch deploys (use platform-metadata-deploy) or unvalidated deploys (use platform-deploy-validate first).
Resumen
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
--ortest.salesforce.comhost 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 toplatform-metadata-deploy(which handles non-prod natively).unknownmeans 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 withsf org login webusually 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)
- Read
- 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
- 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
Archivos 1 archivo
Instálala a mano
Deska ejecuta esto por ti, para cada agente que elijas. Para ejecutarlo tú en una terminal:
npx skills add forcedotcom/sf-skills --skill platform-quick-deployMás de forcedotcom
- platform-apex-generateforcedotcomPrimary Apex authoring skill for class generation, refactoring, and review. ALWAYS ACTIVATE when the user mentions Apex, .cls, triggers, or asks to create/refactor a class (service, selector, domain, batch, queueable, schedulable, invocable, DTO, utility, interface, abstract, exception, REST resource). Use this skill for requests involving SObject CRUD, mapping collections, fetching related records, scheduled jobs, batch jobs, trigger design, @AuraEnabled controllers, @RestResource endpoints, custom REST APIs, or code review of existing Apex.6,700 instalaciones en skills.sh0
- platform-apex-test-generateforcedotcomUse to generate and validate Apex test classes with TestDataFactory patterns, bulk testing (251+ records), mocking, assertions, and disciplined test-fix loops. Use when creating Apex test classes (for triggers, services, controllers, batch jobs, queueables, and callouts), improving coverage, debugging or fixing failing Apex tests, or running test/coverage analysis. Triggers on *Test.cls files, sf apex run test, coverage reports. Do NOT trigger for production Apex (use platform-apex-generate) or Jest/LWC tests.6,600 instalaciones en skills.sh0
- platform-apex-test-runforcedotcomApex test execution, coverage analysis, and test-fix loops with 120-point scoring. Use when the user runs Apex tests, checks code coverage, fixes failing tests, or touches *Test.cls / *_Test.cls files. DO NOT TRIGGER when writing Apex production code (use platform-apex-generate), Agentforce agent testing (use agentforce-test), or Jest/LWC tests (use experience-lwc-generate).6,500 instalaciones en skills.sh0
- platform-apex-logs-debugforcedotcomSalesforce debug log analysis and troubleshooting with 100-point scoring. TRIGGER when: user analyzes debug logs, hits governor limits, reads stack traces, or touches .log files from Salesforce orgs. DO NOT TRIGGER when: running Apex tests (use platform-apex-test-run), generating or fixing Apex code (use platform-apex-generate), or Agentforce session tracing (use agentforce-observe).6,400 instalaciones en skills.sh0
- platform-metadata-deployforcedotcomSalesforce DevOps automation using sf CLI v2. TRIGGER when: user deploys metadata, creates/manages scratch orgs or sandboxes, sets up CI/CD pipelines, or troubleshoots deployment errors with sf project deploy. DO NOT TRIGGER when: writing Apex code (use platform-apex-generate), building LWC components (use experience-lwc-generate), creating metadata definitions (use platform-custom-object-generate or platform-custom-field-generate), or querying org data (use platform-data-manage).6,300 instalaciones en skills.sh0