
Deploying Metadata
Deploy Salesforce metadata with sf project deploy and controlled destructiveChanges.xml pre/post deletes.
Overview
deploying-metadata is an agent skill for the Ship phase that guides Salesforce CLI metadata deploys including destructiveChanges.xml for controlled component deletion.
Install
npx skills add https://github.com/forcedotcom/sf-skills --skill deploying-metadataWhat is this skill?
- Destructive changes XML template for pre- or post-deploy deletions via sf CLI
- Commented examples for ApexClass, ApexTrigger, CustomObject, CustomField, LWC, and Aura bundles
- Documents sf project deploy start with manifest plus --post-destructive-changes or --pre-destructive-changes
- Shows --target-org flag pattern for production-oriented deploys
Adoption & trust: 735 installs on skills.sh; 513 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need to promote a manifest-based deploy to a target org and remove deprecated Salesforce metadata without leaving orphan types or failed dependency deploys.
Who is it for?
Indie Salesforce developers shipping DX projects who must delete retired Apex, fields, or bundles in the same release pipeline as additive metadata.
Skip if: Greenfield prototypes with no Salesforce org, or teams that only use change sets without CLI manifests and destructive delete files.
When should I use this skill?
Planning or executing sf project deploy with destructive changes against a named target org.
What do I get? / Deliverables
You run sf project deploy start with package.xml, optional pre/post destructive changes, and an explicit --target-org for the intended environment.
- destructiveChanges.xml manifest for pre or post deploy
- Documented sf project deploy start command line for the release
Recommended Skills
Journey fit
Metadata deploy is the gated push from project source to a target org—classic ship/launch prep before or during production cutover. Launch subphase covers release execution commands, manifests, and org targeting rather day-two monitoring.
How it compares
Skill workflow for CLI manifest deploys and destructive XML—not a substitute for full CI/CD pipeline design or org backup strategy.
Common Questions / FAQ
Who is deploying-metadata for?
Builders using Salesforce DX and sf CLI who own manifest-based deploys and need documented destructive change patterns.
When should I use deploying-metadata?
In Ship/Launch when preparing production or sandbox pushes that must delete deprecated classes, triggers, objects, fields, or Lightning bundles via destructiveChanges.xml.
Is deploying-metadata safe to install?
The skill encodes destructive delete operations that can harm production data models; review Security Audits on this page and never run unreviewed destructive deploys against production.
SKILL.md
READMESKILL.md - Deploying Metadata
<?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