sf-metadata: Salesforce Metadata Generation and Org Querying
Use this skill when the user needs metadata definition or org metadata discovery: custom objects, fields, validation rules, record types, page layouts, permission sets, or schema inspection with sf CLI.
When This Skill Owns the Task
Use sf-metadata when the work involves:
- object, field, validation rule, record type, layout, profile, or permission-set metadata
.object-meta.xml,.field-meta.xml,.profile-meta.xml, and related metadata files- describing schema before coding or Flow work
- generating metadata XML from requirements
Delegate elsewhere when the user is:
- analyzing permission access rather than defining metadata → sf-permissions
- deploying metadata → sf-deploy
- editing Flow XML → sf-flow
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 permission-set or FLS follow-up will be needed
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.
3. Validate metadata quality
Check:
- naming conventions
- structural correctness
- field-type fit
- security / FLS implications
- downstream deployment dependencies
4. Plan permission impact
When new fields or objects are created, account for permission-set follow-up and layout visibility.
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
- prefer permission sets over profile-centric access patterns
- 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>Cross-Skill Integration
| Need | Delegate to | Reason |
|---|---|---|
| deploy metadata | sf-deploy | rollout and validation |
| build Flows on new schema | sf-flow | declarative automation |
| build Apex on new schema | sf-apex | code against metadata |
| analyze permission access after creation | sf-permissions | access auditing |
| seed data after deploy | sf-data | test data creation |
Reference Map
Start here
- references/field-and-cli-reference.md
- references/metadata-types-reference.md
- references/naming-conventions.md
- references/orchestration.md
Security / scoring / examples
- references/fls-best-practices.md
- references/permset-auto-generation.md
- references/best-practices-scoring.md
- references/field-types-guide.md
- references/field-types-example.md
- references/custom-object-example.md
- references/permission-set-example.md
- references/profile-permission-guide.md
- references/sf-cli-commands.md
- assets/
Score Guide
| Score | Meaning |
|---|---|
| 108+ | strong production-ready metadata |
| 96–107 | good metadata with minor review items |
| 84–95 | acceptable but validate carefully |
| < 84 | block deployment until corrected |