
Sf Deploy
Run Salesforce CLI deploys—including pre/post destructiveChanges.xml—to push metadata safely into target orgs.
Overview
Sf-deploy is an agent skill for the Ship phase that structures Salesforce CLI metadata deployments and destructiveChanges.xml deletes for target org launches.
Install
npx skills add https://github.com/jaganpro/sf-skills --skill sf-deployWhat is this skill?
- destructiveChanges.xml template for Apex classes, triggers, objects, fields, LWC, and Aura bundles
- sf project deploy start with --manifest package.xml plus --pre-destructive-changes or --post-destructive-changes
- Commented XML examples for deprecated Apex, custom objects, and Lightning bundles
- Targets named orgs via --target-org including production paths
- Aligns deploy flow with Salesforce DX metadata packaging conventions
- Template documents six metadata type families for deletion (Apex, triggers, objects, fields, LWC, Aura)
Adoption & trust: 1.3k installs on skills.sh; 418 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a package.xml ready but fear leaving deprecated Salesforce metadata behind or mis-ordering destructive deletes during production deploy.
Who is it for?
Indie Salesforce developers and tiny ISV teams using DX manifests who need agent help drafting destructive change sets for CLI deploys.
Skip if: Builders not on Salesforce Platform, teams using change sets only without CLI, or orgs that forbid automated destructive deploys without human approval.
When should I use this skill?
Starting a Salesforce metadata deploy that may include pre- or post-destructive component removal to a named target org.
What do I get? / Deliverables
You get a valid destructiveChanges manifest and the exact sf project deploy start invocation with pre/post destructive flags aimed at your target org.
- destructiveChanges.xml with typed members blocks
- Documented sf project deploy start command with destructive flags
- Commented examples for deprecated metadata removal
Recommended Skills
Journey fit
Metadata hits the org when you ship Salesforce customizations; canonical placement is Ship because this is release execution, not greenfield Build coding. Launch subphase covers go-live deploy commands, manifests, and destructive deletes bundled with package.xml.
How it compares
Template-first DX deploy helper—not a full CI pipeline skill or Salesforce MCP integration.
Common Questions / FAQ
Who is sf-deploy for?
Salesforce developers and solo consultants who promote metadata with Salesforce CLI and need structured destructive change manifests alongside package.xml.
When should I use sf-deploy?
Use it during Ship when launching or refreshing org metadata, especially when you must remove deprecated Apex, fields, or Lightning bundles via --pre-destructive-changes or --post-destructive-changes.
Is sf-deploy safe to install?
Destructive deploys can delete live org data and code; review the Security Audits panel on this page and require human review plus sandbox validation before any production --target-org run.
SKILL.md
READMESKILL.md - Sf Deploy
<?xml version="1.0" encoding="UTF-8"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <!-- Destructive Changes Template Use this file to specify metadata components to delete from the target org. This file should be used with --pre-destructive-changes or --post-destructive-changes Example: sf project deploy start \ --manifest manifest/package.xml \ --post-destructive-changes manifest/destructiveChanges.xml \ --target-org production --> <!-- Delete Apex Classes --> <!-- <types> <members>DeprecatedClass1</members> <members>DeprecatedClass2</members> <name>ApexClass</name> </types> --> <!-- Delete Apex Triggers --> <!-- <types> <members>OldTrigger</members> <name>ApexTrigger</name> </types> --> <!-- Delete Custom Objects --> <!-- <types> <members>ObsoleteObject__c</members> <name>CustomObject</name> </types> --> <!-- Delete Custom Fields --> <!-- <types> <members>Account.DeprecatedField__c</members> <members>Contact.OldField__c</members> <name>CustomField</name> </types> --> <!-- Delete Lightning Components --> <!-- <types> <members>oldComponent</members> <name>LightningComponentBundle</name> </types> --> <!-- Delete Aura Components --> <!-- <types> <members>deprecatedAuraComponent</members> <name>AuraDefinitionBundle</name> </types> --> <!-- Delete Validation Rules --> <!-- <types> <members>Account.OldValidationRule</members> <name>ValidationRule</name> </types> --> <!-- Delete Workflow Rules --> <!-- <types> <members>Account.OldWorkflowRule</members> <name>WorkflowRule</name> </types> --> <!-- Delete Flows --> <!-- <types> <members>Deprecated_Flow</members> <name>Flow</name> </types> --> <!-- Delete Permission Sets --> <!-- <types> <members>ObsoletePermissionSet</members> <name>PermissionSet</name> </types> --> <!-- Delete Static Resources --> <!-- <types> <members>oldStaticResource</members> <name>StaticResource</name> </types> --> <!-- API Version --> <version>66.0</version> </Package> <!-- IMPORTANT NOTES: 1. Order of operations: - Pre-destructive: Deleted BEFORE deployment (--pre-destructive-changes) - Post-destructive: Deleted AFTER deployment (--post-destructive-changes) 2. Best practices: - Test destructive changes in sandbox first - Backup metadata before deletion - Use --dry-run to validate before actual deployment - Delete fields before objects - Be careful with dependencies 3. Common destructive change scenarios: - Removing deprecated features - Cleaning up unused metadata - Refactoring object structures - Removing test/demo data objects 4. Example usage: sf project deploy start \ --manifest manifest/package.xml \ --post-destructive-changes manifest/destructiveChanges.xml \ --target-org sandbox \ --dry-run \ --test-level RunLocalTests \ --wait 30 5. Rollback: - Keep backup of deleted metadata in version control - Tag the commit before destructive deployment - Can redeploy from backup if needed --> <?xml version="1.0" encoding="UTF-8"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <!-- Apex Classes --> <types> <members>*</members> <name>ApexClass</name> </types> <!-- Apex Triggers --> <types> <members>*</members> <name>ApexTrigger</name> </types> <!-- Aura Components --> <types> <members>*</members> <name>AuraDefinitionBundle</name> </types> <!-- Lightning Web Components --> <types> <members>*</members> <name>LightningComponentBundle