platform-manifest-generate
Use to generate a package.xml (and optionally destructiveChanges.xml / Pre / Post) from a source dir, a component list, or org introspection. Trigger on 'generate a package.xml from this folder', 'create a manifest for these classes', 'I need a deploy manifest', or 'destructiveChanges.xml for deletions'. Encodes wildcard-vs-explicit-member rules per metadata type. DO NOT TRIGGER to deploy (platform-metadata-deploy), delete (platform-destructive-deploy), or retrieve (platform-metadata-retrieve).
- Installs
- 3K
- Last 24h
- +17
- Trending rank
- #6440
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/forcedotcom/sf-skills --skill platform-manifest-generate- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads platform-manifest-generate automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
platform-manifest-generate
Produce a Salesforce metadata manifest — package.xml (or one of the destructive variants) — from local source, an org, or an explicit component list. This skill is purely about authoring the manifest file. Hand off to platform-metadata-deploy or platform-destructive-deploy once the file exists.
Tool Restrictions
Use ONLY the Bash tool to run sf project generate manifest, and the Write tool for the hand-built fallback path. Do NOT use MCP tools.
When This Skill Owns the Task
Use platform-manifest-generate when the work involves any of:
- Building a
package.xmlfrom a source directory (e.g.force-app/main/default/classes/) - Building a manifest from an explicit list of components (e.g.
AccountService,ContactSelector,Account) - Building a manifest by introspecting an org via
--from-org - Producing
destructiveChanges.xml,destructiveChangesPre.xml, ordestructiveChangesPost.xmlfor a deletion - Producing both a
package.xmland a destructive manifest in one operation
Delegate elsewhere when the user is:
- Running the deploy itself →
platform-metadata-deploy - Validating before a prod release →
platform-deploy-validate - Executing the destructive deploy →
platform-destructive-deploy(that skill uses the manifest this skill generates) - Retrieving metadata to local →
platform-metadata-retrieve
Two Generation Paths
Path A — CLI-driven (recommended)
Wrap sf project generate manifest. Always prefer this path; it knows about every metadata type and produces canonical XML — and never emits *, sidestepping the wildcard hazard entirely.
The CLI offers three input modes (mutually exclusive):
| Input | Flag | Use when |
|---|---|---|
| Source directory | --source-dir (-p) | User points to a folder containing already-on-disk metadata |
| Component list | --metadata (-m) | User names specific components, e.g. ApexClass:AccountService CustomObject:Account |
| Org introspection | --from-org | User wants every component currently in an org (or a filtered subset) |
You can specify either --source-dir or --metadata, not both. --from-org may be combined with --metadata (filter included types) or --excluded-metadata (filter out types).
Verified flags (do not invent flags — verify with sf project generate manifest --help if unsure):
| Flag | Purpose |
|---|---|
--source-dir, -p | Local source paths to scan |
--metadata, -m | Component names to include (e.g. ApexClass:AccountService) |
--from-org | Username or alias of org to introspect |
--name, -n | Custom output filename (mutually exclusive with --type) |
--type, -t | Predefined manifest kind: package | pre | post | destroy |
--output-dir, -d | Directory to write the manifest into |
--api-version | Override the API version for the request |
--include-packages, -c | Include managed and/or unlocked package metadata when using --from-org |
--excluded-metadata | Types to exclude when using --from-org |
--json | Machine-readable output |
Manifest filename by --type:
--type | Output file |
|---|---|
package (default) | package.xml |
pre | destructiveChangesPre.xml |
post | destructiveChangesPost.xml |
destroy | destructiveChanges.xml |
You can specify either --type or --name, not both.
Canonical CLI examples
# Build package.xml from a source dir
sf project generate manifest \
--source-dir force-app/main/default \
--name package.xml \
--output-dir manifest \
--json
# Build package.xml from an explicit component list
sf project generate manifest \
--metadata ApexClass:AccountService \
--metadata ApexClass:ContactSelector \
--metadata CustomObject:Account \
--name package.xml \
--output-dir manifest \
--json
# Build destructiveChanges.xml from a component list
sf project generate manifest \
--metadata CustomField:Account.OldField__c \
--metadata CustomField:Account.OldStatus__c \
--type destroy \
--output-dir manifest \
--json
# Build a manifest by introspecting an org (filtered)
sf project generate manifest \
--from-org <alias> \
--metadata ApexClass,CustomObject,CustomLabels \
--output-dir manifest \
--json
If both a package.xml and a destructive manifest are needed, run the CLI twice — once with --type package (or default), once with --type destroy / pre / post.
Path B — Hand-built fallback
Use this only when the CLI cannot express the user's intent — e.g. they want "just the Apex classes I changed today" and the change set is derived from git diff rather than a clean directory or component list. In that case:
- Resolve the components yourself (e.g. parse
git diff --name-onlyand map paths back to metadata types). - Group by metadata type.
- Emit the XML inline using the schema below.
- Always cross-check by running
sf project deploy start --manifest <file> --dry-run(hand off toplatform-metadata-deploy).
Manifest XML schema
Root element is <Package> in the metadata namespace. Each metadata type gets one <types> block containing one <members> per component plus a single <name>. The trailing <version> declares the API version for the manifest.
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>AccountService</members>
<members>ContactSelector</members>
<name>ApexClass</name>
</types>
<types>
<members>Account</members>
<name>CustomObject</name>
</types>
<types>
<members>Account.Status__c</members>
<name>CustomField</name>
</types>
<version>62.0</version>
</Package>
Notes:
- For component-bound types like
CustomField,BusinessProcess,RecordType,Layout,ListView,ValidationRule,WebLink, members useObject.Namenotation. destructiveChanges.xml,destructiveChangesPre.xml, anddestructiveChangesPost.xmluse the same XML structure — only the filename and intent differ.- An empty manifest (no
<types>blocks) is legal and is sometimes paired with a destructive manifest:
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<version>62.0</version>
</Package>
API Version Handling
The <version> element at the bottom of every manifest must reflect the project's API version.
Resolution order:
- Read
sourceApiVersionfromsfdx-project.jsonat the project root. - If
--api-versionwas passed by the user, use that instead. - If neither is available, fall back to the value reported by
sf --version(the CLI's bundled API version) — but warn the user and recommend they setsourceApiVersioninsfdx-project.jsonfor reproducibility. - Never silently hardcode a value (e.g.
62.0) into output without surfacing the source.
# Quick read of sourceApiVersion
jq -r '.sourceApiVersion' sfdx-project.json
When using the CLI path, omit --api-version unless the user explicitly overrides — the CLI already reads sourceApiVersion.
Wildcard Members (<members>*</members>)
A wildcard member matches every component of that metadata type. It is not legal for every type. Using * for a disallowed type causes deploy/retrieve errors like Wildcards are not supported for this metadata type.
Wildcard NOT allowed (must enumerate)
These types require explicit member names. Common examples: Profile, PermissionSet, PermissionSetGroup, CustomLabels, CustomObjectTranslation, Layout, Workflow (in some package configurations), SharingRules, StandardValueSet, ManagedTopics, and most "container" types whose contents are object-bound (CustomField, RecordType, BusinessProcess, ListView, ValidationRule, WebLink, CompactLayout).
For these, enumerate explicitly:
<types>
<members>Admin</members>
<members>Standard User</members>
<name>Profile</name>
</types>
Wildcard generally allowed
Most "self-contained" component types accept *. Examples: ApexClass, ApexTrigger, ApexComponent, ApexPage, AuraDefinitionBundle, LightningComponentBundle, CustomApplication, CustomTab, StaticResource, EmailTemplate, Report, Dashboard, Flow, FlexiPage, CustomMetadata. See references/wildcard-allowlist.md for the full enumeration and edge cases.
Rule of thumb: if you are not certain, list the components explicitly. The CLI path (--source-dir / --metadata) sidesteps this problem because it never emits *.
Examples
Example 1 — Build package.xml from a directory
"Generate package.xml from
force-app/main/default/classes/"
sf project generate manifest \
--source-dir force-app/main/default/classes \
--name package.xml \
--output-dir manifest \
--json
Result: manifest/package.xml listing every Apex class in that folder.
Example 2 — Build a manifest covering specific components
"Build a manifest covering AccountService, ContactSelector, and the Account custom object"
sf project generate manifest \
--metadata ApexClass:AccountService \
--metadata ApexClass:ContactSelector \
--metadata CustomObject:Account \
--name package.xml \
--output-dir manifest \
--json
Result: manifest/package.xml containing exactly those three components.
Example 3 — Generate both package.xml and destructiveChanges.xml for deletions
"Create both package.xml and destructiveChanges.xml for these deletions:
Account.OldField__c,Account.OldStatus__c"
# Empty/minimal package.xml (deletion-only deploy still needs a package descriptor)
sf project generate manifest \
--metadata CustomLabels \
--name package.xml \
--output-dir manifest \
--json
# destructiveChanges.xml
sf project generate manifest \
--metadata CustomField:Account.OldField__c \
--metadata CustomField:Account.OldStatus__c \
--type destroy \
--output-dir manifest \
--json
After generation, hand off to platform-destructive-deploy to validate and execute the deletion.
Failure Modes
| Symptom | Likely cause | Recovery |
|---|---|---|
Path does not exist: <dir> | --source-dir points at a missing folder | Confirm the path; use ls to verify; default to force-app/main/default if the user is vague |
| Generated manifest is empty | Source dir contained no recognizable metadata, or all files were ignored | Check .forceignore; verify the path actually contains metadata files (*.cls, *-meta.xml, etc.) |
Wildcards are not supported for this metadata type at deploy time | Hand-built manifest used * for a disallowed type | See the wildcard allowlist above; enumerate the components explicitly |
<version> missing or mismatched | sfdx-project.json lacks sourceApiVersion | Add sourceApiVersion to sfdx-project.json, or pass --api-version to the CLI |
You can specify either --type or --name, but not both | CLI invocation passed both flags | Drop one; use --type for predefined names, --name for a custom one |
You can specify either --source-dir or --metadata, but not both | CLI invocation passed both | Pick one input mode |
Components missing from --from-org output | Org introspection batched too aggressively, or the type is in a managed package | Set SF_LIST_METADATA_BATCH_SIZE lower; add --include-packages managed if intended |
Cross-Skill Integration
| Need | Delegate to | Reason |
|---|---|---|
| Run a deploy with the generated manifest | platform-metadata-deploy | This skill stops at file generation |
| Validate before a prod release | platform-deploy-validate | Pre-flight test against prod |
| Actually delete the components in the destructive manifest | platform-destructive-deploy | That skill validates and executes the destructive deploy |
| Retrieve metadata listed in the manifest | platform-metadata-retrieve | Pulls org metadata to local |
| Author the metadata being listed in the manifest | Other platform-* generators (e.g. platform-custom-object-generate) | The manifest just lists what already exists on disk |
Completion Format
Manifest goal: <package | pre | post | destroy>
Input mode: <source-dir | metadata list | from-org | hand-built>
Output: <path/to/manifest.xml>
API version: <value> (source: sfdx-project.json | --api-version | CLI default)
Component count: <N> across <M> metadata types
Next step: <platform-metadata-deploy | platform-deploy-validate | platform-destructive-deploy>
FAQ
What does the platform-manifest-generate skill do?
Use to generate a package.xml (and optionally destructiveChanges.xml / Pre / Post) from a source dir, a component list, or org introspection. Trigger on 'generate a package.xml from this folder', 'create a manifest for these classes', 'I need a deploy manifest', or 'destructiveChanges.xml for deletions'. Encodes wildcard-vs-explicit-member rules per metadata type. DO NOT TRIGGER to deploy (platform-metadata-deploy), delete (platform-destructive-deploy), or retrieve (platform-metadata-retrieve).
How do I install platform-manifest-generate?
Run npx skills add https://github.com/forcedotcom/sf-skills --skill platform-manifest-generate in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/platform-manifest-generate/ (personal) or .claude/skills/platform-manifest-generate/ (project).
Which AI agents can use platform-manifest-generate?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is platform-manifest-generate safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains platform-manifest-generate?
It is published by forcedotcom in forcedotcom/sf-skills. It has 2,991 recorded installs.
More from forcedotcom/sf-skills
platform-apex-generate
forcedotcom/sf-skills
Primary Apex authoring skill for class generation, refactoring, and review. ALWAYS ACTIVATE when the user mentions Apex, .cls, triggers, or asks to create/refactor a class (service, selector, domain, batch, queueable, schedulable, invocable, DTO, utility, interface, abstract, exception, REST resource). Use this skill for requests involving SObject CRUD, mapping collections, fetching related records, scheduled jobs, batch jobs, trigger design, @AuraEnabled controllers, @RestResource endpoints, custom REST APIs, or code review of existing Apex.
platform-apex-test-generate
forcedotcom/sf-skills
Use to generate and validate Apex test classes with TestDataFactory patterns, bulk testing (251+ records), mocking, assertions, and disciplined test-fix loops. Use when creating Apex test classes (for triggers, services, controllers, batch jobs, queueables, and callouts), improving coverage, debugging or fixing failing Apex tests, or running test/coverage analysis. Triggers on Test.cls files, sf apex run test, coverage reports. Do NOT trigger for production Apex (use platform-apex-generate) or Jest/LWC tests.
platform-apex-test-run
forcedotcom/sf-skills
Apex test execution, coverage analysis, and test-fix loops with 120-point scoring. Use when the user runs Apex tests, checks code coverage, fixes failing tests, or touches Test.cls / Test.cls files. DO NOT TRIGGER when writing Apex production code (use platform-apex-generate), Agentforce agent testing (use agentforce-test), or Jest/LWC tests (use experience-lwc-generate).
platform-apex-logs-debug
forcedotcom/sf-skills
Salesforce debug log analysis and troubleshooting with 100-point scoring. TRIGGER when: user analyzes debug logs, hits governor limits, reads stack traces, or touches .log files from Salesforce orgs. DO NOT TRIGGER when: running Apex tests (use platform-apex-test-run), generating or fixing Apex code (use platform-apex-generate), or Agentforce session tracing (use agentforce-observe).
platform-soql-query
forcedotcom/sf-skills
Use when the user needs SOQL/SOSL authoring or optimization: natural-language-to-query generation, relationship queries, aggregates, query-plan/selectivity analysis, and performance or safety improvements. TRIGGER when the user writes, optimizes, or debugs SOQL/SOSL, touches .soql files, or asks about relationship queries, aggregates, or query performance. DO NOT TRIGGER for bulk data operations (use platform-data-manage), Apex DML logic (use platform-apex-generate), or report/dashboard queries.
platform-metadata-deploy
forcedotcom/sf-skills
Salesforce DevOps automation using sf CLI v2. TRIGGER when: user deploys metadata, validates a deploy or does a dry-run, deploys to a Production org, quick-deploys a validated job ID, ships/promotes to prod, creates/manages scratch orgs or sandboxes, sets up CI/CD pipelines, or troubleshoots deployment errors with sf project deploy. DO NOT TRIGGER when: writing Apex code, building LWC components (use experience-lwc-generate), creating metadata definitions (use platform-custom-object-generate), deleting metadata from an org (use platform-destructive-deploy), or querying org data (use platform-data-manage).
Popular devops & cloud skills
microsoft-foundry
microsoft/azure-skills
Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure
azure-diagnostics
microsoft/azure-skills
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
azure-prepare
microsoft/azure-skills
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
azure-ai
microsoft/azure-skills
Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.
azure-deploy
microsoft/azure-skills
Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.
azure-validate
microsoft/azure-skills
Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.