Dx Pkg Post Install Configure

forcedotcom/sf-skills/plugins/builder/dx-org-lifecycle/skills/dx-pkg-post-install-configure

作者 forcedotcome5164d94d7511c00fa02a5b8b60754b2361e178f無授權條款1K 個星標收錄於 2026年10月9日更新於 2026年10月9日儲存庫昨天更新

Use this skill to automate managed package post-install configuration. Package-agnostic — works with any managed package (LMA, FMA, work.com, Certinia, etc.). TRIGGER when: user installs a managed package and needs post-install configuration, mentions LMA/FMA/work.com post-install setup, asks to configure permission sets/FLS/page layouts for an installed package, says 'post-install', 'package setup', 'configure LMA', 'set up FMA', 'post-install steps'. DO NOT TRIGGER for: standalone permission set assignment (use dx-org-permission-set-assign), generating permission set metadata XML (use platform-permission-set-generate), package installation, or org switching.

僅含說明DevOps & Cloud
AI 產生的概覽

使用 MCP 工具或 sf CLI 自動完成 Salesforce 受管理套件的安裝後設定。

功能
此技能引導代理在安裝後設定 Salesforce 受管理套件。它會讀取套件的安裝後文件,擷取設定步驟,將其分類為可自動化或需手動執行,並執行已核准的步驟,例如權限集、物件與欄位權限、頁面配置、Visualforce 頁面存取及索引標籤設定。它會產生逐步狀態摘要,並為無法自動化的步驟提供 Setup 導覽指引。
適用情境
在安裝 Salesforce 受管理套件後需要安裝後設定時使用,例如設定權限集、欄位層級安全性或頁面配置。它適用於提及安裝後步驟、套件設定或設定 LMA、FMA、work.com 等套件的要求。它不適用於獨立的權限集指派、產生權限集中繼資料、套件安裝或組織切換。
執行需求
一個已透過 sf CLI(2.0.0 或更高版本)驗證的 Salesforce 組織,API 版本為 67.0 或更高。可選用組織原生或 Claude Code MCP 伺服器直接存取組織,並以 sf CLI 作為後備。需要提供套件名稱;若使用者未提供,還需要安裝後文件(PDF、markdown、URL 或貼上的文字)。需要連線至 Salesforce 組織的網路存取。不隨附指令碼。

When to Use This Skill

Use when automating post-install configuration for any Salesforce managed package. This skill reads the package's post-install documentation, discovers available execution methods, and automates the configuration steps — including permission sets, object/field permissions, page layouts, Visualforce page access, and tab settings.

Input

  • Required: Package name (e.g., LMA, FMA, work.com)
  • Optional: Path to post-install doc (PDF, markdown, URL)

If no doc is provided, ask the user to supply it.

Workflow

Execute phases in order. Each phase must pass before proceeding.


Phase 1: Discover Available Execution Methods

Priority order:

  1. Org-native platform MCP servers (highest — direct org access via Headless 360)
  2. Claude Code external MCP servers (sf-sobject-all, sf-sobject-all-sb, etc.)
  3. sf CLI fallback (always available if authenticated)
Step 1A: Resolve org API version

Discover the org's current API version dynamically — never hardcode a version number:

bash
sf org display --target-org <alias> --json

From the JSON response, read result.apiVersion (e.g., "67.0"). Store this value and use it as v<apiVersion> in all subsequent REST paths. If the command fails, fall back to the minApiVersion declared in this skill's metadata (67.0).

Step 1B: Check for org-native platform MCP servers

Query the Tooling API for MCP server availability:

bash
sf api request rest "/services/data/v<apiVersion>/tooling/query?q=SELECT+Id,DeveloperName,MasterLabel+FROM+McpServerAccess" --target-org <alias>
Step 1C: Determine execution method

Check which Claude Code MCP tools are available and authenticated.

MCP tool prefixes by org type:

Org TypeTool Prefix
Productionmcp__sf-sobject-all__
Sandboxmcp__sf-sobject-all-sb__
Falcon Test (pc-rnd)mcp__sf-sobject-all-falcon__

If MCP needs auth, call the authenticate tool. If auth fails, fall back to sf CLI.


Phase 2: Verify Authentication & Org Identity

  1. Run a lightweight test query (SELECT Id, Name, IsSandbox FROM Organization)
  2. If MCP auth fails, automatically fall back to sf CLI
  3. Display org info and ask user to confirm before proceeding

Phase 3: Verify Package Installation

  1. Determine the package namespace (ask user if unknown)
  2. Check via Tooling API (InstalledSubscriberPackage) — do NOT use PackageLicense
  3. If package not found, stop and inform user

Phase 4: Read and Parse Post-Install Document

Read the provided document and extract discrete configuration steps.

Supported formats: PDF, markdown, URL (via WebFetch), pasted text.

Parsing approach:

  1. Extract each numbered/bulleted step from the document
  2. Present the extracted steps to the user for validation before proceeding

Phase 5: Classify Steps & Interactive Plan Review

For each step extracted from the doc, classify as Automated or Manual.

Automation capabilities reference

Via MCP (sobject-all) or sf CLI CRUD:

  • Record CRUD on any standard or custom object (PermissionSet, ObjectPermissions, FieldPermissions, SetupEntityAccess, PermissionSetTabSetting, PermissionSetAssignment, etc.)

Via Metadata API retrieve/deploy (sf CLI):

  • Page layout modifications (add related lists, fields, sections)
  • Profile settings
  • Custom metadata type records

Via sf CLI Tooling API:

  • Tooling queries (InstalledSubscriberPackage, ApexPage, ApexClass, etc.)
  • Any REST-accessible Tooling operation

Manual (no API path — requires Setup UI):

  • System permissions not exposed via REST
  • Connected app OAuth configuration
  • Environment Hub linkage
Interactive approval

Present the classified plan and let the user choose:

  • "Approve all" — Execute all steps as planned
  • "Let me choose" — Select which steps to approve/skip
  • "I have questions" — Discuss specific steps before deciding

Phase 6: Execute Approved Steps

For each approved step, use the resolved execution method.

Execution method reference
OperationVia MCPVia sf CLI
SOQL querysoqlQuery toolsf data query --query "<SOQL>" --target-org <alias> --json
Create recordcreateSobjectRecord toolsf data create record --sobject <Object> --values "..." --target-org <alias> --json
Update recordupdateSobjectRecord toolsf data update record --sobject <Object> --record-id <id> --values "..." --target-org <alias> --json
Describe objectgetObjectSchema toolsf api request rest "/services/data/v<apiVersion>/sobjects/<Object>/describe" --target-org <alias>
Page layoutN/AMetadata API retrieve/deploy
Page layout modifications via Metadata API

Use sf project retrieve start → edit the layout XML → sf project deploy start.

Execution rules
  • Idempotency: Before creating any record, query to check if it already exists. Skip if so.
  • Report after each step: Show success count, skipped items, and reasons.
  • Automatic fallback: If MCP fails mid-execution, retry via sf CLI.
  • On failure: Report error, ask user to retry/skip/stop.

Phase 7: Guide Manual Steps (if any)

If any steps could not be automated, present each with Setup navigation instructions. Wait for user confirmation before proceeding to the next.


Phase 8: Summary

Display final summary with step-by-step status, method used, and any skipped items.


Error Handling

  • Auth failure mid-execution: Stop, ask user to re-auth, offer to resume
  • Duplicate record errors: Treat as "already configured", skip and continue
  • Permission errors: Report which permission is missing, suggest resolution
  • Unknown step type: Ask user to clarify, offer to mark as manual

Notes

  • Priority: org-native MCP > Claude Code MCP > sf CLI > manual
  • sf CLI is always a valid fallback for all CRUD and Tooling API operations
  • Page layout modifications are automated via Metadata API retrieve/deploy
  • Always verify org identity before making changes
  • All actions respect the authenticated user's permissions

來源與署名

來源:forcedotcom/sf-skills位於plugins/builder/dx-org-lifecycle/skills/dx-pkg-post-install-configure提交e5164d9

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架