@salesforce/afv-skills 1.21.0 → 1.23.0

package/skills/platform-custom-lightning-type-generate/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: platform-custom-lightning-type-generate
+description: "Use this skill when users need to create Custom Lightning Types (CLTs) for Einstein Agent actions or structured input/output schemas. Trigger when users mention CLT, Custom Lightning Types, Custom Lightning Types (CLTs) with widget/mosaic/fragment rendition/renderer, JSON schemas for agents, type definitions, lightning__objectType, or editor/renderer configurations. When widget renditions are requested, you MUST first read the widget-rendition.md reference file in this skill's references/ directory and follow its complete workflow. This is complex - always use this skill for CLT work."
+metadata:
+  version: "1.0"
+---
+
+## When to Use This Skill
+
+Use this skill when you need to:
+- Create Custom Lightning Types (CLTs) for structured inputs/outputs
+- Generate JSON Schema-based type definitions for Lightning Platform
+- Configure CLTs for Einstein Agent actions
+- Set up editor and renderer configurations for custom UI
+- Create CLTs with widget/mosaic/fragment rendition
+- Troubleshoot deployment errors related to Custom Lightning Types
+
+## Specification
+
+# CustomLightningType Metadata Specification
+
+## Overview & Purpose
+Custom Lightning Types (CLTs) are JSON Schema-based type definitions used by the Lightning Platform (including Einstein Agent actions) to describe structured inputs/outputs and drive editor/renderer experiences.
+
+## Configuration
+- **Choose referenced CLT pattern for nested objects** - When you need a **reusable** or **separately deployed** nested type, create a CLT for that shape and reference it with `"lightning:type": "c__<CLTName>"`. That string is the referenced type’s **`lightning:type` value / FQN / registered identifier** — not the JSON Schema `title`.
+- **Choose standard Lightning types** when the structure is simple and can be expressed with properties and supported primitive `lightning:type` identifiers.
+- **Choose Apex class types** (`@apexClassType/...`) when the structure already exists server-side and you want the Apex class to define the shape.
+- **Include editor/renderer config** only when you need custom UI behavior (custom LWC input/output components). Otherwise, omit.
+
+## Critical Rules (Read First)
+- **CRITICAL: NEVER include the `"$schema"` field in schema.json**
+  - Salesforce CLT validator WILL REJECT schemas with this field, even if it's a valid JSON Schema `$schema` declaration.
+- **Root object schemas MUST include**:
+  - `"type": "object"`
+  - `"title"`
+  - `"lightning:type": "lightning__objectType"`
+  - `"unevaluatedProperties": false`
+- `"unevaluatedProperties"` is enforced as `false` by the CLT metaschema. Do not set it to `true`.
+- **Root object schemas MUST NOT include** `"examples"` when `"unevaluatedProperties": false` is set.
+- **Nested objects (inside `properties`) MUST NOT set** `"lightning:type": "lightning__objectType"`.
+    - Nested objects can be: references to other CLTs using `c__<CLTName>` syntax.
+- **List/array properties are highly restricted by the CLT metaschema**:
+  - **CRITICAL LIMITATION**: the CLT metaschema may reject the `items` keyword entirely. Treat `items` as **disallowed by default**.
+  - **Root-level arrays** (direct children of the root `properties`):
+    - **MUST include** `"lightning:type": "lightning__listType"`
+    - **MUST NOT include** `"items"`
+    - **OPTIONAL** `"type": "array"`
+  - **Nested arrays** (arrays inside nested objects) are the most common failure:
+    - **MUST include** `"type": "array"`
+    - **MUST NOT include** `"lightning:type": "lightning__listType"`
+    - **MUST NOT include** `"items"`
+- **When `"unevaluatedProperties": false` is set, any unknown keyword will fail validation**. Prefer removing keywords over relaxing strictness.
+- **Apex class CLTs are minimal**:
+  - Include **only** `title`, `description` (optional), and `lightning:type` set to `@apexClassType/...`.
+  - Do **not** add `type`, `properties`, `required`, or `unevaluatedProperties`.
+
+## Additional CLT Metaschema Validations
+- **Org namespace validation**: titles/descriptions and other string fields may be validated to ensure you are not using an org namespace in places that are disallowed.
+- **Lightning type validation**: CLTs are validated to prevent referencing internal namespaces (for example, disallowing types from internal namespaces like `sfdc_cms` where not permitted).
+- **Object type validation**: the CLT root is validated to ensure `lightning:type` is exactly `lightning__objectType`.
+
+## Primitive Types & Constraints
+
+When you need the full list of supported primitive `lightning:type` identifiers, their constraints, and the allowed property-level keywords, read `assets/primitive-types-and-constraints.md` in this skill's directory.
+
+## Generation Workflow
+1. **Confirm the CLT approach**
+   - If referencing Apex: capture the exact class reference (`@apexClassType/namespace__ClassName$InnerClass`).
+   - If using standard primitives: list the fields, their Lightning primitive types, and which fields are required.
+2. **Draft `schema.json`**
+   - **DO NOT include `"$schema"` at the top**
+   - Start with the root object structure (required root fields).
+   - Add `properties` using valid primitive `lightning:type` identifiers.
+   - For nested-object properties, use **CLT Reference pattern**:
+     - `"lightning:type": "c__<CLTName>"` to reference another CLT
+     - The referenced CLT must be deployed to the org before the parent CLT.
+   - For Apex-based nested objects: Use `@apexClassType/...` when structure exists server-side.
+   - If the prompt explicitly requires true nested object output, prefer an **Apex-based CLT** (`@apexClassType/...`) for deploy-safe nested structures.
+   - For arrays: follow the strict list rules (avoid `items`; avoid `lightning:type` on nested arrays).
+   - Before deployment, verify exact `lightning:type` spellings (for example, use `lightning__richTextType`, not misspelled variants).
+3. **(Optional) Draft `editor.json`** (only if custom UI is required)
+   - **Supported shape:** Top-level `editor` object with `editor.componentOverrides` and `editor.layout`.
+     - Top-level `editor` object.
+     - Use `editor.componentOverrides` for component overrides.
+     - Use `editor.layout` for layout.
+     - **DEPRECATED**: Do NOT use `propertyRenderers` or `view` — these are legacy keys. Always use `componentOverrides` and `layout` instead.
+   - **Root override pattern** (most common for fully custom editing UI):
+     - `editor.componentOverrides["$"] = { "definition": "c/<yourEditorComponent>", "attributes": { ... } }`
+     - When passing schema data into a custom LWC, use attribute mapping with the `{!$attrs.<name>}` syntax: e.g. `"attributes": { "myField": "{!$attrs.value}" }` so the runtime binds schema values to your component's attributes.
+     - **CRITICAL**: The `<name>` in `{!$attrs.<name>}` must be a property defined in your type schema. For example, if your schema has a property called `temperature`, use `{!$attrs.temperature}`, not `{!$attrs.value}` unless `value` is an actual property.
+   - **Property-level override pattern** (for individual fields):
+     - `editor.componentOverrides["<propertyName>"] = { "definition": "es_property_editors/<...>" }`
+     - **Valid editor components** (examples): `es_property_editors/inputText`, `es_property_editors/inputNumber`, `es_property_editors/inputRichText`, `es_property_editors/inputImage`, `es_property_editors/inputTextarea`. **Do not use** `es_property_editors/inputList`.
+   - **Collection editor** (for root-level `lightning__listType` properties): Use a collection-level override so the list is edited by a custom component: `collection.editor.componentOverrides["$"] = { "definition": "c/<yourCollectionEditorComponent>" }`. Alternatively, use `editor.layout` with `lightning/propertyLayout` and `attributes.property = "<listPropertyName>"` for default list editing.
+   - **Layout pattern**:
+     - `editor.layout.definition = "lightning/verticalLayout"`
+     - `editor.layout.children[*].definition = "lightning/propertyLayout"` with `attributes.property = "<propertyName>"`
+     - **CRITICAL**: `lightning/propertyLayout` only accepts the `property` attribute. Do NOT add `label`, `title`, or any other attributes — these will fail validation with `additionalProperties: false` errors.
+   - **Avoid known-invalid patterns**:
+     - Do not use `es_property_editors/inputList`.
+     - Do not use `itemSchema` attributes.
+4. **(Optional) Draft `renderer.json`** (only if custom UI or mosaic rendition is required)
+   - **Supported shape:** Top-level `renderer` object with `renderer.componentOverrides` and `renderer.layout`.
+     - Top-level `renderer` object.
+     - Use `renderer.componentOverrides` for component overrides.
+     - Use `renderer.layout` for layout.
+     - **DEPRECATED**: Do NOT use `propertyRenderers` or `view` — these are legacy keys. Always use `componentOverrides` and `layout` instead.
+   - **Root override pattern** (most common for fully custom rendering UI):
+     - `renderer.componentOverrides["$"] = { "definition": "c/<yourRendererComponent>", "attributes": { ... } }`
+     - Use `{!$attrs.<name>}` in attribute mappings when binding schema data to custom renderer component attributes.
+     - **CRITICAL**: Attribute mappings like `{!$attrs.propertyName}` must reference properties that **actually exist** in your type schema. Referencing non-existent properties will fail validation.
+     - **Type matching**: Attribute values must match the expected type for the component. For example, if a component expects a string attribute, passing an integer will fail validation.
+   - **Widget renderer pattern** (for widget rendition):
+       - **When to use:** Use this when users request "mosaic", "widget", "fragment", or "cross-platform rendering" for their CLT.
+       - **Structure:** `renderer.componentOverrides["$"] = { "type": "mosaic", "definition": "tile/mosaic", "children": [ /* UEM tree of blocks and regions */ ] }`
+       - **REQUIRED workflow:**
+           - **STOP**: Do NOT attempt to create the widget renderer yourself.
+           - **MANDATORY FIRST STEP**: You MUST fetch the reference file `references/widget-rendition.md` located in this skill's directory before proceeding.
+           - Follow the complete workflow documented in `widget-rendition.md` using the generated CLT schema as the grounding schema.
+           - The `widget-rendition.md` reference contains the full widget generation workflow: discovering UEM blocks via discoverUiComponents, calling getUiComponentSchemas, building the UEM tree, and writing renderer.json.
+           - **Do not** attempt to generate widget rendition without first fetching the `widget-rendition.md` reference file.
+   - **Property-level override pattern**:
+     - `renderer.componentOverrides["<propertyName>"] = { "definition": "es_property_editors/outputText" | "es_property_editors/outputNumber" | "es_property_editors/outputImage" | ... }`. **Valid renderer components** (examples): `es_property_editors/outputText`, `es_property_editors/outputNumber`, `es_property_editors/outputImage`. Avoid input-style components in the renderer.
+   - **Layout pattern for renderer**:
+     - `renderer.layout.definition = "lightning/verticalLayout"`
+     - `renderer.layout.children[*].definition = "lightning/propertyLayout"` with `attributes.property = "<propertyName>"`
+     - **CRITICAL**: Same as editor layouts, `lightning/propertyLayout` only accepts the `property` attribute. Do NOT add `label`, `title`, or any other attributes.
+   - **Collection renderer** (for root-level `lightning__listType` properties): Use `collection.renderer.componentOverrides["$"] = { "definition": "c/<yourListRendererComponent>" }` or `es_property_editors/genericListTypeRenderer` to render the list.
+5. **Place files in the correct bundle structure**
+   - `lightningTypes/<TypeName>/schema.json`
+   - (Optional) `lightningTypes/<TypeName>/lightningDesktopGenAi/editor.json`
+   - (Optional) `lightningTypes/<TypeName>/lightningDesktopGenAi/renderer.json`
+   - For Gen AI / Copilot the standard path is `lightningDesktopGenAi/`. Other targets (e.g. Experience Builder, Mobile Copilot, Enhanced Web Chat) use different subfolders when supported: `experienceBuilder/`, `lightningMobileGenAi/`, `enhancedWebChat/`.
+6. **Configure custom LWC components (if using custom components)**
+   - **CRITICAL**: Custom LWC components referenced in editor/renderer configs MUST have the correct target configuration in their `-meta.xml` files:
+     - **For editor components** (`c/<componentName>` used in `editor.json`): The LWC's `-meta.xml` file must include `<target>lightning__AgentforceInput</target>`
+     - **For renderer components** (`c/<componentName>` used in `renderer.json`): The LWC's `-meta.xml` file must include `<target>lightning__AgentforceOutput</target>`
+   - Without the correct target, deployment will fail with: `Invalid target configuration. To use 'c/componentName' as a renderer/editor, your js-meta.xml file must include valid target 'lightning__AgentforceOutput/Input'.`
+   - Example `-meta.xml` for a renderer component:
+     ```xml
+     <?xml version="1.0" encoding="UTF-8"?>
+     <LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
+         <apiVersion>60.0</apiVersion>
+         <isExposed>true</isExposed>
+         <targets>
+             <target>lightning__AgentforceOutput</target>
+         </targets>
+     </LightningComponentBundle>
+     ```
+## Common Deployment Errors
+| Error / Symptom | Likely Cause | Fix |
+|---|---|---|
+| Schema validation fails due to unknown keyword | `unevaluatedProperties: false` + disallowed keyword (commonly `examples`, `items`) | Remove the offending keyword; keep schema minimal |
+| Nested object validation failure | Org/channel validation rejects nested object typing in `LightningTypeBundle` | Use CLT reference (`c__<CLTName>`) or Apex class types |
+| Invalid CLT reference | Referenced CLT doesn't exist in org or incorrect syntax | Deploy the referenced CLT first; `c__<CLTName>` must match the referenced type’s **`lightning:type` value / FQN / registered identifier**, not `title` |
+| Invalid or misspelled `lightning:type` (for example, `lightning__richtextType` instead of `lightning__richTextType`) | Incorrect generated type name | Cross-check all `lightning:type` values against supported type names and correct them before deployment |
+| Array property rejected | Use of `items` (or `lightning:type` in nested arrays) rejected by validator | For nested arrays: keep only `type: "array"`. For root arrays: use minimal structure; remove `items` if rejected |
+| Apex-based CLT rejected | Extra fields added (e.g., `type`, `properties`) | Use only `title`, optional `description`, and `lightning:type` |
+| Editor config rejected | Use of invalid patterns (`es_property_editors/inputList`, `itemSchema`) or unrecognized top-level keys | Use `editor.componentOverrides` and `editor.layout`; keep config minimal |
+| `additionalProperties` error on layout attributes | Adding `label` or other attributes to `lightning/propertyLayout` | Only use `property` attribute in `lightning/propertyLayout`. Remove `label`, `title`, or any other attributes |
+| Invalid target configuration for custom LWC | Custom LWC component's `-meta.xml` missing required target (`lightning__AgentforceInput` or `lightning__AgentforceOutput`) | Add correct target to LWC's `-meta.xml`: use `lightning__AgentforceInput` for editors, `lightning__AgentforceOutput` for renderers |
+| Attribute mapping doesn't exist in type schema | Using `{!$attrs.propertyName}` where `propertyName` is not defined in schema | Ensure all attribute mappings reference actual properties in your type schema's `properties` section |
+| `additionalProperties` error with deprecated keys | Using `propertyRenderers` or `view` in editor/renderer config | Replace deprecated `propertyRenderers` with `componentOverrides` and `view` with `layout` |
+| Type mismatch in component attributes | Passing wrong type for component attribute (e.g., integer instead of string) | Ensure attribute values match the expected type defined by the component |
+
+## Verification Checklist
+- [ ] Root schema has `type: "object"`, `title`, `lightning:type: "lightning__objectType"`, and `unevaluatedProperties: false`
+- [ ] Root schema does not include `examples` when strict validation is enabled
+- [ ] No nested object includes `lightning:type: "lightning__objectType"`
+- [ ] Arrays are defined minimally (especially nested arrays)
+- [ ] Only supported primitive `lightning:type` identifiers are used for leaf properties
+- [ ] Apex class CLTs contain only `title`/`description` and `lightning:type: "@apexClassType/..."`
+- [ ] Bundle structure and filenames match Lightning Types requirements
+- [ ] Editor config uses only allowed patterns (no `es_property_editors/inputList`, no `itemSchema`); use valid components (e.g. `es_property_editors/inputText`, `es_property_editors/inputNumber`) or custom `c/` components
+- [ ] Renderer config uses output-style components (e.g. `es_property_editors/outputText`, `es_property_editors/outputNumber`) where applicable, not input editors
+- [ ] Layout configurations use `lightning/propertyLayout` with ONLY the `property` attribute (no `label`, `title`, or other attributes)
+- [ ] All attribute mappings (`{!$attrs.propertyName}`) reference properties that exist in the type schema
+- [ ] Custom LWC components have correct targets in `-meta.xml`: `lightning__AgentforceInput` for editors, `lightning__AgentforceOutput` for renderers
+- [ ] Root schema does NOT include `"$schema"` field

package/skills/platform-custom-object-generate/SKILL.md

@@ -0,0 +1,240 @@
+---
+name: platform-custom-object-generate
+description: "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 custom object\", \"generate object metadata\", \"set up an object for...\", or when they're troubleshooting object deployment errors especially around sharing models and Master-Detail relationships. Always use this skill for any custom object metadata work."
+metadata:
+  version: "1.0"
+---
+
+## 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
+
+## 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`
+
+---
+
+## 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`
+```xml
+<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
+  <label>Order Line Item</label>
+  <pluralLabel>Order Line Items</pluralLabel>
+  <sharingModel>ReadWrite</sharingModel>  <!-- WRONG: Object has a M-D field -->
+  <deploymentStatus>Deployed</deploymentStatus>
+</CustomObject>
+```
+
+**✅ CORRECT:**
+```xml
+<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
+  <label>Order Line Item</label>
+  <pluralLabel>Order Line Items</pluralLabel>
+  <sharingModel>ControlledByParent</sharingModel>  <!-- CORRECT -->
+  <deploymentStatus>Deployed</deploymentStatus>
+</CustomObject>
+```
+
+---
+
+## 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:**
+```xml
+<nameField>
+  <label>Project Name</label>
+  <type>Text</type>
+</nameField>
+```
+
+**AutoNumber Name Field Example:**
+```xml
+<nameField>
+  <label>Invoice Number</label>
+  <type>AutoNumber</type>
+  <displayFormat>INV-{0000}</displayFormat>
+  <startingNumber>1</startingNumber>
+</nameField>
+```
+
+### B. Object Description
+
+**`<description>`**: Mandatory. Every object must contain a professional summary.
+
+If the intent is vague, generate a summary:
+> "Object used to track and manage [Intent] within the organization."
+### 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:**
+```xml
+<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
+  <fullName>Vehicle__c</fullName>  <!-- WRONG: Remove this -->
+  <label>Vehicle</label>
+</CustomObject>
+```
+
+**✅ CORRECT:**
+```xml
+<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
+  <label>Vehicle</label>
+  <!-- fullName comes from filename: Vehicle__c.object-meta.xml -->
+</CustomObject>
+```
+
+### 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:**
+```xml
+<validationRules>
+  <fullName>Require_Start_Date__c</fullName>  <!-- WRONG: Has __c suffix -->
+  <active>true</active>
+  <errorMessage>Start Date is required.</errorMessage>
+  <formula>ISBLANK(Start_Date__c)</formula>
+</validationRules>
+```
+**Error:** `The validation name can only contain alphanumeric characters, must begin with a letter, cannot end with an underscore...`
+
+**✅ CORRECT:**
+```xml
+<validationRules>
+  <fullName>Require_Start_Date</fullName>  <!-- CORRECT: No __c suffix -->
+  <active>true</active>
+  <errorMessage>Start Date is required.</errorMessage>
+  <formula>ISBLANK(Start_Date__c)</formula>
+</validationRules>
+```
+
+**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?
+
+### Architectural Checks
+- [ ] Is `<description>` present with a meaningful summary?
+- [ ] Are `<enableSearch>` and `<enableReports>` set to `true` if user-facing?
+- [ ] Does the filename match the intended API name?

package/skills/platform-custom-tab-generate/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: platform-custom-tab-generate
+description: "Use this skill when users need to create or configure Salesforce Custom Tabs. Trigger when users mention tabs, navigation tabs, object tabs, web tabs, Visualforce tabs, Lightning component tabs, app page tabs, or tab configuration. Also use when users want to add navigation to custom objects, create tabs for external content, or set up Lightning page tabs. Always use this skill for any custom tab work."
+metadata:
+  version: "1.0"
+---
+
+## When to Use This Skill
+
+Use this skill when you need to:
+- Create tabs for objects, web pages, or Visualforce pages
+- Add navigation tabs to applications
+- Configure tab visibility and access
+- Troubleshoot deployment errors related to custom tabs
+
+## Specification
+
+# CustomTab Metadata Specification
+
+## 📋 Overview
+Custom tabs for navigating to objects, web content, or Visualforce pages within Salesforce applications.
+
+## 🎯 Purpose
+- Provide navigation to custom objects
+- Link to external web content
+- Access Visualforce pages
+- Organize application navigation
+
+## ⚙️ Required Properties
+
+### Core Tab Properties
+- **customObject**: `true` for custom object tabs, `false` for all others.
+- **motif**: Tab icon style — choose a motif that semantically matches the object's purpose. Do NOT reuse the same motif for every tab.
+- **label**: Display name (required for non-object tabs ONLY; object tabs inherit label from the object)
+- **url**: Web URL (for web tabs)
+- **page**: Visualforce page name (for Visualforce tabs)
+
+
+### 🚨 STRICT ELEMENT ALLOWLIST — READ THIS FIRST
+
+**The root element MUST always be `<CustomTab>` (NOT `<Tab>`).** The XML namespace must be `xmlns="http://soap.sforce.com/2006/04/metadata"`.
+
+Only the elements listed below are valid. **Any element not on this list WILL cause a deployment error.**
+
+| Tab Type | ONLY these elements are allowed (nothing else) |
+|---|---|
+| **Object tabs** | `<customObject>` (required, set to `true`), `<motif>` (required), `<description>` (optional) |
+| **Web tabs** | `<customObject>` (required, set to `false`), `<label>` (required), `<motif>` (required), `<url>` (required), `<urlEncodingKey>` (required, set to `UTF-8`), `<description>` (optional), `<frameHeight>` (optional) |
+| **Visualforce tabs** | `<customObject>` (required, set to `false`), `<label>` (required), `<motif>` (required), `<page>` (required), `<description>` (optional) |
+
+### ⚠️ FORBIDDEN ELEMENTS (every one of these causes a deployment error)
+`<sobjectName>`, `<name>`, `<fullName>`, `<apiVersion>`, `<isHidden>`, `<tabVisibility>`, `<type>`, `<mobileReady>`, `<urlFrameHeight>`, `<urlType>`, `<urlRedirect>`, `<encodingKey>`, `<height>`, `<auraComponent>`
+
+Also forbidden:
+- `<label>` on object tabs (object tabs inherit their label from the custom object)
+- `<page>` on web tabs (only for Visualforce tabs)
+- Empty elements like `<page></page>` or `<description></description>`
+- Any element not in the allowlist table above
+
+## 🔧 Tab Types
+
+### Object Tabs
+- **Purpose**: Navigate to custom or standard objects
+- **File name** determines the object: `{ObjectApiName}.tab-meta.xml` (e.g., `Space_Station__c.tab-meta.xml`)
+- **Required elements**: `<customObject>true</customObject>` and `<motif>`
+- **Correct example** (for a Space_Station__c.tab-meta.xml):
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<CustomTab xmlns="http://soap.sforce.com/2006/04/metadata">
+    <customObject>true</customObject>
+    <motif>Custom39: Telescope</motif>
+</CustomTab>
+```
+- **Correct example** (for a Supply__c.tab-meta.xml — note different motif):
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<CustomTab xmlns="http://soap.sforce.com/2006/04/metadata">
+    <customObject>true</customObject>
+    <motif>Custom98: Truck</motif>
+</CustomTab>
+```
+- **❌ WRONG** — do NOT add `<sobjectName>`, `<name>`, `<fullName>`, or `<label>`:
+```xml
+<CustomTab xmlns="http://soap.sforce.com/2006/04/metadata">
+    <sobjectName>Space_Station__c</sobjectName>  <!-- DEPLOYMENT ERROR -->
+    <label>Space Station</label>                  <!-- DEPLOYMENT ERROR on object tabs -->
+    <customObject>true</customObject>
+    <motif>Custom57: Desert</motif>
+</CustomTab>
+```
+
+### Web Tabs
+- **Purpose**: Link to external websites or web applications
+- **File name**: Use a descriptive name: `{TabName}.tab-meta.xml` (e.g., `Knowledge_Base.tab-meta.xml`)
+- **COPY THIS EXACT TEMPLATE** — only replace the placeholder values. Do NOT add, remove, or rename any XML elements:
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<CustomTab xmlns="http://soap.sforce.com/2006/04/metadata">
+    <customObject>false</customObject>
+    <description>REPLACE_WITH_DESCRIPTION</description>
+    <frameHeight>600</frameHeight>
+    <label>REPLACE_WITH_LABEL</label>
+    <motif>REPLACE_WITH_MOTIF</motif>
+    <url>REPLACE_WITH_URL</url>
+    <urlEncodingKey>UTF-8</urlEncodingKey>
+</CustomTab>
+```
+- **These 7 elements above are the ONLY elements allowed in a web tab file.** Do not add ANY other elements.
+- The `<description>` element is optional — you may remove it if not needed, but do not add anything else.
+
+### Visualforce Tabs
+- **Purpose**: Access custom Visualforce pages
+- **File name**: `{TabName}.tab-meta.xml` (e.g., `Custom_Page_Tab.tab-meta.xml`)
+- **Required elements**: `<customObject>false</customObject>`, `<label>`, `<motif>`, `<page>`
+- **Correct example**:
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<CustomTab xmlns="http://soap.sforce.com/2006/04/metadata">
+    <customObject>false</customObject>
+    <label>Custom Page</label>
+    <motif>Custom46: Computer</motif>
+    <page>CustomPage</page>
+</CustomTab>
+```
+
+## 🎨 Tab Configuration
+
+### Tab Style
+- **Default**: Use standard tab styling
+- **Custom**: Can specify custom tab styles if needed
+
+### Tab Visibility
+- **Default**: Visible to all users with access
+- **Custom**: Can be configured for specific user profiles
+
+## 📱 Supported Applications
+- **Standard Apps**: Available in standard Salesforce applications
+- **Custom Apps**: Can be included in custom applications
+- **Community Apps**: Available in community applications
+
+## 🔗 Integration Points
+- **Object Relationships**: Links to related object records
+- **Web Content**: External website integration
+- **Visualforce Pages**: Custom page functionality
+- **Lightning Components**: Modern component integration
+## ✅ Best Practices
+- Use clear, descriptive tab labels
+- Choose appropriate tab types for functionality
+- **Select a unique, contextually relevant motif for each tab** — do not default every tab to the same icon
+- Consider user experience and navigation flow
+- Test tab functionality across different applications
+- Ensure proper permissions and visibility settings
+- Follow consistent naming conventions
+- Object tab files MUST only contain `<customObject>true</customObject>` and `<motif>` — nothing else
+- Web tab files MUST only contain: `<customObject>false</customObject>`, `<label>`, `<motif>`, `<url>`, `<urlEncodingKey>`, and optionally `<description>`, `<frameHeight>` — nothing else
+- Never include `<isHidden>`, `<tabVisibility>`, `<type>`, `<mobileReady>`, or empty elements