sf-setup-automation

Automates Salesforce Setup changes lacking Metadata API coverage via gated browser sessions and audit verification.

2|Updated Sep 12, 2026
One-click install
npx skills add https://github.com/grzmol/vibe-force --skill sf-setup-automation-grzmol
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sf-setup-automation
Source: https://github.com/grzmol/vibe-force/tree/main/skills/sf-setup-automation
Command: npx skills add https://github.com/grzmol/vibe-force --skill sf-setup-automation-grzmol

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires @playwright/mcp, and includes references (resource) components.

What problem does it solve? Some Salesforce org preferences and feature switches have no metadata type, so no deploy can carry them, and clicking them in Setup leaves no versioned, auditable trail. This Skill decides whether a change belongs in a deploy, a scratch-org definition, or a browser session, then executes browser-driven Setup changes safely and proves them with SetupAuditTrail. ## Core Features & Use Cases - Deploy-vs-browser gating: Runs vf-setup check against the org's own describeMetadata to decide whether a change is deployable, recording the verdict in a gate file that MCP guards read. - Credential-safe browser hand-off: vf-setup serve keeps the single-use frontdoor URL in process memory and hands the browser a loopback ticket, so a live admin session never enters the transcript. - Accessibility-tree automation and proof: Drives Lightning Setup via Playwright MCP snapshots, then verifies the change with SetupAuditTrail queries instead of trusting screenshots. - Use Case: You need to enable an Einstein feature toggle that has no metadata type. The Skill confirms no deploy route exists, hands a headless browser a single-use session, makes the change, and confirms it in the org's audit trail. ## Quick Start Ask the assistant to enable a specific Salesforce Setup preference in your sandbox org and verify the change in SetupAuditTrail.

Frequently Asked Questions about sf-setup-automation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I change a Salesforce Setup setting that has no metadata type?

Run vf-setup check to confirm the Metadata API cannot deploy it, then use vf-setup serve to hand a headless browser a single-use authenticated session. Drive the change through Playwright MCP snapshot and click tools, then verify it with a SetupAuditTrail query.

How do I know if a Salesforce setting is deployable via Metadata API?

Run sf org list metadata-types or vf-setup check against the target org to get its describeMetadata result, which lists every metadata type the org supports. The Metadata Coverage Report is the official source of truth; never rely on a hardcoded list of unsupported types.

Is it safe to pass a Salesforce frontdoor URL to a browser tool?

No. A frontdoor URL from sf org open --url-only is a live admin session, and putting it in a tool argument writes it into the transcript. vf-setup serve keeps it in process memory and issues a loopback ticket that expires and works exactly once.

Why did my Salesforce Setup change not take effect after clicking save?

Lightning can render a saved-looking page while server-side validation fails. Query SetupAuditTrail with vf-setup audit --since 30m; an empty result means the change did not happen, and browser_console_messages usually reveals the failing validation rule or permission.

When should I not use browser automation for Salesforce configuration?

Never use it for anything with a metadata type, such as objects, fields, layouts, flows, or permission sets, since those belong in a versioned deploy. Scratch org features belong in the scratch definition file, and production Setup changes are refused by the tooling.