mirror of
https://github.com/forcedotcom/afv-library.git
synced 2026-07-30 03:09:50 +08:00
feat: add metadata type skills
This commit is contained in:
Hemant Singh Bisht
parent
65947b1550
commit
3689f14af7
76
skills/lex-app-solution/SKILL.md
Normal file
76
skills/lex-app-solution/SKILL.md
Normal file
@ -0,0 +1,76 @@
|
||||
---
|
||||
name: lex-app-solution
|
||||
description: Use this skill to build and orchestrate complete Salesforce Lightning Applications (LEX Apps), custom projects, or end-to-end business solutions from a natural language scenario. Triggers when a user requests a "custom app", a "business solution", or describes any scenario requiring multiple interconnected Salesforce components to be built together into a complete Lightning Experience (LEX) Application. Orchestrates the sequenced creation of Custom Objects, Relationships, Fields, Lightning Record Pages, Custom Tabs, Custom Applications, Permission Sets, and OPTIONALLY Flows and Validation Rules.
|
||||
---
|
||||
|
||||
# Salesforce Lightning Application (LEX App) Builder
|
||||
|
||||
## Overview
|
||||
|
||||
Build and orchestrate complete Salesforce Lightning Applications (LEX Apps) from natural language scenarios. This skill coordinates the sequenced creation of multiple interconnected Salesforce components—Custom Objects, Fields, Lightning Record Pages, Custom Tabs, Custom Applications, Permission Sets, and optionally Flows and Validation Rules—by invoking specialized metadata expert skills in the correct order.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
- Build or enhance a complete Lightning Application (LEX App) from a single user prompt.
|
||||
- Create end-to-end solutions requiring multiple metadata types working together within the Lightning Experience.
|
||||
- Ensure proper sequencing of metadata creation (Objects → Fields → Tabs → Pages → Apps → Security).
|
||||
|
||||
**Do not use this skill for:**
|
||||
- Creating individual metadata components (use specific metadata expert skills instead).
|
||||
- Troubleshooting or fixing deployment errors.
|
||||
- Building Salesforce Classic applications or off-platform integrations.
|
||||
|
||||
## Specification
|
||||
|
||||
# Salesforce Lightning Application Development Requirements
|
||||
|
||||
You are a highly experienced and certified Salesforce Architect. Your purpose is to autonomously orchestrate the generation of a complete Salesforce Lightning application based on the user's requirements.
|
||||
|
||||
## Specialized Skill Invocation Requirement
|
||||
|
||||
**CRITICAL:** You **MUST NOT** generate raw metadata or XML directly. You **MUST** invoke the specialized metadata expert skill for each component type.
|
||||
|
||||
### MANDATORY Skill Mapping (Always Evaluate & Invoke):
|
||||
- **Custom Objects** → `salesforce-custom-object`
|
||||
- **Custom Fields** → `salesforce-custom-field`
|
||||
- **Custom Tabs** → `salesforce-custom-tab`
|
||||
- **FlexiPages** → `salesforce-flexipage`
|
||||
- **Custom Applications** → `salesforce-custom-application` (Ensure this generates a LEX CustomApplication, not Classic)
|
||||
- **Permission Sets** → `salesforce-permission-set` (Create at least one baseline permission set for app access if specific personas aren't requested)
|
||||
|
||||
### OPTIONAL Skill Mapping (Strictly Conditional):
|
||||
*DO NOT invoke these unless the user's prompt explicitly asks for or clearly describes requirements for them (e.g., "enforce that...", "automate the...").*
|
||||
- **Validation Rules** → `salesforce-validation-rule`
|
||||
- **Flows** → `salesforce-flow`
|
||||
|
||||
---
|
||||
|
||||
## Autonomous Execution Sequence
|
||||
|
||||
Execute the following steps sequentially in a single response. Do not stop and ask the user for permission to proceed unless their initial prompt lacks the basic information needed to start building.
|
||||
|
||||
### STEP 1: The Pre-Flight Checklist (Planning)
|
||||
Before invoking any skills, you must analyze the user's request and output a bulleted "Build Plan".
|
||||
- Explicitly list every Custom Object, Field, Tab, FlexiPage, LEX Application, and Permission Set you are about to create.
|
||||
- **Evaluate Optional Metadata:** Actively scan the prompt for automation or validation requirements. If found, add them to the plan. If NOT found, explicitly state: *"No optional Flows or Validation Rules requested. Skipping."*
|
||||
- Explicitly state which metadata skill you will invoke for each planned item.
|
||||
|
||||
### STEP 2: The Build Sequence (Skill Invocations)
|
||||
Immediately after outputting the Pre-Flight Checklist, begin invoking the specialized skills strictly in this order:
|
||||
1. **Data Model (Mandatory):** Invoke skills for Custom Objects first, followed immediately by Custom Fields.
|
||||
2. **Business Logic (Optional):** Invoke skills for Validation Rules and Flows **ONLY IF** they were explicitly included in your Pre-Flight Checklist. Otherwise, skip this step entirely.
|
||||
3. **User Experience (Mandatory):** Invoke skills for Custom Tabs. Then, invoke skills for FlexiPages (only for objects that received tabs, ensuring you include requested components like Highlights Panels).
|
||||
4. **App Assembly (Mandatory):** Invoke the skill for the Custom Application to create the Lightning App, adding the newly created tabs.
|
||||
5. **Security (Mandatory):** Invoke the skill for Permission Sets to grant access to the newly created LEX App, Objects, and Fields.
|
||||
|
||||
### STEP 3: Skill Invocation Summary
|
||||
Once all invocations are complete, output a final summary confirming:
|
||||
- The complete Lightning application has been orchestrated.
|
||||
- A list of any errors, warnings, or constraints encountered during the skill invocations.
|
||||
|
||||
---
|
||||
|
||||
### Error Handling & Constraints
|
||||
- If a specialized skill invocation fails, note it in your internal sequence, skip that specific component, and attempt to continue building the rest of the application.
|
||||
- Only pause and ask the user for intervention if a critical failure occurs (e.g., a primary Custom Object fails to generate).
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
name: salesforce-custom-application
|
||||
description: Generate CustomApplication (Lightning App) metadata with proper navigation types, branding, and action overrides. Use when creating Lightning applications for specific user workflows.
|
||||
description: Use this skill when users need to create or configure Salesforce Custom Applications. Trigger when users mention custom apps, application metadata, app navigation, or organizing tabs into applications. Use when users want to create app containers for tabs and pages. Always use this skill for custom application work.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
@ -12,11 +12,10 @@ Use this skill when you need to:
|
||||
- Set up custom page layouts for objects
|
||||
- Troubleshoot deployment errors related to custom applications
|
||||
|
||||
## Specification
|
||||
|
||||
# CustomApplication (Lightning App) Metadata Specification
|
||||
|
||||
## 📋 Overview
|
||||
## Overview
|
||||
|
||||
Custom applications (Lightning Apps) that group tabs and functionality to provide a focused user experience for specific business processes. Always configured for Lightning Experience.
|
||||
|
||||
## 🎯 Purpose
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
name: salesforce-custom-field
|
||||
description: Generate CustomField metadata XML with proper type handling, relationship rules, and formula syntax. Handles Master-Detail, Lookup, Roll-Up Summary, and Formula fields correctly. Use when creating or modifying custom fields.
|
||||
description: Use this skill when users need to create, generate, or validate Salesforce Custom Field metadata. Trigger when users mention custom fields, field types, Roll-up Summary fields, Master-Detail relationships, Lookup relationships, formula fields, picklists, or field metadata. Also use when users encounter field deployment errors, especially around Roll-up Summary format, Master-Detail constraints, or formula issues. Always use this skill for any custom field metadata work, field generation, or field troubleshooting.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
@ -12,6 +12,12 @@ Use this skill when you need to:
|
||||
- Create formula or roll-up summary fields
|
||||
- Troubleshoot deployment errors related to custom fields
|
||||
|
||||
# Salesforce Custom Field Generator and Validator
|
||||
|
||||
## Overview
|
||||
|
||||
Generate and validate Salesforce Custom Field metadata with mandatory constraints to prevent deployment errors. This skill has special focus on the **highest-failure-rate field types**: Roll-up Summary and Master-Detail relationships.
|
||||
|
||||
## Specification
|
||||
|
||||
## 1. Purpose
|
||||
157
skills/salesforce-custom-lightning-type/SKILL.md
Normal file
157
skills/salesforce-custom-lightning-type/SKILL.md
Normal file
@ -0,0 +1,157 @@
|
||||
---
|
||||
name: salesforce-custom-lightning-type
|
||||
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, JSON schemas for agents, type definitions, lightning__objectType, or editor/renderer configurations. This is complex - always use this skill for CLT work.
|
||||
---
|
||||
|
||||
## 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
|
||||
- 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 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)
|
||||
- **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 should be plain JSON Schema objects (`type`, `properties`, optional `required`, optional `unevaluatedProperties`).
|
||||
- **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
|
||||
- `lightning__textType`
|
||||
- Max length 255
|
||||
- `lightning__multilineTextType`
|
||||
- Max length 2000
|
||||
- `lightning__richTextType`
|
||||
- Max length 100000
|
||||
- `lightning__urlType`
|
||||
- Max length 2000
|
||||
- Optional `lightning:allowedUrlSchemes` enum values: `https`, `http`, `relative`, `mailto`, `tel`
|
||||
- `lightning__dateType`
|
||||
- Data pattern: YYYY-MM-DD
|
||||
- `lightning__timeType`
|
||||
- Data pattern: HH:MM:SS.sssZ
|
||||
- `lightning__dateTimeType`
|
||||
- Data shape is an object with required `dateTime` and optional `timeZone`
|
||||
- `lightning__numberType`
|
||||
- Decimal numbers; optional `maximum`, `minimum`, `multipleOf`
|
||||
- `lightning__integerType`
|
||||
- Whole numbers only; optional `maximum`, `minimum`
|
||||
- `lightning__booleanType`
|
||||
- true/false
|
||||
|
||||
## Allowed Property-Level Keywords
|
||||
When strict validation is enabled (`unevaluatedProperties: false`), keep each property minimal and prefer only keywords known to be allowed:
|
||||
- `title`, `description`, `einstein:description`
|
||||
- `type` (when used, ensure it matches the chosen `lightning:type`)
|
||||
- `lightning:type`
|
||||
- `maximum`, `minimum`, `multipleOf` (numeric)
|
||||
- `maxLength`, `minLength` (string)
|
||||
- `const`, `enum`
|
||||
- `lightning:textIndexed`, `lightning:supportsPersonalization`, `lightning:localizable`
|
||||
- `lightning:uiOptions`, `lightning:allowedUrlSchemes`
|
||||
- `lightning:tags` (metaschema restricts values; currently `flow` is the only known allowed tag)
|
||||
|
||||
## 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`**
|
||||
- Start with the root object structure (required root fields).
|
||||
- Add `properties` using valid primitive `lightning:type` identifiers.
|
||||
- For nested objects: omit `lightning:type` and keep keywords minimal.
|
||||
- For arrays: follow the strict list rules (avoid `items`; avoid `lightning:type` on nested arrays).
|
||||
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.
|
||||
- **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.
|
||||
- **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>"`
|
||||
- **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 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.
|
||||
- **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.
|
||||
- **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.
|
||||
- **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. **Deploy and validate**
|
||||
- Deploy the bundle using your org's standard metadata deployment flow (e.g. Salesforce CLI or IDE). The MCP client or tooling in use should provide or integrate with the appropriate deploy/retrieve commands for Lightning Type bundles.
|
||||
- Validate incrementally: if deployment fails, remove disallowed keywords first (especially `examples`, `items`, nested `lightning:type`).
|
||||
|
||||
## 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 | Nested object includes `lightning:type: lightning__objectType` | Remove `lightning:type` from nested objects |
|
||||
| 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 |
|
||||
|
||||
## 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
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
name: salesforce-custom-object
|
||||
description: Generate CustomObject metadata XML following Salesforce best practices. Ensures correct sharing models, name fields, and required elements. Use when creating new custom objects or modifying existing object metadata.
|
||||
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.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
@ -14,7 +14,7 @@ Use this skill when you need to:
|
||||
|
||||
## Specification
|
||||
|
||||
## 1. Purpose
|
||||
## 1. Overview and Purpose
|
||||
|
||||
This document defines the mandatory constraints for generating CustomObject metadata XML (`.object` file). The agent must verify these constraints before outputting XML to prevent Metadata API deployment errors.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
name: salesforce-custom-tab
|
||||
description: Generate CustomTab metadata XML for object tabs, web tabs, or Visualforce tabs. Use when adding navigation tabs to Salesforce applications.
|
||||
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.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
178
skills/salesforce-experience-site/SKILL.md
Normal file
178
skills/salesforce-experience-site/SKILL.md
Normal file
@ -0,0 +1,178 @@
|
||||
---
|
||||
name: salesforce-experience-site
|
||||
description: Use this skill when users need to create, modify, or manage Salesforce Experience Cloud sites (LWR sites). Trigger when users mention Experience sites, LWR sites, DigitalExperience, Experience Cloud, community sites, portals, creating pages, adding routes, views, theme layouts, branding sets, or any DigitalExperience bundle work. Also use when users mention specific content types like sfdc_cms__route, sfdc_cms__view, sfdc_cms__themeLayout, or when troubleshooting site deployment. Always use this skill for any Experience Cloud or LWR site work.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
- Create Experience Cloud sites or communities
|
||||
- Build LWR (Lightning Web Runtime) sites
|
||||
- Set up site configuration and settings
|
||||
- Generate Experience Site metadata
|
||||
- Troubleshoot deployment errors related to Experience Sites
|
||||
|
||||
## Specification
|
||||
|
||||
# Experience LWR Site Metadata Specification
|
||||
An LWR site can be represented by metadata DigitalExperienceConfig, DigitalExperienceBundle, Network, CustomSite, and CMS contents. Your purpose is to assist developers in creating and editing these metadata.
|
||||
|
||||
## Supported Template Types
|
||||
|
||||
Template name - Template DevName
|
||||
- Build Your Own (LWR) - talon-template-byo
|
||||
|
||||
## Core Properties
|
||||
|
||||
Before doing anything else, identify the following properties from the local project if available. Check with the user if any of the following is missing:
|
||||
- Site name: Required. (e.g., `'My Community'`).
|
||||
- URL path prefix: Optional. Alphanumeric characters only. Convert from site name if not provided (e.g., `'mycommunity'`) and verify with the user for the converted value.
|
||||
- Template type devName: Optional. Defaults to `talon-template-byo`.
|
||||
|
||||
## General Tips
|
||||
|
||||
TIP 1. When available, the site developer name can be found in the CustomSite filename (e.g., `sites/MySite.site-meta.xml` → developer name is `MySite`).
|
||||
|
||||
## Project Structure in DigitalExperienceBundle Format
|
||||
|
||||
### Site Metadata
|
||||
- DigitalExperienceConfig
|
||||
- Path: `digitalExperienceConfigs/{siteName}1.digitalExperienceConfig-meta.xml`
|
||||
- DigitalExperienceBundle
|
||||
- Path: `digitalExperiences/site/{siteName}1/{siteName}1.digitalExperience-meta.xml`
|
||||
- Network
|
||||
- Path: `networks/{siteName}.network-meta.xml`
|
||||
- CustomSite
|
||||
- Path: `sites/{siteName}.site-meta.xml`
|
||||
|
||||
### DigitalExperience Contents
|
||||
- Path: `digitalExperiences/site/{siteName}1/sfdc_cms__*/{contentApiName}/*`
|
||||
- Description: These are the content components defining routes, views, theme layouts, etc. Each component must have a `_meta.json` and `content.json` file.
|
||||
|
||||
#### Content Type Descriptions
|
||||
| Content Type | Description | When to Use |
|
||||
|-|-|-|
|
||||
| `sfdc_cms__site` | Root site configuration containing site-wide settings | Required for every site; one per site |
|
||||
| `sfdc_cms__appPage` | Application page container that groups routes and views | Required; defines the app shell |
|
||||
| `sfdc_cms__route` | URL routing definition mapping paths to views | Create one for each page/URL path |
|
||||
| `sfdc_cms__view` | Page layout and component structure | Create one for each route; defines page content. Also use to edit existing views (e.g., adding/removing components, updating theme layout) |
|
||||
| `sfdc_cms__brandingSet` | Brand colors, fonts, and styling tokens | Required; defines site-wide styling |
|
||||
| `sfdc_cms__languageSettings` | Language and localization configuration | Required; defines supported languages |
|
||||
| `sfdc_cms__mobilePublisherConfig` | Mobile app publishing settings | Required for mobile app deployment |
|
||||
| `sfdc_cms__theme` | Theme definition referencing layouts and branding | Required; one per site |
|
||||
| `sfdc_cms__themeLayout` | Page layout templates used by views | Create layouts for different page structures |
|
||||
|
||||
**Important:** Creating any new pages require BOTH `sfdc_cms__route` AND `sfdc_cms__view`.
|
||||
|
||||
## CUD Operations on DigitalExperience Contents
|
||||
- Users can perform create, update, delete operations on DigitalExperience Contents.
|
||||
- **IMPORTANT:** Before ANY modification (create, update, or delete) to content, ALWAYS call `execute_metadata_action` first to get the schema, examples, and instructions for that content type.
|
||||
- **Call once per content type per user request**: If you're creating/modifying multiple items of the same content type (e.g., creating 3 routes), you only need to call `execute_metadata_action` ONCE for that content type. Reuse the schema and examples for all items of that type within the same user request.
|
||||
- For each unique content type you need to work with, call `execute_metadata_action` using the following:
|
||||
```json
|
||||
{
|
||||
"metadataType": "ExperienceSite",
|
||||
"actionName": "getSiteContentMetadata",
|
||||
"parameters": {
|
||||
"contentType": "<content type from table above>",
|
||||
"shouldIncludeExamples": true
|
||||
}
|
||||
}
|
||||
```
|
||||
- Do not call the `execute_metadata_action` MCP tool with any other site actionName unless specified in this knowledge doc/instructions.
|
||||
|
||||
## Retrieving Site URLs After Deployment
|
||||
|
||||
After successfully deploying the site using `sf project deploy`, use the `execute_metadata_action` MCP tool to get the preview and builder URLs:
|
||||
```json
|
||||
{
|
||||
"metadataType": "ExperienceSite",
|
||||
"actionName": "getSiteUrls",
|
||||
"parameters": {
|
||||
"siteDevName": "<site developer name>"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Refer to TIP 1 to get the site developer name.
|
||||
|
||||
If the site is not found, an error message will be returned indicating that the site may not be deployed. Ensure the site has been successfully deployed before calling this action.
|
||||
|
||||
## Enhancement Rules
|
||||
|
||||
- If need to understand how site metadata should be configured, use the `get_metadata_api_context` MCP tool to get the schemas.
|
||||
|
||||
- Use MCP tool `execute_metadata_action` with `getSiteTemplateMetadata` to get the knowledge document about the template and its default configurations if needed. **IMPORTANT:** This MUST be used for new site:
|
||||
```json
|
||||
{
|
||||
"metadataType": "ExperienceSite",
|
||||
"actionName": "getSiteTemplateMetadata",
|
||||
"parameters": {
|
||||
"templateDevName": "<template DevName, e.g. talon-template-byo>"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- To validate Experience Site metadata, run CLI command `sf project deploy validate --metadata DigitalExperienceBundle DigitalExperience DigitalExperienceConfig Network CustomSite --target-org ${usernameOrAlias}`
|
||||
|
||||
## Guest User Sharing Rules (Public Sites Only)
|
||||
|
||||
**When to use**: Only create guest sharing rules when the user explicitly wants to make the site **public** (accessible to unauthenticated visitors). If the site is private/login-required, guest sharing rules are not needed.
|
||||
If sharingRules metadata is not available locally in force-app/main/default/sharingRules, retrieve it from the org before creating new rules.
|
||||
|
||||
To get the full SharingRules schema, use the `get_metadata_api_context` MCP tool:
|
||||
```json
|
||||
{
|
||||
"metadataType": "SharingRules"
|
||||
}
|
||||
```
|
||||
|
||||
### XML Example
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<SharingRules xmlns="http://soap.sforce.com/2006/04/metadata">
|
||||
<sharingGuestRules>
|
||||
<fullName>ShareAccountsWithSiteGuest</fullName>
|
||||
<accessLevel>Read</accessLevel>
|
||||
<includeHVUOwnedRecords>false</includeHVUOwnedRecords>
|
||||
<label>Share Accounts With Site Guest</label>
|
||||
<sharedTo>
|
||||
<guestUser>[site developer name]</guestUser>
|
||||
</sharedTo>
|
||||
<criteriaItems>
|
||||
<field>Name</field>
|
||||
<operation>notEqual</operation>
|
||||
<value>null</value>
|
||||
</criteriaItems>
|
||||
</sharingGuestRules>
|
||||
</SharingRules>
|
||||
```
|
||||
Refer to TIP 1 to get the site developer name.
|
||||
|
||||
### Critical Requirements
|
||||
|
||||
1. **SharedTo Element**: Must use `<guestUser>{siteName}</guestUser>` where `{siteName}` is the Network name (not URL path prefix).
|
||||
2. **includeHVUOwnedRecords**: Required field. Set to `false` unless records owned by high-volume site users should be included.
|
||||
3. **One XML file per object**: Put all rules for a given object in one file. Do not create additional.
|
||||
|
||||
### Common Mistakes
|
||||
|
||||
- Using `<role>` or `<group>` instead of `<guestUser>` in sharedTo
|
||||
- Omitting the required `includeHVUOwnedRecords` field
|
||||
- Using `includeRecordsOwnedByAll` (that's for `sharingCriteriaRules`, not guest rules)
|
||||
|
||||
## Workflows
|
||||
|
||||
### Creating a new site
|
||||
|
||||
- Verify with user on the value of site name, url path prefix, and site template type.
|
||||
- Retrieve template information from `getSiteTemplateMetadata` and strictly follow the rules of its knowledge document.
|
||||
- Proceed to the workflow of editing an existing site.
|
||||
|
||||
### Editing an existing site
|
||||
|
||||
- Identify the intent of the user and break it down into steps.
|
||||
- Make use of `get_metadata_api_context` if user wants to edit site metadata.
|
||||
- Use `getSiteContentMetadata` to understand how to edit site contents.
|
||||
- Once the tasks are done, perform site metadata validation.
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
name: salesforce-flexipage
|
||||
description: Generate FlexiPage metadata using CLI bootstrapping and MCP actions for component discovery. Use when creating Record Pages, App Pages, or Home Pages in Lightning Experience.
|
||||
description: Use this skill when users need to create, generate, modify, or validate Salesforce Lightning pages (FlexiPages). Trigger when users mention RecordPage, AppPage, HomePage, Lightning pages, page layouts, adding components to pages, or page customization. Also use when users say things like "create a Lightning page", "add a component to a page", "customize the record page", "generate a FlexiPage", or when they're working with FlexiPage XML files and need help with components, regions, or deployment errors. Always use this skill for any FlexiPage-related work, even if they just mention "page" in the context of Salesforce.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
@ -12,7 +12,6 @@ Use this skill when you need to:
|
||||
- Configure page structure and components
|
||||
- Troubleshoot deployment errors related to FlexiPages
|
||||
|
||||
## Specification
|
||||
|
||||
# FlexiPage Generation Guide
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
name: salesforce-flow
|
||||
description: Generate Flow metadata using the mandatory 3-step pipeline (fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration). Use when creating Screen Flows, Autolaunched Flows, Record-Triggered Flows, or Scheduled Flows.
|
||||
description: Use this skill when users need to generate Salesforce Flows using the 3-step pipeline (fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration). Trigger when users mention creating flows, Screen Flows, Autolaunched Flows, Record-Triggered Flows, Scheduled Flows, Platform Event-Triggered Flows, flow metadata, flow automation, process automation, workflow automation, or generating flow XML. This skill guides through the mandatory 3-step MCP pipeline and ensures proper inflightMetadata formatting. Always use this skill for any flow generation or automation requests.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
42
skills/salesforce-fragment/SKILL.md
Normal file
42
skills/salesforce-fragment/SKILL.md
Normal file
@ -0,0 +1,42 @@
|
||||
---
|
||||
name: salesforce-fragment
|
||||
description: Use this skill when users need to create or edit Salesforce Fragments (reusable UI pieces). Trigger when users mention fragments, UEM blocks, reusable UI templates, structured rendering across Slack/Mobile/LEX, or block-based layouts. Also use when users want to create unified experience components. Always use this skill for any fragment work.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
- Create reusable UI fragments for Salesforce experiences
|
||||
- Generate Fragment metadata following UEM structure
|
||||
- Build fragments for Slack, Mobile, LEX, and other Salesforce experiences
|
||||
- Troubleshoot deployment errors related to Fragments
|
||||
|
||||
## Specification
|
||||
|
||||
# Fragment Generation Guide
|
||||
|
||||
## 📋 Overview
|
||||
Fragments are reusable pieces of UI similar to templates, with placeholders for actual data values. The purpose of this file is to assist developers in creating and editing fragments.
|
||||
|
||||
## 🎯 Purpose
|
||||
Fragments render data in a structured and unified way across various Salesforce experiences like Slack, Mobile, LEX etc
|
||||
|
||||
## ⚙️ Composition
|
||||
A fragment is a UEM (Unified Experience Model) tree of blocks and regions. The fragment you return must follow the Typescript interfaces below:
|
||||
|
||||
- **Block definition**: Follow `{namespace}}/{{blockName}` convention and use the same value as the block's definition when it appears in a fragment.
|
||||
|
||||
```ts
|
||||
interface BlockType {
|
||||
type: 'block'
|
||||
definition: string // {namespace}/{blockName}, e.g. "bcx/heading"
|
||||
attributes?: Record<string, any>
|
||||
children?: (BlockType | RegionType)[]
|
||||
}
|
||||
|
||||
interface RegionType {
|
||||
type: 'region'
|
||||
name: string
|
||||
children: BlockType[]
|
||||
}
|
||||
```
|
||||
216
skills/salesforce-list-view/SKILL.md
Normal file
216
skills/salesforce-list-view/SKILL.md
Normal file
@ -0,0 +1,216 @@
|
||||
---
|
||||
name: salesforce-list-view
|
||||
description: Use this skill when users need to create, generate, or validate Salesforce List View metadata. Trigger when users mention list views, filtered record lists, creating views, setting up record columns, filtering records by criteria, or ask about list view visibility. Also use when users say things like "I need a view that shows...", "filter records by...", "create a list view for...", or when they're working with ListView XML files and need validation or troubleshooting.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
- Create list views for objects
|
||||
- Generate filtered, column-based record listings
|
||||
- Configure list view visibility and sharing
|
||||
- Troubleshoot deployment errors related to List Views
|
||||
|
||||
## Specification
|
||||
|
||||
# Salesforce List View Metadata Knowledge
|
||||
|
||||
## 📋 Overview
|
||||
Salesforce List Views define filtered, column-based record listings on an object's tab.
|
||||
|
||||
## 🎯 Purpose
|
||||
- Provide curated, role- or task-specific subsets of records
|
||||
- Standardize commonly used filters and visible fields across teams
|
||||
|
||||
## 🔧 Configuration
|
||||
|
||||
Unless specifically requested to be generated inline, List Views are stored at:
|
||||
- force-app/main/default/objects/<ObjectName>/listViews/<fullName>.listView-meta.xml
|
||||
Only if the user requests are they to be included in the object's metadata file:
|
||||
- fore-app/main/default/objects/<ObjectName>/<ObjectName>.object-meta.xml
|
||||
|
||||
Key elements:
|
||||
- label: Human-friendly name shown in UI (must be under 40 characters in length)
|
||||
- fullName (fullName): API identifier used in metadata and file name
|
||||
- filterScope: Everything | Mine | Queue
|
||||
- filters: field/operation/value triples
|
||||
- booleanFilterLogic: Combine multiple filters logically with AND/OR (e.g., "1 AND (2 OR 3)")
|
||||
- columns: Ordered list of field API names to display
|
||||
|
||||
References:
|
||||
- listViews appear on the entity's tab
|
||||
- listViews can be referenced by flexipages using the "filterListCard" component
|
||||
|
||||
### Critical Decision: Visibility Strategy
|
||||
Choose how broadly the view should appear in the org.
|
||||
|
||||
**Choose "Visible to all users" when:**
|
||||
- The view is useful across profiles/roles
|
||||
- It's a governed, shared artifact to be managed via source control
|
||||
- Data contained is appropriate for broad visibility
|
||||
|
||||
**Choose "Owner-only/Restricted" when:**
|
||||
- It is experimental or niche during iteration
|
||||
- It is specifically requested to be limited to Users, Groups or Roles
|
||||
- There are governance/security reviews pending
|
||||
|
||||
**When in doubt:** Default to "Visible to all users".
|
||||
|
||||
### Critical Decision: Columns Density
|
||||
**Choose minimal, high-signal columns when:**
|
||||
- Users need at-a-glance scanning
|
||||
- Mobile/responsive performance matters
|
||||
|
||||
**Choose richer column sets when:**
|
||||
- Desktop heavy workflows need more context without opening records
|
||||
- It serves as a work queue and extra fields reduce clicks
|
||||
|
||||
**When in doubt:** Start with 4–6 columns that directly support the primary task.
|
||||
|
||||
## Critical Rules (Read First)
|
||||
|
||||
### Rule 1: Custom Field API Names
|
||||
For custom fields, use exact API names (e.g., Status__c), not labels.
|
||||
|
||||
Wrong:
|
||||
- Status (label)
|
||||
|
||||
Right:
|
||||
- Status__c (API name)
|
||||
|
||||
### Rule 2: Standard Field Names
|
||||
For standard fields on Custom Objects, use already defined names:
|
||||
|
||||
Wrong:
|
||||
- Name (API Name)
|
||||
|
||||
Right:
|
||||
- NAME
|
||||
|
||||
The standard fields on Custom Objects are:
|
||||
- NAME
|
||||
- RECORDTYPE
|
||||
- OWNER.ALIAS
|
||||
- OWNER.FIRST_NAME
|
||||
- OWNER.LAST_NAME
|
||||
- CREATEDBY_USER.ALIAS
|
||||
- CREATEDBY_USER
|
||||
- CREATED_DATE
|
||||
- UPDATEDBY_USER.ALIAS
|
||||
- UPDATEDBY_USER
|
||||
- LAST_UPDATE
|
||||
- LAST_ACTIVITY
|
||||
|
||||
### Rule 3: Operations Must Match Field Types
|
||||
Picklists require equals/notEqual; date fields require date operators; boolean values are 0 and 1; do not mix text-only operators with non-text fields.
|
||||
|
||||
Wrong:
|
||||
- operation="contains" on a picklist
|
||||
- value=True on a boolean
|
||||
|
||||
Right:
|
||||
- operation="equals" with a valid picklist value
|
||||
- value=1 on a boolean
|
||||
|
||||
### Rule 4: Name and Path Alignment
|
||||
File name, fullName (also sometimes referred to as DeveloperName), and uniqueness must align.
|
||||
|
||||
Wrong:
|
||||
- File: My_List.listView-meta.xml
|
||||
- fullName: MyList
|
||||
|
||||
Right:
|
||||
- File: MyList.listView-meta.xml
|
||||
- fullName: MyList
|
||||
|
||||
### Rule 5: Folder Placement
|
||||
Place files under the object's listViews directory or deployments will fail to resolve components. Only if a user
|
||||
requests it, may the listView may be included inline in force-app/main/default/objects/<ObjectName>/<ObjectName>.object-meta.xml
|
||||
|
||||
Path:
|
||||
- force-app/main/default/objects/<ObjectName>/listViews/<fullName>.listView-meta.xml
|
||||
|
||||
## Generation Workflow
|
||||
|
||||
### Step 1: Get Metadata Information
|
||||
- Identify the target object API name (e.g., Object__c).
|
||||
- Gather business requirements: purpose, audience, fields, filters.
|
||||
- Validate values and operator compatibility with field types.
|
||||
|
||||
### Step 2: Examine Existing Examples
|
||||
- Repo: force-app/main/default/objects/<Object>/listViews/ (unless otherwise required by end user)
|
||||
- Org: retrieve existing list views for proven patterns (filters, logic, columns).
|
||||
- Note what passed review/deployment and delivered expected UX.
|
||||
|
||||
### Step 3: Create Specification
|
||||
Document before implementation:
|
||||
- Name: fullName and Label
|
||||
- Audience: Visibility scope ("all users" vs. shared)
|
||||
- Filter scope: Everything | Mine | Queue
|
||||
- Filter items: filter, operator, value; plus booleanFilterLogic if multiple
|
||||
- Columns: Ordered list of field API names
|
||||
- Acceptance criteria: Which records appear, paging behavior, key scenarios
|
||||
|
||||
### Step 4: Author Metadata File
|
||||
Use a Lightning-compatible template and ensure valid XML:
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<ListView xmlns="http://soap.sforce.com/2006/04/metadata">
|
||||
<fullName>OpenMine</fullName>
|
||||
<label>Open - My Records</label>
|
||||
<filterScope>Mine</filterScope>
|
||||
<columns>NAME</columns>
|
||||
<columns>Status__c</columns>
|
||||
<columns>OWNER.ALIAS</columns>
|
||||
<columns>LAST_UPDATE</columns>
|
||||
<filters>
|
||||
<field>Status__c</field>
|
||||
<operation>equals</operation>
|
||||
<value>Open</value>
|
||||
</filters>
|
||||
<sharedTo>
|
||||
<role>CEO</role>
|
||||
<roleAndSubordinatesInternal>COO</roleAndSubordinatesInternal>
|
||||
</sharedTo>
|
||||
</ListView>
|
||||
```
|
||||
|
||||
Notes:
|
||||
- For "My" views, use filterScope="Mine".
|
||||
- Keep columns tight and purposeful.
|
||||
- If intended for all users, omit the "sharedTo" section.
|
||||
|
||||
### Step 5: Validate Locally
|
||||
- Well-formed XML; correct namespace
|
||||
- Field names exist on the object; operators and values match field types
|
||||
- Path and fullName alignment
|
||||
- If multiple filters: set booleanFilterLogic correctly (e.g., "1 AND (2 OR 3)")
|
||||
|
||||
### Step 6: Deploy and Verify in Org
|
||||
- Deploy the component path or the whole object.
|
||||
- In the UI, open the object tab and:
|
||||
- Confirm records match filters
|
||||
- Confirm columns render correctly
|
||||
- Confirm visibility matches audience
|
||||
|
||||
## Common Deployment Errors
|
||||
|
||||
| Error | Cause | Fix |
|
||||
|-------|---------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|
|
||||
| "Invalid field Status" | Used label instead of API name, or used API Name instead of defined name for Standard Field | Use Status__c (or correct API name), or NAME instead of Name (for Standard Fields) |
|
||||
| "Invalid filter operator" | Operator not valid for field type | Choose operation compatible with field type (e.g., equals for picklist) |
|
||||
| "Component not found at path" | Wrong folder or file name | Place in objects/<Object>/listViews and align file name with fullName |
|
||||
| "Malformed booleanFilterLogic" | Syntax or index mismatch | Use "1 AND 2" style, ensure filters index order matches |
|
||||
|
||||
## Verification Checklist
|
||||
- [ ] All required fields populated (fullName, label, filterScope, columns)
|
||||
- [ ] Property values are XML-encoded where needed
|
||||
- [ ] Custom Field references use API names (e.g., Status__c)
|
||||
- [ ] Standard Field references use defined names (e.g., NAME)
|
||||
- [ ] Operations match field types; picklist values are valid
|
||||
- [ ] booleanFilterLogic (if used) matches filters ordering and count
|
||||
- [ ] File path and fullName/developerName are aligned
|
||||
- [ ] No deprecated or Classic-only properties included
|
||||
- [ ] Deployed successfully and visible as intended
|
||||
- [ ] Records, columns, and filtering behave as specified
|
||||
@ -1,186 +0,0 @@
|
||||
---
|
||||
name: salesforce-experience-site
|
||||
description: Generate Digital Experience Site metadata including Network, CustomSite, and DigitalExperienceBundle configurations. Use when creating Experience Cloud sites or web apps.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
- Create Experience Cloud sites or communities
|
||||
- Build customer-facing portals
|
||||
- Set up site configuration and settings
|
||||
- Generate Experience Site metadata
|
||||
- Troubleshoot deployment errors related to Experience Sites
|
||||
|
||||
## Specification
|
||||
|
||||
# Digital Experience Site Metadata Specification
|
||||
|
||||
## 📋 Overview
|
||||
Digital Experience Sites for building and hosting websites backed by either Salesforce or web app (React) metadata.
|
||||
|
||||
## 🎯 Purpose
|
||||
- Provide a website for retail and customer services.
|
||||
- Use either Salesforce Experience metadata or something else like React or Angular.
|
||||
- Configure site, network, and app settings for the website.
|
||||
|
||||
## ⚙️ Required Properties
|
||||
### Core Site Properties
|
||||
- **siteName**: You must determine the name of the site. You must make the name `UpperCamelCase` (e.g., `'MyCommunity'`).
|
||||
- **siteUrlPathPrefix**. You must determine the url path prefix of the site. You must make the url path prefix `kebab-case`. You must convert the site name to the url prefix if an explicit prefix is not provided (e.g., `'my-community'`).
|
||||
- **templateType**: You must determine what type of template is being used for the site. Default to `OneRuntime`.
|
||||
|
||||
## 🔧 Site Template Types
|
||||
### OneRuntime
|
||||
- **Purpose**: Support a site or web app backed by a non-Salesforce metadata framework like React or Angular
|
||||
|
||||
## 🔄 Generation Workflow
|
||||
You must follow the steps below to generate insertable Digital Experience Site metadata.
|
||||
|
||||
### Step 1: Determine the Template Type
|
||||
- You must first determine the template type of the Experience Site using the Site Template Types section.
|
||||
|
||||
### Step 2: Use Template Type to Get Metadata Configurations for Project Structure and Fields
|
||||
- You must determine the project structure and fields for the chosen template type.
|
||||
- You must resolve all properties and fields.
|
||||
- You must use the following configurations for OneRuntime template type:
|
||||
|
||||
#### OneRuntime Template Type Configuration
|
||||
#### Project Structure
|
||||
#### Additional Instructions
|
||||
- You must construct the project folders to match the provided paths.
|
||||
- You must use the `get_metadata_api_context` MCP tool to get the schemas for `DigitalExperienceConfig`, `DigitalExperienceBundle`, `Network`, and `CustomSite`.
|
||||
|
||||
#### Configuration
|
||||
- DigitalExperienceConfig
|
||||
- Path: `digitalExperienceConfigs/{siteName}1.digitalExperienceConfig`
|
||||
- DigitalExperienceBundle
|
||||
- Path: `digitalExperiences/site/{siteName}1/{siteName}1.digitalExperience-meta.xml`
|
||||
- Network
|
||||
- Path: `networks/{siteName}.network`
|
||||
- CustomSite
|
||||
- Path: `sites/{siteName}.site`
|
||||
- DigitalExperience
|
||||
- Path: `digitalExperiences/site/{siteName}1/{contentType}/{apiName}/*`
|
||||
- Description: These are the content component directories defining site and language information. Each directory must have a `_meta.json` and `content.json` file.
|
||||
- Required component content types (`contentType`):
|
||||
- `sfdc_cms__site`
|
||||
|
||||
#### Fields
|
||||
#### Additional Site Properties
|
||||
- **namespace**: You must determine the namespace of the React app. Default to empty.
|
||||
- **appDevName**. You must determine the developer name of the React app. Default to empty.
|
||||
|
||||
#### Configuration
|
||||
- `DigitalExperienceConfig`
|
||||
- label: {siteName}
|
||||
- urlPathPrefix: {siteUrlPathPrefix}
|
||||
- space: site/{siteName}1
|
||||
|
||||
- `DigitalExperienceBundle`
|
||||
- label: {siteName}1
|
||||
|
||||
- `Network`
|
||||
- allowInternalUserLogin: false
|
||||
- allowMembersToFlag: false
|
||||
- changePasswordTemplate: unfiled$public/CommunityChangePasswordEmailTemplate
|
||||
- disableReputationRecordConversations: true
|
||||
- emailSenderAddress: admin@company.com
|
||||
- emailSenderName: {siteName}
|
||||
- embeddedLoginEnabled: false
|
||||
- enableApexCDNCaching: true
|
||||
- enableCustomVFErrorPageOverrides: false
|
||||
- enableDirectMessages: true
|
||||
- enableExpFriendlyUrlsAsDefault: false
|
||||
- enableExperienceBundleBasedSnaOverrideEnabled: true
|
||||
- enableGuestChatter: false
|
||||
- enableGuestFileAccess: false
|
||||
- enableGuestMemberVisibility: false
|
||||
- enableImageOptimizationCDN: true
|
||||
- enableInvitation: false
|
||||
- enableKnowledgeable: false
|
||||
- enableLWRExperienceConnectedApp: true
|
||||
- enableMemberVisibility: false
|
||||
- enableNicknameDisplay: true
|
||||
- enablePrivateMessages: false
|
||||
- enableReputation: false
|
||||
- enableShowAllNetworkSettings: false
|
||||
- enableSiteAsContainer: true
|
||||
- enableTalkingAboutStats: true
|
||||
- enableTopicAssignmentRules: true
|
||||
- enableTopicSuggestions: false
|
||||
- enableUpDownVote: false
|
||||
- forgotPasswordTemplate: unfiled$public/CommunityForgotPasswordEmailTemplate
|
||||
- gatherCustomerSentimentData: false
|
||||
- headlessForgotPasswordTemplate: unfiled$public/CommunityHeadlessForgotPasswordTemplate
|
||||
- headlessRegistrationTemplate: unfiled$public/CommunityHeadlessRegistrationTemplate
|
||||
- networkMemberGroups:
|
||||
- profile: admin
|
||||
- networkPageOverrides:
|
||||
- changePasswordPageOverrideSetting: Standard
|
||||
- forgotPasswordPageOverrideSetting: Designer
|
||||
- homePageOverrideSetting: Designer
|
||||
- loginPageOverrideSetting: Designer
|
||||
- selfRegProfilePageOverrideSetting: Designer
|
||||
- newSenderAddress: admin@company.com
|
||||
- picassoSite: {siteName}1
|
||||
- selfRegistration: false
|
||||
- sendWelcomeEmail: true
|
||||
- site: {siteName}
|
||||
- siteArchiveStatus: NotArchived
|
||||
- status: UnderConstruction
|
||||
- tabs:
|
||||
- defaultTab: home
|
||||
- standardTab: Chatter
|
||||
- urlPathPrefix: {siteUrlPathPrefix}vforcesite
|
||||
- welcomeTemplate: unfiled$public/CommunityWelcomeEmailTemplate
|
||||
|
||||
- `CustomSite`
|
||||
- active: true
|
||||
- allowGuestPaymentsApi: false
|
||||
- allowHomePage: false
|
||||
- allowStandardAnswersPages: false
|
||||
- allowStandardIdeasPages: false
|
||||
- allowStandardLookups: false
|
||||
- allowStandardPortalPages: true
|
||||
- allowStandardSearch: false
|
||||
- authorizationRequiredPage: CommunitiesLogin
|
||||
- bandwidthExceededPage: BandwidthExceeded
|
||||
- browserXssProtection: true
|
||||
- cachePublicVisualforcePagesInProxyServers: true
|
||||
- clickjackProtectionLevel: SameOriginOnly
|
||||
- contentSniffingProtection: true
|
||||
- enableAuraRequests: true
|
||||
- fileNotFoundPage: FileNotFound
|
||||
- genericErrorPage: Exception
|
||||
- inMaintenancePage: InMaintenance
|
||||
- indexPage: CommunitiesLanding
|
||||
- masterLabel: {siteName}
|
||||
- redirectToCustomDomain: false
|
||||
- referrerPolicyOriginWhenCrossOrigin: true
|
||||
- selfRegPage: CommunitiesSelfReg
|
||||
- siteType: ChatterNetwork
|
||||
- urlPathPrefix: {siteUrlPathPrefix}vforcesite
|
||||
|
||||
- `DigitalExperience`
|
||||
1. sfdc_cms__site
|
||||
- apiName: {siteName}1
|
||||
- type: sfdc_cms__site
|
||||
- title: {siteName}
|
||||
- urlName: {siteUrlPathPrefix}
|
||||
- contentBody:
|
||||
- authenticationType: AUTHENTICATED_WITH_PUBLIC_ACCESS_ENABLED
|
||||
- appContainer: true
|
||||
- appSpace: {namespace}__{appDevName}
|
||||
|
||||
### Step 3: Create a Project Structure for the Chosen Template Type
|
||||
You must construct a metadata project folder using the knowledge from Step 2.
|
||||
|
||||
### Step 4: Resolve All Required Fields for the Chosen Template Type
|
||||
You must determine values for all required metadata fields using the knowledge from Step 2.
|
||||
|
||||
## ✅ Verification Checklist
|
||||
- [ ] All properties are resolved.
|
||||
- [ ] All metadata directories and files are created based on the template type configurations.
|
||||
- [ ] All metadata fields are populated based on the template type configurations.
|
||||
- [ ] All metadata is validated by running CLI command `sf project deploy validate --metadata DigitalExperienceBundle DigitalExperience DigitalExperienceConfig Network CustomSite --target-org ${usernameOrAlias}`
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
name: salesforce-validation-rule
|
||||
description: Generate ValidationRule metadata XML with proper formula syntax, CDATA handling, and error messages. Use when creating validation rules to enforce business logic at the data layer.
|
||||
description: Use this skill when users need to create, modify, or validate Salesforce Validation Rules. Trigger when users mention validation rules, field validation, data quality rules, formula validation, error messages, or validation logic. Also use when users encounter validation errors, need to update formulas, or want to enforce business rules at the data layer. Always use this skill for any validation rule work.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
84
skills/salesforce-web-app-creating-records/SKILL.md
Normal file
84
skills/salesforce-web-app-creating-records/SKILL.md
Normal file
@ -0,0 +1,84 @@
|
||||
---
|
||||
name: salesforce-web-app-creating-records
|
||||
description: Use this skill when users need to create Salesforce records from React web applications. Trigger when users mention createRecord, creating leads/contacts/custom objects from web apps, handling record IDs, form submissions to Salesforce, or Application__c custom objects. Always use this skill for any record creation from React apps.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
- Create Salesforce records from web applications
|
||||
- Implement createRecord functionality for custom or standard objects
|
||||
- Handle record ID extraction from create responses
|
||||
- Troubleshoot deployment errors related to record creation
|
||||
|
||||
|
||||
# Creating Salesforce records (webApplication)
|
||||
|
||||
## Overview
|
||||
Implement list and create functionality for any custom object using GraphQL queries and createRecord API with automatic list refresh.
|
||||
|
||||
## API
|
||||
|
||||
- Use **createRecord** from `@salesforce/webapp-experimental/api`:
|
||||
- `createRecord(objectApiName: string, fields: Record<string, unknown>)` → returns a result object that may contain the new record id in different shapes depending on the API version.
|
||||
|
||||
## Getting the new record id
|
||||
|
||||
The create response is not always a simple `{ id: string }`. Handle both common shapes so you don't get "Create succeeded but no record id returned":
|
||||
|
||||
- Prefer **result.id** when it's a string.
|
||||
- Else read **result.fields.Id.value** (or equivalent) if the API returns the id inside a fields wrapper.
|
||||
|
||||
Example helper:
|
||||
|
||||
```ts
|
||||
function getRecordIdFromResponse(result: Record<string, unknown>): string {
|
||||
const id =
|
||||
typeof result.id === "string"
|
||||
? result.id
|
||||
: (result.fields as Record<string, { value?: string }> | undefined)?.Id?.value;
|
||||
if (!id) throw new Error("Create succeeded but no record id returned");
|
||||
return id;
|
||||
}
|
||||
```
|
||||
|
||||
Use this after `createRecord()` and return `{ id }` to the caller so the UI can show success or navigate.
|
||||
|
||||
## Field set and org schema
|
||||
|
||||
- **Only send fields that exist in the org.** If you send a field that doesn't exist (e.g. custom field not deployed), the API can return POST body parse errors (e.g. "Field X does not exist").
|
||||
- For **custom objects**, deploy the object and its fields (e.g. via SFDX/CLI or metadata API) before relying on them in the app.
|
||||
- **Fallback:** If you need to capture data that might not have a custom field yet (e.g. contact details), store it in a long text area or similar (e.g. `Employment_Info__c`) as a blob (e.g. JSON or line-based text) so no data is lost and the create still succeeds.
|
||||
|
||||
## Custom objects (e.g. Application__c)
|
||||
|
||||
- Define the object and fields in the project's Salesforce metadata (e.g. `objects/Application__c/`, `fields/*.field-meta.xml`).
|
||||
- In the app, build a `fields` object with only the API names and values you want to set; omit required fields only if they have defaults.
|
||||
- Use a typed input interface and map it to the `fields` passed to `createRecord`; optionally combine contact/extra info into one blob field if some fields might not be deployed.
|
||||
|
||||
## Standard objects (e.g. Lead)
|
||||
|
||||
- Use standard field API names: **FirstName**, **LastName**, **Email**, **Company**, **Phone**, **Description**, **LeadSource**, etc.
|
||||
- **LeadSource** helps distinguish origin (e.g. "Website", "Website Newsletter").
|
||||
- For "Contact Us" → Lead: map subject to **Company** (or a custom field if available), message to **Description**.
|
||||
- For newsletter signup → Lead: set **Email**; use a placeholder **LastName** (e.g. "Newsletter Subscriber") and **Company** (e.g. "Website") so the Lead is valid.
|
||||
|
||||
## Structure
|
||||
|
||||
| Concern | Where |
|
||||
|--------|--------|
|
||||
| Create custom object (e.g. Application) | e.g. `src/api/applicationApi.ts` — `createApplicationRecord(input)` → `createRecord("Application__c", fields)` |
|
||||
| Create standard object (e.g. Lead) | e.g. `src/api/leadApi.ts` — `createContactUsLead(input)`, `createNewsletterLead(email)` |
|
||||
| Form UI | Pages that collect data and call these APIs; show success/error and optionally redirect or reset form |
|
||||
|
||||
## Errors
|
||||
|
||||
- **"Field X does not exist"** → Remove that field from the payload or deploy the field to the org.
|
||||
- **"Create succeeded but no record id returned"** → Use the id-extraction pattern above (result.id or result.fields.Id.value).
|
||||
- **Validation errors** → Return and display the API error message; fix required/invalid values in the form.
|
||||
|
||||
## Verification
|
||||
|
||||
- Deploy object/fields to the org if using custom objects.
|
||||
- Run the create flow in the app; confirm the record appears in the org and the UI shows success and the new id if needed.
|
||||
- Test with minimal required fields first, then add optional or blob fields.
|
||||
70
skills/salesforce-web-app-feature/SKILL.md
Normal file
70
skills/salesforce-web-app-feature/SKILL.md
Normal file
@ -0,0 +1,70 @@
|
||||
---
|
||||
name: salesforce-web-app-feature
|
||||
description: Use this skill when users need to add features to Salesforce React web applications. Trigger when users mention adding authentication, search, charts, GraphQL, ShadCN components, Agentforce conversation client, or any feature packages. Also use when users want to install npm packages, copy-then-adjust workflow, or integrate official feature packages. This is the PRIMARY skill for web app features - always prefer official packages listed here.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
- Add features to Salesforce React web applications
|
||||
- Install and integrate feature packages (authentication, search, charts, etc.)
|
||||
- Follow copy-then-adjust workflow for feature integration
|
||||
- Troubleshoot deployment errors related to web application features
|
||||
|
||||
|
||||
# Adding a new webApplication feature
|
||||
|
||||
**Always prefer the features listed below.** When the user asks to add auth, search, charts, navigation, GraphQL, shared UI, or Agentforce conversation (ACC/copilot/agent) to a webapp, match their request to one of the official feature packages in the table in section 1. Use those packages first; only build from scratch or use other solutions when no listed feature fits.
|
||||
|
||||
When the user asks to add a feature to their app, follow this workflow.
|
||||
|
||||
When adding a feature, integrating code from an npm package, or bringing in a reference implementation:
|
||||
|
||||
1. **Prefer copying over rewriting.** Use `cp` (or equivalent) to copy files from the source (e.g. `node_modules/<package>/dist/...` or a reference app) into this project. Do not retype or rewrite the same code by hand.
|
||||
|
||||
2. **Then adjust.** After copying, do minimal edits: fix import paths (e.g. change relative `../../` imports to the project's path alias like `@/`), update any app-specific config, and remove or adapt anything that doesn't apply.
|
||||
|
||||
3. **When to copy.** Copy when:
|
||||
- Installing a feature from a template/feature package (e.g. authentication, search, charts).
|
||||
- The package ships full source in `dist/` or `src/` that is meant to be integrated.
|
||||
- You would otherwise be recreating multiple files by reading a reference and typing them out.
|
||||
|
||||
4. **When rewriting is okay.** Only rewrite or create from scratch when:
|
||||
- The source is not file-based (e.g. only docs or snippets).
|
||||
- The integration is a thin wrapper or a single small file.
|
||||
- Copying would pull in a large, unrelated tree and the actual need is a small part of it.
|
||||
|
||||
## 1. Match the request to a feature
|
||||
|
||||
**Prefer these features.** Always check this table first; use the matching package when it fits the user's need.
|
||||
|
||||
Available features (npm packages):
|
||||
|
||||
| Feature | Package | Description | Integration notes |
|
||||
|------------------------------------| ----------------------------------------------------------------------- | ---------------------------------------------------------------------- |-------------------------------------------------------------------------|
|
||||
| **Authentication** | `@salesforce/webapp-template-feature-react-authentication-experimental` | Login, register, password reset, protected routes | Copy-then-adjust; fix imports to `@/`; align with app layout and routes |
|
||||
| **Global search** | `@salesforce/webapp-template-feature-react-global-search-experimental` | Search single Salesforce objects with filters and pagination | Copy-then-adjust; fix imports to `@/`; align with app layout and routes |
|
||||
| **Charts** | `@salesforce/webapp-template-feature-react-chart-experimental` | Recharts line/bar charts with theming (AnalyticsChart, ChartContainer) | Copy-then-adjust; fix imports to `@/`; align with app layout and routes |
|
||||
| **GraphQL data access** | `@salesforce/webapp-template-feature-graphql-experimental` | executeGraphQL utilities, codegen tooling, and example AccountsTable | Copy-then-adjust; fix imports to `@/` and `@api/` |
|
||||
| **Shared UI (shadcn)** | `@salesforce/webapp-template-feature-react-shadcn-experimental` | Button, Card, Input, Select, Table, Tabs, and other ShadCN components | Copy-then-adjust per README/AGENT.md |
|
||||
| **Agentforce conversation client** | `@salesforce/webapp-template-feature-react-agentforce-conversation-client-experimental` | React wrapper for embedded Agentforce conversation client (agent chat UI) via Lightning Out 2.0; automatic auth resolution; `<AgentforceConversationClient />` component | Import from package (not copy) per README/AGENT.md |
|
||||
|
||||
If no feature matches, tell the user and offer to build it from scratch following the project's existing patterns. Do not substitute third-party or custom implementations when one of the features above matches—always prefer the listed packages.
|
||||
|
||||
## 2. Install the npm package
|
||||
|
||||
```bash
|
||||
npm install <package-name>
|
||||
```
|
||||
|
||||
## 3. Read the README.md / AGENT.md
|
||||
|
||||
The `node_modules` folder of the installed package contains a README.md and/or AGENT.md. Load it and follow its instructions.
|
||||
|
||||
## 4. Always validate
|
||||
|
||||
After integrating, **always validate** with:
|
||||
|
||||
```bash
|
||||
npm i && npm run build && npm run dev
|
||||
```
|
||||
36
skills/salesforce-web-app-list-and-create-records/SKILL.md
Normal file
36
skills/salesforce-web-app-list-and-create-records/SKILL.md
Normal file
@ -0,0 +1,36 @@
|
||||
---
|
||||
name: salesforce-web-app-list-and-create-records
|
||||
description: Use this skill when users need to list and create records for Salesforce custom objects from React web apps. Trigger when users mention list and create patterns, GraphQL queries, refetch after create, form picklists matching object schema, or dashboard widgets showing record lists. Always use this skill for list+create patterns.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
- Implement list and create functionality for custom objects
|
||||
- Build GraphQL queries for listing records
|
||||
- Create records and update lists without page reload
|
||||
- Troubleshoot deployment errors related to list and create operations
|
||||
|
||||
|
||||
# List and create records (webApplication)
|
||||
|
||||
## Pattern
|
||||
|
||||
- **List:** Query the object via **GraphQL** (`executeGraphQL`, `uiapi.query.ObjectApiName__c`). Use **webApplicationFeature** (GraphQL) for the connection shape (first/after, edges.node, field `{ value, displayValue }`). Map nodes to a simple summary type; sort client-side by date or other field if needed.
|
||||
- **Create:** Use **createRecord** from `@salesforce/webapp-experimental/api`. See **webApplicationCreatingRecords** for required/optional fields and id handling.
|
||||
- **Hook:** One hook that fetches the list on mount and exposes `refetch`. After a successful create, call `refetch()` so the list updates without a full page reload.
|
||||
- **Form:** Collect only fields that exist on the object. For picklist fields, use option values that **match the object's value set** (e.g. from the object's field metadata or a known value set). Default required picklists (e.g. Status to "New", Priority to "Standard") when the object defines defaults.
|
||||
- **UI:** Table or cards for the list; form above or on a separate route. Show loading and error states for both list and submit. Optional: dashboard widget showing a slice of the list (e.g. first N items) with a "See all" link.
|
||||
|
||||
## Structure (generic)
|
||||
|
||||
| Concern | Where |
|
||||
|--------|--------|
|
||||
| API: list + create | e.g. `src/api/<objectName>Api.ts` — query function (GraphQL) and create function (createRecord) |
|
||||
| Hook: list + refetch | e.g. `src/hooks/use<ObjectName>List.ts` — returns `{ items, loading, error, refetch }` |
|
||||
| Page | Form (controlled inputs, submit → create → refetch) and table/list of items |
|
||||
|
||||
## Cross-references
|
||||
|
||||
- **webApplicationFeature** — Feature packages including GraphQL (connection shape, node shape, field value extraction).
|
||||
- **webApplicationCreatingRecords** — createRecord, id extraction, only send existing fields, picklist/required handling.
|
||||
34
skills/salesforce-web-application/SKILL.md
Normal file
34
skills/salesforce-web-application/SKILL.md
Normal file
@ -0,0 +1,34 @@
|
||||
---
|
||||
name: salesforce-web-application
|
||||
description: Directory of web application (React) sub-knowledges for Salesforce React BYO, feature packages, and copy-then-adjust workflow. Use when working with Salesforce web applications.
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
- Work with Salesforce React web applications
|
||||
- Understand available web application features and workflows
|
||||
- Navigate web application knowledge resources
|
||||
- Troubleshoot deployment errors related to web applications
|
||||
|
||||
## Specification
|
||||
|
||||
## Overview
|
||||
|
||||
This skill provides guidance for working with Salesforce React web applications (Salesforce BYO React template). It covers adding features, creating Salesforce records, and listing/creating custom object records.
|
||||
|
||||
## Web Applications — Directory
|
||||
|
||||
This is the **directory** of sub-knowledges for web applications (Salesforce React BYO, feature packages, copy-then-adjust workflow). **Call `get_expert_knowledge` again with one of the topic names below** to load the relevant knowledge.
|
||||
|
||||
## Sub-knowledges (use as `topic` in get_expert_knowledge)
|
||||
|
||||
| Topic name | Use when |
|
||||
|-----------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **webApplicationFeature** | Adding a feature to a webapp: authentication, search, charts, GraphQL, ShadCN, Agentforce conversation client. Feature table, npm install, copy-then-adjust workflow |
|
||||
| **webApplicationCreatingRecords** | Creating Salesforce records: createRecord, custom/standard objects, id handling, Application__c, Lead |
|
||||
| **webApplicationListAndCreateRecords** | List + create any custom object: GraphQL list, createRecord, hook with refetch, form picklists match object |
|
||||
|
||||
**Flow:** After reading this directory, call `get_expert_knowledge({ topic: "<subTopicName>" })` with the single sub-topic that best matches the user's request (e.g. `webApplicationFeature`, `webApplicationCreatingRecords`).
|
||||
|
||||
**Adding features:** Always prefer the feature packages listed in **webApplicationFeature** (authentication, search, charts, nav, GraphQL, ShadCN, Agentforce conversation) over building from scratch or other solutions when one of them matches the request.
|
||||
@ -1,67 +0,0 @@
|
||||
---
|
||||
name: lex-app-solution
|
||||
description: Build complete Lightning Applications using Application-First Development Model. Creates CustomObject, CustomField, CustomTab, FlexiPage, and CustomApplication metadata in sequence. Optionally creates ValidationRule and Flow metadata when requested. Use when user requests a complete application, system, or solution (not individual components).
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
- Build or enhance a complete Lightning Application from scratch
|
||||
- Create end-to-end solutions requiring multiple metadata types working together
|
||||
- Guide users through full application development workflows
|
||||
- Ensure proper sequencing of metadata creation (objects → fields → tabs → pages → app)
|
||||
- Make context-aware decisions about which objects need tabs and pages
|
||||
- Orchestrate CustomObject, CustomField, CustomTab, FlexiPage, and CustomApplication metadata
|
||||
- Optionally create ValidationRule and Flow metadata when requested
|
||||
|
||||
**Do not use this skill for:**
|
||||
- Creating individual metadata components (use specific metadata expert skills instead)
|
||||
- Modifying existing metadata without building a full application
|
||||
- Troubleshooting or fixing deployment errors for single components
|
||||
|
||||
## Specification
|
||||
|
||||
# Salesforce Application Development Requirements
|
||||
|
||||
You are a highly experienced and certified Salesforce Architect. Your purpose is to assist developers in generating high-quality, secure, and maintainable Salesforce metadata. You must adhere to the principles of architectural integrity, data integrity, security, and performance.
|
||||
|
||||
## The Application-First Development Model
|
||||
|
||||
**When to Use:** User requests a complete application, system, or solution (not just individual components).
|
||||
|
||||
Your approach for full applications is to build or enhance a complete Lightning Application. You must guide the user through the following logical sequence to ensure a complete and user-ready result.
|
||||
|
||||
**The Guided Application Workflow (Step-by-Step with Context):**
|
||||
|
||||
1. **App Scoping & Vision:** Define the application's purpose. Ask: "What is the name of the application we are building (e.g., 'Project Management')?
|
||||
What is its primary goal?"
|
||||
|
||||
2. **Data Foundation (Objects & Fields):** Create ALL `CustomObjects` and their `CustomFields` first. This gives you the complete data model context.
|
||||
|
||||
3. **Validation Rules (OPTIONAL):** Create `ValidationRule` metadata only if explicitly requested in the prompt. Skip this step if validation rules are not mentioned.
|
||||
|
||||
4. **Flow Automation (OPTIONAL):** Create `Flow` metadata only if explicitly requested in the prompt. Skip this step if flows are not mentioned. Flows depend on CustomObject and CustomField metadata being created first.
|
||||
|
||||
5. **Object Analysis & Tab Decision Phase (MANDATORY):**
|
||||
- **STOP and analyze each object before creating any tabs**
|
||||
- **For each object, explicitly state:** "Do users need direct access to this object?"
|
||||
- **Consider:** Is this a primary business entity, junction object, lookup-only object, or system object?
|
||||
- **Make intelligent decisions** about which objects need tabs
|
||||
- **List which objects will get tabs and which will be skipped**
|
||||
- **DO NOT proceed to tab creation until this analysis is complete**
|
||||
|
||||
6. **User Accessibility (Tabs):** Create `CustomTab` metadata **only for objects that passed the decision phase** (primary business objects that
|
||||
users need direct access to).
|
||||
|
||||
7. **User Experience (Record Pages):** Create `FlexiPage` metadata **only for objects that have tabs** (following the tab decision from step 5).
|
||||
**CRITICAL:** Follow the FlexiPage rules to generate the complete structure including field instances from the start:
|
||||
- Use the simple structure example from the rules
|
||||
- Include primaryField and secondaryFields facet regions
|
||||
- Select intelligent fields based on the object's field types
|
||||
- This ensures the highlights panel displays meaningful, relevant fields
|
||||
|
||||
8. **Application Assembly (The App):** Create the `CustomApplication` (Lightning App) itself, adding **only the tabs that were created in
|
||||
step 6** to its navigation.
|
||||
|
||||
|
||||
**Key Principle:** Always create objects first, then make context-aware decisions about tabs, then create tabs and pages only for selected objects.
|
||||
Loading…
Reference in New Issue
Block a user