SKILL.md

$27

Required Context to Gather First

Ask for or infer:

whether the user wants generation or querying

metadata type(s) involved

target object / field / package directory

target org alias if querying is required

whether new custom objects or fields should also include permission-set / FLS generation

Unless the user explicitly opts out, assume new custom objects or fields need permission-set follow-up.

Recommended Workflow

1. Choose the mode

Mode

Use when

generation

the user wants new or updated metadata XML

querying

the user needs object / field / metadata discovery

2. Start from templates or CLI describe data

For generation, use the assets under:

assets/objects/

assets/fields/

assets/permission-sets/

assets/profiles/

assets/record-types/

assets/validation-rules/

assets/layouts/

For querying, prefer sf metadata and sobject describe commands.

Recent SDR/CLI support worth knowing when reading older examples: CnfgItemSourceDefinition, ExtlClntAppOauthSecuritySettings, and UIBundle are now source-supported under their current names. See references/metadata-types-reference.md.

3. Validate metadata quality

Check:

naming conventions

structural correctness

field-type fit

security / FLS implications

downstream deployment dependencies

4. Plan permission impact by default

When new custom fields or objects are created:

default to generating or updating a Permission Set unless the user opts out

include fieldPermissions for eligible custom fields

note any metadata categories that are excluded because Salesforce treats them as system-managed or always-available

remember that object CRUD alone does not make custom fields visible

5. Hand off deployment

Use sf-deploy when the user needs the metadata rolled out.

High-Signal Rules

field-level security is often the hidden blocker after deployment

object permissions ≠ field permissions

prefer permission sets over profile-centric access patterns

generate Permission Set follow-up by default for new custom objects and fields

include fieldPermissions for eligible custom fields instead of leaving FLS as a manual afterthought

avoid hardcoded IDs in formulas or metadata logic

validation rules should have intentional bypass strategy when operationally necessary

create metadata before attempting Flow or data tasks that depend on it

Output Format

When finishing, report in this order:

Metadata created or queried

Files created or updated

Key schema/security decisions

Permission / layout follow-ups

Deploy next step

Suggested shape:

Metadata task: <generate / query>

Items: <objects, fields, rules, layouts, permsets>

Files: <paths>

Notes: <naming, field types, security, dependencies>

Next step: <deploy, assign permset, or verify in Setup>