Use this skill when users need to create, generate, or validate Salesforce Custom Object metadata. Trigger when users mention custom objects, creating objects, object metadata, .object files, sharing models, name fields, or validation rules on objects. Also use when users say things like "create a c

When to Use This Skill Use this skill when you need to: Create new custom objects Generate custom object metadata XML Configure object sharing and security settings Set up object features and capabilities Troubleshoot deployment errors related to custom objects Add, update, or delete a field OR a validation rule on an existing object — any of these may make the object's <description stale, so you must refresh it (propose + confirm). This applies equally to validation rule changes, not just fields. See Section 3.B. Specification 1. Overview and Purpose This document defines the mandatory constraints for generating CustomObject metadata XML ( .object meta.xml file). The agent must verify these constraints before outputting XML to prevent Metadata API deployment errors. File extension: .object meta.xml Description freshness — applies to EVERY object change, fields AND validation rules: Whenever you add, update, or delete a field or a validation rule on an object, the <description may now be stale. Before finishing, refresh it per Section 3.B (propose, confirm with the user, write). A validation rule change counts exactly like a field change — the change is not done until the description has been reconciled. This is easy to forget on validation rule edits/deletes — don't. 2. Syntactic Essentials (Tier 1) The following constraints must be true for the XML body to deploy successfully. Note: The API Name (fullName) is NOT a tag; it is the filename (e.g., Vehicle c.object meta.xml ). Required Elements Element Requirement Notes <label Required Singular UI name <pluralLabel Required Plural UI name <sharingModel Required See Sharing Model Rules below <deploymentStatus Required Always set to Deployed <nameField Required Primary record identifier (requires <label and <type ) <visibility Required Always set to Public Sharing Model Rules Default: Set <sharingModel to ReadWrite . Exception: If this object contains a Master Detail relationship field, <sharingModel MUST be ControlledByParent . Decision Logic: IF object has NO Master Detail field → use ReadWrite IF object has Master Detail field → use ControlledByParent IF a Master Detail field is being added to an existing child object → that existing object's <sharingModel must also be updated to ControlledByParent INCORRECT — Will cause error: Cannot set sharingModel to ReadWrite on a CustomObject with a MasterDetail relationship field CORRECT: 3. Smart Defaults & Decision Logic (Tier 2) The agent must choose which features to enable based on the object's intended use case. A. The Name Field Decision Type When to Use Additional Requirements Text Default for human named entities (Projects, Locations, Teams) None AutoNumber Use for transactions, logs, or IDs (Invoices, Requests, Tickets) Must include <displayFormat (e.g., INV {0000} ) and <startingNumber 1</startingNumber Text Name Field Example: AutoNumber Name Field Example: B. Object Description (Enrichment) <description : Mandatory — every Custom Object MUST have one. It must read like human written documentation, never a generic template ("Object used to track and manage...") or a metadata dump ("Contains 8 fields including Project Name c ..."). Always compose an enriched description — when creating the object, and again on any change to it: adding, updating, or deleting a field or a validation rule (so it never goes stale). The change — field or validation rule — is never "done" until you've refreshed the object's description. This is not optional; do not ask whether to add a description. Confirm per change — every time. Propose and confirm on each field/rule change separately. A previous "keep current" applies only to that one change; it is never standing permission to skip the proposal on a later change. Do not infer a preference from an earlier answer — re propose and re ask for every new change. Compose the description (steps below). If the object already has one, use it as a strong signal — preserve the business context it carries (domain, team, intent the schema can't reveal) and fold the new field/rule in rather than discarding it. Then branch on whether a description already exists: No existing description (brand new object): there is nothing to overwrite — just write the composed description. Do not prompt. An existing description (update, delete, or any re enrichment): never overwrite it silently — you can't tell from the file whether it was hand written by an admin or generated earlier. Show the proposal, ask, and STOP — wait for the user's reply before writing: Proposed description for {Object} : <the enriched description Current: <the existing description Use this? (yes / keep current / edit) You MUST NOT write the <description until the user replies — showing the diff is not approval, even when the change looks obvious or minor. Then act: yes → write the proposed text · keep current → leave the existing one untouched (this applies to this change only — re propose on the next one) · edit → use the user's wording. Always end with a <description written. Composing the description: 1. Classify each field by how it appears in the description: Constrained (required, unique, externalId, restricted picklist) → selective parenthetical: VIN (required, external ID) , Color (Red/Green only) Behavioral (formula, roll up) → describe what it computes: "the Age Years field auto calculates vehicle age" Relationship (master detail, lookup) → woven context: "as a child of Account" (never "(Master Detail to Account)") Standard → label only 2. Compose in this order, using field labels not API names : Purpose → key fields → computed fields → validation rules (as business rules) → "Commonly used for {use cases}." 3. Count and trim before writing (required): count the words; aim ~45, hard ceiling 50. If over, tighten wording first, then drop whole sentences in priority order (use cases → rules → computed; never drop sentences 1–2). Recount. Do not write until ≤ 50. Example (Car, 46 words): → For the full workflow and examples, read references/description enrichment.md . C. Junction Object Naming If the object is a many to many link between two parents, name the object by combining the two parent entities to ensure the schema remains intuitive. Examples: Position Candidate c (links Position and Candidate) Job Application c (links Job and Application) D. Feature Enablement (Clean XML) To maintain "Clean XML," only include optional tags when deviating from the Salesforce platform default of false . Scenario A: User Facing Objects (Apps, Trackers, Business Entities) Trigger: The object is intended for direct user interaction Action: Set <enableSearch , <enableReports , <enableActivities , and <enableHistory to true Scenario B: System Facing Objects (Junctions, Background Logs) Trigger: The object exists for technical associations or background data Action: Omit these tags to keep the UI clean and the XML lean 4. Critical Constraints & Common Failures Reserved Words Never use reserved words as API names for Custom Objects or Custom Fields: Category Reserved Words (Do Not Use as API Names) SOQL/SQL Select , From , Where , Limit , Order , Group System User , External , View , Type Temporal Date , Number Relationship Cap Do not create more than 2 Master Detail relationships for a single object. If a third relationship is required, use a Lookup instead. XML Root Element Do NOT include the <fullName tag at the root of the .object meta.xml file. The API name is derived from the filename. INCORRECT: CORRECT: Validation Rule Naming Convention Validation rule names follow different conventions than custom fields. Rules: Must contain only alphanumeric characters and underscores Must begin with a letter Cannot end with an underscore Cannot contain two consecutive underscores Must NOT end with c (unlike custom fields) INCORRECT: Error: The validation name can only contain alphanumeric characters, must begin with a letter, cannot end with an underscore... CORRECT: Naming Pattern Reference: Metadata Type Naming Pattern Example Custom Fields Ends with c Start Date c Validation Rules No suffix Require Start Date Custom Objects Ends with c Vehicle c 5. Verification Checklist Before generating the Custom Object XML, verify: Syntactic Checks [ ] Are both <label and <pluralLabel present? [ ] Is <deploymentStatus set to Deployed ? [ ] Is <visibility set to Public ? [ ] Does <nameField include both <label and <type ? [ ] If <type is AutoNumber , are <displayFormat and <startingNumber included? Sharing Model Check (Critical) [ ] Does this object have a Master Detail relationship field? If YES → <sharingModel MUST be ControlledByParent If NO → <sharingModel should be ReadWrite Constraint Checks [ ] Is the API name free of reserved words? [ ] Are there 2 or fewer Master Detail relationships? [ ] Is <fullName absent from the XML root? Validation Rule Checks (if applicable) [ ] Do validation rule names NOT end with c ? [ ] Do validation rule names follow alphanumeric + underscore pattern? Description Enrichment Quality Checks [ ] Opens with "The {Object} object..." + business purpose (not "Object used to track and manage...") [ ] Uses field labels , never API names; no "Contains N fields including" dump [ ] Formulas/rollups described by behavior; validations stated as business rules; relationships as context [ ] Includes common use cases ("Commonly used for...") and is under 50 words [ ] Folded any current description's business context into the proposed one (didn't discard it) [ ] For an existing description (update/delete/re enrich), STOPPED and waited for the user's reply before writing — did not treat showing the diff as approval Architectural Checks [ ] Is <description present? (Enriched per Section B — proposed and confirmed with the user before writing.) [ ] Are <enableSearch and <enableReports set to true if user facing? [ ] Does the filename match the intended API name? Reference File Index File When to read references/description enrichment.md Composing or refreshing an object's <description (on create, or when a field/rule changes) — full enrichment workflow, field prioritization tiers, junction/child handling, edge cases, and more examples

platform-custom-object-generate