forcedotcom/sf-skills

platform-quick-deploy

Deploy validated metadata to a Production Salesforce org without re-running tests.

ソースを見る

使い方

  1. インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
  2. 必要なツール、認証情報、対応環境を原文で確認します。
  3. 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/forcedotcom/sf-skills --skill platform-quick-deploy

開始前の確認

  • 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
  • スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文

見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。

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:

  1. 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):

bash
   "${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.

  1. A validation exists
  • Read .sfdx/last-validation.json if it exists (left there by platform-deploy-validate)
  • OR ask the user for the job ID
  • OR fall back to --use-most-recent (validates within last 3 days)
  1. 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 createdAt exceeds the window → STOP and run platform-deploy-validate first
  1. 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":

bash
sf project deploy quick --job-id <id> --target-org <alias> --wait 30 --json

Or 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:

bash
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 start against a Production target (always validate then quick-deploy)
  • NEVER use --ignore-errors or --ignore-warnings on 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-validate first

タスクに関連する項目

同じリポジトリから

関連する Skills

すべての Skills
forcedotcom
コミュニティ

design-systems-slds-apply

Apply SLDS-compliant UI using the correct blueprints, styling hooks, utility classes, and icons. Use when building any UI that needs SLDS, choosing between Lightning Base Components and SLDS Blueprints, applying styling hooks for theming, using utility classes for layout and spacing, or selecting icons. Triggers include \"build a modal\", \"create a form\", \"data table\", \"SLDS styling\", \"style with hooks\", \"add an icon\".

導入数
2
GitHub Stars
1109
更新日
10月21日
forcedotcom
コミュニティ

design-systems-slds-validate

Audit Lightning Web Components for SLDS design-system compliance and produce a scored quality report. Runs the SLDS linter and analyzes CSS for theming hook usage and pairing, scoring SLDS findings across categories into an overall grade. Use when asked to \"score my component's SLDS\", \"SLDS scorecard\", \"SLDS quality report\", \"audit SLDS compliance\", \"how good is my SLDS\", \"check SLDS quality\", \"rate my SLDS styling\", \"evaluate my component's SLDS\", \"is this component's SLDS read

導入数
2
GitHub Stars
1109
更新日
10月21日
forcedotcom
コミュニティ

external-diagram-mermaid-generate

Salesforce architecture diagrams using Mermaid with ASCII fallback. Use this skill when generating text-based diagrams for Salesforce architecture, OAuth flows, ERDs, integration sequences, or Agentforce structure. TRIGGER when: user says \"diagram\", \"visualize\", \"ERD\", or asks for sequence diagrams, flowcharts, class diagrams, or architecture visualizations in Mermaid. DO NOT TRIGGER when: user asks about non-Salesforce systems.

導入数
2
GitHub Stars
1109
更新日
10月21日
forcedotcom
コミュニティ

platform-architecture-analyze

Use when the developer asks to \"review the architecture\", \"run a Well-Architected check\", \"audit this project\", \"is this project well-architected?\", or wants to assess security/governor-limit/risk as a holistic code-and-metadata health report. Grades observable criteria (sharing/FLS, bulkification, SOQL selectivity, packageability) with file:line evidence; emits a governance checklist for what it can't see. Read-only, never edits. DO NOT TRIGGER for single-tool Apex scans (dx-code-analyz

導入数
2
GitHub Stars
1109
更新日
10月21日