/platform-manifest-generate

name: platform-manifest-generate
description: "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)."
metadata:
  version: "1.0"
  relatedSkills:
    - "platform-metadata-deploy"
    - "platform-metadata-retrieve"
    - "platform-destructive-deploy"
  cliTools:
    - tool: ["sf"]
      semver: ">=2.0.0"

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.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-metadata-deploy` (production path)
• 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:

1. Resolve the components yourself (e.g. parse `git diff --name-only` and map paths back to metadata types). 2. Group by metadata type. 3. Emit the XML inline using the schema below. 4. Always cross-check by running `sf project deploy start --manifest <file> --dry-run` (hand off to `platform-metadata-deploy`).

Manifest XML schema

Root element is `<Package>` in the metadata namespace. Each metadata type gets one `<types>` block containing one `<m