platform-manifest-generate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

platform-destructive-deploy

once the file exists.

从本地源、组织或明确的组件列表生成Salesforce元数据清单——

package.xml

（或其中一种破坏性变体）。本Skill仅负责创建清单文件。文件生成完成后，可移交至

platform-metadata-deploy

或

platform-destructive-deploy

进行后续操作。

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.

仅可使用Bash工具运行

sf project generate manifest

，手动构建备选路径时使用

Write

工具。请勿使用MCP工具。

When This Skill Owns the Task

本Skill负责的任务场景

Use

platform-manifest-generate

when the work involves any of:

Building a

package.xml

from 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

, or

destructiveChangesPost.xml

for a deletion

Producing both a
```
package.xml
```
and 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
```

当工作涉及以下任一内容时，使用

platform-manifest-generate

：

从源目录构建

package.xml

（例如

force-app/main/default/classes/

）

从明确的组件列表构建清单（例如
```
AccountService
```
、
```
ContactSelector
```
、
```
Account
```
）
通过
```
--from-org
```
参数从组织内省构建清单

为删除操作生成

destructiveChanges.xml

、

destructiveChangesPre.xml

或

destructiveChangesPost.xml

一次操作同时生成
```
package.xml
```
和破坏性清单

当用户需要以下操作时，请移交至其他Skill：

执行部署本身 →
```
platform-metadata-deploy
```
生产环境发布前验证 →
```
platform-deploy-validate
```
执行破坏性部署 →
```
platform-destructive-deploy
```
（该Skill会使用本Skill生成的清单）
将元数据检索到本地 →
```
platform-metadata-retrieve
```

Two Generation Paths

两种生成路径

Path A — CLI-driven (recommended)

路径A — CLI驱动（推荐）

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

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

--name

, not both.

封装

sf project generate manifest

命令。请优先使用此路径；它了解所有元数据类型，可生成标准XML，且绝不会输出

，完全规避了通配符风险。

CLI提供三种互斥的输入模式：

输入类型	参数	使用场景
源目录	`--source-dir` （ `-p` ）	用户指向包含已存储在磁盘上元数据的文件夹
组件列表	`--metadata` （ `-m` ）	用户指定具体组件，例如 `ApexClass:AccountService CustomObject:Account`
组织内省	`--from-org`	用户需要获取组织中当前的所有组件（或筛选后的子集）

你只能指定

--source-dir

或

--metadata

中的一个，不能同时指定。

--from-org

可与

--metadata

（筛选包含的类型）或

--excluded-metadata

（筛选排除的类型）结合使用。

已验证的参数（请勿自行发明参数——如有疑问，请通过

sf project generate manifest --help

验证）：

参数	用途
`--source-dir` , `-p`	要扫描的本地源路径
`--metadata` , `-m`	要包含的组件名称（例如 `ApexClass:AccountService` ）
`--from-org`	要内省的组织的用户名或别名
`--name` , `-n`	自定义输出文件名（与 `--type` 互斥）
`--type` , `-t`	预定义的清单类型： `package` \| `pre` \| `post` \| `destroy`
`--output-dir` , `-d`	写入清单的目录
`--api-version`	覆盖请求的API版本
`--include-packages` , `-c`	使用 `--from-org` 时，包含 `managed` 和/或 `unlocked` 包元数据
`--excluded-metadata`	使用 `--from-org` 时，要排除的类型
`--json`	机器可读的输出格式

按
--type
划分的清单文件名：

`--type`	输出文件
`package` （默认）	`package.xml`
`pre`	`destructiveChangesPre.xml`
`post`	`destructiveChangesPost.xml`
`destroy`	`destructiveChanges.xml`

你只能指定

--type

或

--name

中的一个，不能同时指定。

Canonical CLI examples

标准CLI示例

bash

undefined

bash

undefined

Build package.xml from a source dir

从源目录构建package.xml

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

从明确的组件列表构建package.xml

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

从组件列表构建destructiveChanges.xml

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`.

sf project generate manifest
--from-org <alias>
--metadata ApexClass,CustomObject,CustomLabels
--output-dir manifest
--json


如果同时需要`package.xml`和破坏性清单，请运行两次CLI——一次使用`--type package`（或默认），一次使用`--type destroy`/`pre`/`post`。

Path B — Hand-built fallback

路径B — 手动构建备选方案

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-only
```
and 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 to

platform-metadata-deploy

仅当CLI无法表达用户意图时使用此路径——例如，用户需要“仅包含我今天修改的Apex类”，且变更集来自

git diff

而非整洁的目录或组件列表。这种情况下：

自行解析组件（例如解析
```
git diff --name-only
```
的结果，并将路径映射回元数据类型）。
按元数据类型分组。
使用以下架构内联生成XML。

务必通过运行

sf project deploy start --manifest <file> --dry-run

进行交叉检查（移交至

platform-metadata-deploy

）。

Manifest XML schema

清单XML架构

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

<?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 use

Object.Name

notation.

destructiveChanges.xml

destructiveChangesPre.xml

, and

destructiveChangesPost.xml

use 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

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <version>62.0</version>
</Package>

根元素是元数据命名空间中的

<Package>

。每个元数据类型对应一个

<types>

块，包含每个组件的

<members>

元素以及一个

<name>

元素。末尾的

<version>

元素声明清单的API版本。

xml

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

注意事项：

对于
```
CustomField
```
、
```
BusinessProcess
```
、
```
RecordType
```
、
```
Layout
```
、
```
ListView
```
、
```
ValidationRule
```
、
```
WebLink
```
等绑定到对象的组件类型，成员需使用
```
Object.Name
```
格式。

destructiveChanges.xml

、

destructiveChangesPre.xml

和

destructiveChangesPost.xml

使用相同的XML结构——仅文件名和用途不同。

空清单（无
```
<types>
```
块）是合法的，有时会与破坏性清单配合使用：

xml

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <version>62.0</version>
</Package>

API Version Handling

API版本处理

The

<version>

element at the bottom of every manifest must reflect the project's API version.

Resolution order:

Read
```
sourceApiVersion
```
from
```
sfdx-project.json
```
at the project root.
If
```
--api-version
```
was 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 set
```
sourceApiVersion
```
in
```
sfdx-project.json
```
for reproducibility.
Never silently hardcode a value (e.g.
```
62.0
```
) into output without surfacing the source.

bash

undefined

每个清单底部的

<version>

元素必须反映项目的API版本。

解析顺序：

从项目根目录的
```
sfdx-project.json
```
中读取
```
sourceApiVersion
```
。
如果用户传入了
```
--api-version
```
参数，则使用该参数值。
如果以上两者都不可用，则回退到
```
sf --version
```
报告的值（CLI捆绑的API版本）——但需警告用户，并建议他们在
```
sfdx-project.json
```
中设置
```
sourceApiVersion
```
以确保可重复性。
切勿在未告知来源的情况下，将值（例如
```
62.0
```
）静默硬编码到输出中。

bash

undefined

Quick read of sourceApiVersion

快速读取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`.

---

jq -r '.sourceApiVersion' sfdx-project.json


使用CLI路径时，除非用户明确覆盖，否则省略`--api-version`参数——CLI会自动读取`sourceApiVersion`。

---

Wildcard Members (

<members>*</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

通配符成员匹配该元数据类型的所有组件。并非所有类型都支持通配符。对不支持的类型使用

会导致部署/检索错误，例如

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:

xml

<types>
    <members>Admin</members>
    <members>Standard User</members>
    <name>Profile</name>
</types>

这些类型需要明确的成员名称。常见示例：

Profile

、

PermissionSet

、

PermissionSetGroup

、

CustomLabels

、

CustomObjectTranslation

、

Layout

、

Workflow

（在某些包配置中）、

SharingRules

、

StandardValueSet

、

ManagedTopics

，以及大多数内容绑定到对象的“容器”类型（

CustomField

、

RecordType

、

BusinessProcess

、

ListView

、

ValidationRule

、

WebLink

、

CompactLayout

）。

对于这些类型，请明确枚举：

xml

<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

大多数“独立”组件类型支持

。示例：

ApexClass

、

ApexTrigger

、

ApexComponent

、

ApexPage

、

AuraDefinitionBundle

、

LightningComponentBundle

、

CustomApplication

、

CustomTab

、

StaticResource

、

EmailTemplate

、

Report

、

Dashboard

、

Flow

、

FlexiPage

、

CustomMetadata

。完整枚举和边缘情况请参见references/wildcard-allowlist.md。

经验法则：如果不确定，请明确列出组件。CLI路径（

--source-dir

--metadata

）不会输出

，因此可规避此问题。

Examples

示例

Example 1 — Build

package.xml

from a directory

示例1 — 从目录构建

package.xml

"Generate package.xml from
force-app/main/default/classes/
"

bash

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.

“从
force-app/main/default/classes/
生成package.xml”

bash

sf project generate manifest \
  --source-dir force-app/main/default/classes \
  --name package.xml \
  --output-dir manifest \
  --json

结果：

manifest/package.xml

列出该文件夹中的所有Apex类。

Example 2 — Build a manifest covering specific components

示例2 — 构建包含特定组件的清单

"Build a manifest covering AccountService, ContactSelector, and the Account custom object"

bash

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.

“构建包含AccountService、ContactSelector和Account自定义对象的清单”

bash

sf project generate manifest \
  --metadata ApexClass:AccountService \
  --metadata ApexClass:ContactSelector \
  --metadata CustomObject:Account \
  --name package.xml \
  --output-dir manifest \
  --json

结果：

manifest/package.xml

仅包含这三个组件。

Example 3 — Generate both

package.xml

and

destructiveChanges.xml

for deletions

示例3 — 为删除操作同时生成

package.xml

和

destructiveChanges.xml

"Create both package.xml and destructiveChanges.xml for these deletions:
Account.OldField__c
,
Account.OldStatus__c
"

bash

undefined

“为以下删除操作同时创建package.xml和destructiveChanges.xml：
Account.OldField__c
、
Account.OldStatus__c
”

bash

undefined

Empty/minimal package.xml (deletion-only deploy still needs a package descriptor)

空/最小化package.xml（仅删除的部署仍需要包描述符）

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.

---

sf project generate manifest
--metadata CustomField:Account.OldField__c
--metadata CustomField:Account.OldStatus__c
--type destroy
--output-dir manifest
--json


生成完成后，移交至`platform-destructive-deploy`进行验证和执行删除操作。

---

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

症状	可能原因	解决方法
`Path does not exist: <dir>`	`--source-dir` 指向不存在的文件夹	确认路径；使用 `ls` 验证；如果用户表述模糊，默认使用 `force-app/main/default`
生成的清单为空	源目录中没有可识别的元数据，或所有文件都被忽略	检查 `.forceignore` ；验证路径中是否确实包含元数据文件（ `.cls` 、 `-meta.xml` 等）
部署时出现 `Wildcards are not supported for this metadata type`	手动构建的清单对不支持的类型使用了 `*`	参见上方的通配符允许列表；明确枚举组件
`<version>` 缺失或不匹配	`sfdx-project.json` 中缺少 `sourceApiVersion`	在 `sfdx-project.json` 中添加 `sourceApiVersion` ，或向CLI传递 `--api-version` 参数
`You can specify either --type or --name, but not both`	CLI调用同时传递了两个参数	删除其中一个；使用 `--type` 指定预定义名称，使用 `--name` 指定自定义名称
`You can specify either --source-dir or --metadata, but not both`	CLI调用同时传递了两个参数	选择一种输入模式
`--from-org` 输出中缺少组件	组织内省的批处理过于激进，或类型属于托管包	降低 `SF_LIST_METADATA_BATCH_SIZE` 的值；如果需要，添加 `--include-packages managed` 参数

Cross-Skill Integration

跨Skill集成

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

需求	移交至	原因
使用生成的清单执行部署	`platform-metadata-deploy`	本Skill仅负责文件生成
生产环境发布前验证	`platform-deploy-validate`	针对生产环境进行预发布测试
实际删除破坏性清单中的组件	`platform-destructive-deploy`	该Skill负责验证并执行破坏性部署
检索清单中列出的元数据到本地	`platform-metadata-retrieve`	将组织元数据拉取到本地
创建清单中列出的元数据	其他 `platform-*` 生成器（例如 `platform-custom-object-generate` ）	清单仅列出磁盘上已存在的内容

Completion Format

完成格式

text

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>

text

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>

platform-manifest-generate

Original

Translation

platform-manifest-generate

platform-manifest-generate

Tool Restrictions

工具限制

When This Skill Owns the Task

本Skill负责的任务场景

Two Generation Paths

两种生成路径

Path A — CLI-driven (recommended)

路径A — CLI驱动（推荐）

Canonical CLI examples

标准CLI示例

Build package.xml from a source dir

从源目录构建package.xml

Build package.xml from an explicit component list

从明确的组件列表构建package.xml

Build destructiveChanges.xml from a component list

从组件列表构建destructiveChanges.xml

Build a manifest by introspecting an org (filtered)

通过内省组织构建筛选后的清单

Path B — Hand-built fallback

路径B — 手动构建备选方案

Manifest XML schema

清单XML架构

API Version Handling

API版本处理

Quick read of sourceApiVersion

快速读取sourceApiVersion

Wildcard Members (<members>*</members>)

通配符成员（<members>*</members>）

Wildcard NOT allowed (must enumerate)

不允许使用通配符（必须枚举）

Wildcard generally allowed

通常允许使用通配符

Examples

示例

Example 1 — Build package.xml from a directory

示例1 — 从目录构建package.xml

Example 2 — Build a manifest covering specific components

示例2 — 构建包含特定组件的清单

Example 3 — Generate both package.xml and destructiveChanges.xml for deletions

示例3 — 为删除操作同时生成package.xml和destructiveChanges.xml

Empty/minimal package.xml (deletion-only deploy still needs a package descriptor)

空/最小化package.xml（仅删除的部署仍需要包描述符）

destructiveChanges.xml

destructiveChanges.xml

Failure Modes

故障模式

Cross-Skill Integration

跨Skill集成

Completion Format

完成格式

Wildcard Members (
`<members>*</members>`
)

通配符成员（
`<members>*</members>`
）

Example 1 — Build
`package.xml`
from a directory

示例1 — 从目录构建
`package.xml`

Example 3 — Generate both
`package.xml`
and
`destructiveChanges.xml`
for deletions

示例3 — 为删除操作同时生成
`package.xml`
和
`destructiveChanges.xml`