dx-pkg-post-install-configure

Name: dx-pkg-post-install-configure
Author: forcedotcom

324installs272forks

How to install dx-pkg-post-install-configure?

forcedotcom/sf-skills/dx-pkg-post-install-configure

$npx -y skills add forcedotcom/sf-skills --skill dx-pkg-post-install-configure

Installs into the current project.

Summary

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-instal

Files · 1

View on GitHub

SKILL.md

1	## When to Use This Skill
2
3	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.
4
5	## Input
6
7	- Required: Package name (e.g., `LMA`, `FMA`, `work.com`)
8	- Optional: Path to post-install doc (PDF, markdown, URL)
9
10	If no doc is provided, ask the user to supply it.
11
12	## Workflow
13
14	Execute phases in order. Each phase must pass before proceeding.
15
16	---
17
18	### Phase 1: Discover Available Execution Methods
19
20	Priority order:
21	1. Org-native platform MCP servers (highest — direct org access via Headless 360)
22	2. Claude Code external MCP servers (sf-sobject-all, sf-sobject-all-sb, etc.)
23	3. sf CLI fallback (always available if authenticated)
24
25	#### Step 1A: Resolve org API version
26
27	Discover the org's current API version dynamically — never hardcode a version number:
28
29	```bash
30	sf org display --target-org <alias> --json
31	```
32
33	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`).
34
35	#### Step 1B: Check for org-native platform MCP servers
36
37	Query the Tooling API for MCP server availability:
38
39	```bash
40	sf api request rest "/services/data/v<apiVersion>/tooling/query?q=SELECT+Id,DeveloperName,MasterLabel+FROM+McpServerAccess" --target-org <alias>
41	```
42
43	#### Step 1C: Determine execution method
44
45	Check which Claude Code MCP tools are available and authenticated.
46
47	MCP tool prefixes by org type:
48
49	\| Org Type \| Tool Prefix \|
50	\|---\|---\|
51	\| Production \| `mcp__sf-sobject-all__` \|
52	\| Sandbox \| `mcp__sf-sobject-all-sb__` \|
53	\| Falcon Test (pc-rnd) \| `mcp__sf-sobject-all-falcon__` \|
54
55	If MCP needs auth, call the authenticate tool. If auth fails, fall back to sf CLI.
56
57	---
58
59	### Phase 2: Verify Authentication & Org Identity
60
61	1. Run a lightweight test query (`SELECT Id, Name, IsSandbox FROM Organization`)
62	2. If MCP auth fails, automatically fall back to sf CLI
63	3. Display org info and ask user to confirm before proceeding
64
65	---
66
67	### Phase 3: Verify Package Installation
68
69	1. Determine the package namespace (ask user if unknown)
70	2. Check via Tooling API (`InstalledSubscriberPackage`) — do NOT use `PackageLicense`
71	3. If package not found, stop and inform user
72
73	---
74
75	### Phase 4: Read and Parse Post-Install Document
76
77	Read the provided document and extract discrete configuration steps.
78
79	Supported formats: PDF, markdown, URL (via WebFetch), pasted text.
80
81	Parsing approach:
82	1. Extract each numbered/bulleted step from the document
83	2. Present the extracted steps to the user for validation before proceeding
84
85	---
86
87	### Phase 5: Classify Steps & Interactive Plan Review
88
89	For each step extracted from the doc, classify as Automated or Manual.
90
91	#### Automation capabilities reference
92
93	Via MCP (sobject-all) or sf CLI CRUD:
94	- Record CRUD on any standard or custom object (PermissionSet, ObjectPermissions,
95	FieldPermissions, SetupEntityAccess, PermissionSetTabSetting, PermissionSetAssignment, etc.)
96
97	Via Metadata API retrieve/deploy (sf CLI):
98	- Page layout modifications (add related lists, fields, sections)
99	- Profile settings
100	- Custom metadata type records
101
102	Via sf CLI Tooling API:
103	- Tooling queries (InstalledSubscriberPackage, ApexPage, ApexClass, etc.)
104	- Any REST-accessible Tooling operation
105
106	Manual (no API path — requires Setup UI):
107	- System permissions not exposed via REST
108	- Connected app OAuth configuration
109	- Environment Hub linkage
110
111	#### Interactive approval
112
113	Present the classified plan and let the user choose:
114	- "Approve all" — Execute all steps as planned
115	- "Let me choose" — Select which steps to approve/skip
116	- "I have questions" — Discuss specific steps before deciding
117
118	---
119
120	### Phase 6: Execute Approved Steps
121
122	For each approved step, use the resolved execution method.
123
124	#### Execution method reference
125
126	\| Operation \| Via MCP \| Via sf CLI \|
127	\|---\|---\|---\|
128	\| SOQL q

People who liked this also viewed

6 picks

Type

dx-pkg-post-install-configure

324installs272forks

View on GitHub

How to install dx-pkg-post-install-configure?

forcedotcom/sf-skills/dx-pkg-post-install-configure

$npx -y skills add forcedotcom/sf-skills --skill dx-pkg-post-install-configure

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## When to Use This Skill
2
3	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.
4
5	## Input
6
7	- Required: Package name (e.g., `LMA`, `FMA`, `work.com`)
8	- Optional: Path to post-install doc (PDF, markdown, URL)
9
10	If no doc is provided, ask the user to supply it.
11
12	## Workflow
13
14	Execute phases in order. Each phase must pass before proceeding.
15
16	---
17
18	### Phase 1: Discover Available Execution Methods
19
20	Priority order:
21	1. Org-native platform MCP servers (highest — direct org access via Headless 360)
22	2. Claude Code external MCP servers (sf-sobject-all, sf-sobject-all-sb, etc.)
23	3. sf CLI fallback (always available if authenticated)
24
25	#### Step 1A: Resolve org API version
26
27	Discover the org's current API version dynamically — never hardcode a version number:
28
29	```bash
30	sf org display --target-org <alias> --json
31	```
32
33	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`).
34
35	#### Step 1B: Check for org-native platform MCP servers
36
37	Query the Tooling API for MCP server availability:
38
39	```bash
40	sf api request rest "/services/data/v<apiVersion>/tooling/query?q=SELECT+Id,DeveloperName,MasterLabel+FROM+McpServerAccess" --target-org <alias>
41	```
42
43	#### Step 1C: Determine execution method
44
45	Check which Claude Code MCP tools are available and authenticated.
46
47	MCP tool prefixes by org type:
48
49	\| Org Type \| Tool Prefix \|
50	\|---\|---\|
51	\| Production \| `mcp__sf-sobject-all__` \|
52	\| Sandbox \| `mcp__sf-sobject-all-sb__` \|
53	\| Falcon Test (pc-rnd) \| `mcp__sf-sobject-all-falcon__` \|
54
55	If MCP needs auth, call the authenticate tool. If auth fails, fall back to sf CLI.
56
57	---
58
59	### Phase 2: Verify Authentication & Org Identity
60
61	1. Run a lightweight test query (`SELECT Id, Name, IsSandbox FROM Organization`)
62	2. If MCP auth fails, automatically fall back to sf CLI
63	3. Display org info and ask user to confirm before proceeding
64
65	---
66
67	### Phase 3: Verify Package Installation
68
69	1. Determine the package namespace (ask user if unknown)
70	2. Check via Tooling API (`InstalledSubscriberPackage`) — do NOT use `PackageLicense`
71	3. If package not found, stop and inform user
72
73	---
74
75	### Phase 4: Read and Parse Post-Install Document
76
77	Read the provided document and extract discrete configuration steps.
78
79	Supported formats: PDF, markdown, URL (via WebFetch), pasted text.
80
81	Parsing approach:
82	1. Extract each numbered/bulleted step from the document
83	2. Present the extracted steps to the user for validation before proceeding
84
85	---
86
87	### Phase 5: Classify Steps & Interactive Plan Review
88
89	For each step extracted from the doc, classify as Automated or Manual.
90
91	#### Automation capabilities reference
92
93	Via MCP (sobject-all) or sf CLI CRUD:
94	- Record CRUD on any standard or custom object (PermissionSet, ObjectPermissions,
95	FieldPermissions, SetupEntityAccess, PermissionSetTabSetting, PermissionSetAssignment, etc.)
96
97	Via Metadata API retrieve/deploy (sf CLI):
98	- Page layout modifications (add related lists, fields, sections)
99	- Profile settings
100	- Custom metadata type records
101
102	Via sf CLI Tooling API:
103	- Tooling queries (InstalledSubscriberPackage, ApexPage, ApexClass, etc.)
104	- Any REST-accessible Tooling operation
105
106	Manual (no API path — requires Setup UI):
107	- System permissions not exposed via REST
108	- Connected app OAuth configuration
109	- Environment Hub linkage
110
111	#### Interactive approval
112
113	Present the classified plan and let the user choose:
114	- "Approve all" — Execute all steps as planned
115	- "Let me choose" — Select which steps to approve/skip
116	- "I have questions" — Discuss specific steps before deciding
117
118	---
119
120	### Phase 6: Execute Approved Steps
121
122	For each approved step, use the resolved execution method.
123
124	#### Execution method reference
125
126	\| Operation \| Via MCP \| Via sf CLI \|
127	\|---\|---\|---\|
128	\| SOQL q

People who liked this also viewed

6 picks

Type