mirror of
https://github.com/forcedotcom/afv-library.git
synced 2026-08-07 08:04:28 +08:00
Compare commits
2 Commits
59f7832fa0
...
dcedc58cde
| Author | SHA1 | Date | |
|---|---|---|---|
|
dcedc58cde | ||
|
|
2a91a5eb6a |
@ -1,76 +0,0 @@
|
||||
---
|
||||
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).
|
||||
@ -6,17 +6,21 @@ description: Use this skill when users need to create, generate, modify, or vali
|
||||
## When to Use This Skill
|
||||
|
||||
Use this skill when you need to:
|
||||
- Create Lightning pages (Record, App, or Home pages)
|
||||
- Build custom page layouts in Lightning Experience
|
||||
- Add components to Lightning pages
|
||||
- Configure page structure and components
|
||||
- Troubleshoot deployment errors related to FlexiPages
|
||||
- Create Lightning pages (RecordPage, AppPage, HomePage)
|
||||
- Generate FlexiPage metadata XML
|
||||
- Add components to existing FlexiPages
|
||||
- Troubleshoot FlexiPage deployment errors
|
||||
- Understand FlexiPage structure and component configuration
|
||||
- Work with page layouts or Lightning page customization
|
||||
- Edit or update ANY *.flexipage-meta.xml file
|
||||
|
||||
## Specification
|
||||
|
||||
# FlexiPage Generation Guide
|
||||
|
||||
## Overview
|
||||
Generate Lightning pages (RecordPage, AppPage, HomePage) using CLI bootstrapping + MCP actions for component discovery and configuration.
|
||||
|
||||
Generate Lightning pages (RecordPage, AppPage, HomePage) using CLI bootstrapping for component discovery and configuration.
|
||||
|
||||
---
|
||||
|
||||
@ -37,10 +41,16 @@ sf template generate flexipage \
|
||||
|
||||
**Template-specific requirements:**
|
||||
- **RecordPage**: Requires `--sobject` (e.g., Account, Custom_Object__c)
|
||||
- **RecordPage**: Requires `--primary-field` and `--secondary-fields` for dynamic highlights, `--detail-fields` for full record details. Use the most important identifying field as primary, e.g. Name. Use the secondary fields (max 12, recommended 4-6) to show a summary of the record. Use Use detail fields to show the full details of the record.
|
||||
- **RecordPage**: Requires `--primary-field` and `--secondary-fields` for dynamic highlights, `--detail-fields` for full record details. Use the most important identifying field as primary, e.g. Name. Use the secondary fields (max 12, recommended 4-6) to show a summary of the record. Use detail fields to show the full details of the record.
|
||||
- **AppPage**: No additional requirements
|
||||
- **HomePage**: No additional requirements
|
||||
|
||||
**Note:** If the `sf template generate flexipage` command fails, recommend users upgrade to the latest version of the Salesforce CLI:
|
||||
```bash
|
||||
npm install -g @salesforce/cli@latest
|
||||
```
|
||||
|
||||
|
||||
**What you get:**
|
||||
- Valid FlexiPage XML with correct structure
|
||||
- Pre-configured regions and basic components
|
||||
@ -55,32 +65,12 @@ sf project deploy start --source-dir force-app/main/default/flexipages
|
||||
|
||||
**Deploy early, deploy often.** Start with the bootstrapped page, validate it works, then enhance.
|
||||
|
||||
### Step 3: Enhance with MCP Actions (Optional)
|
||||
|
||||
If you need to add more components or customize:
|
||||
|
||||
#### A. Discover Available Components
|
||||
```
|
||||
DISCOVER_UI_COMPONENTS
|
||||
```
|
||||
Returns: List of components available for this page type with descriptions.
|
||||
|
||||
#### B. Get Component Schemas
|
||||
```
|
||||
GET_UI_COMPONENT_SCHEMAS
|
||||
```
|
||||
Returns: JSON schemas showing required/optional properties, types, data sources. Also includes instructions specific to each component.
|
||||
|
||||
#### C. Get Data Source Values
|
||||
```
|
||||
GET_DATA_SOURCE_VALUES
|
||||
```
|
||||
Returns: Valid values for properties with data sources.
|
||||
|
||||
### Step 4: Update and Redeploy
|
||||
### Step 3: Update and Redeploy
|
||||
|
||||
Modify the generated XML, adding components discovered via MCP. Deploy incrementally.
|
||||
|
||||
**Note:** Warn users to use caution with updates beyond this step when using this command.
|
||||
|
||||
---
|
||||
|
||||
## Critical XML Rules
|
||||
@ -118,7 +108,7 @@ Modify the generated XML, adding components discovered via MCP. Deploy increment
|
||||
<!-- Correct -->
|
||||
<fieldItem>Record.Name</fieldItem>
|
||||
|
||||
<!-- Wrong -->
|
||||
<!-- Wrong -->
|
||||
<fieldItem>Account.Name</fieldItem>
|
||||
```
|
||||
|
||||
@ -143,14 +133,14 @@ Modify the generated XML, adding components discovered via MCP. Deploy increment
|
||||
Every fieldInstance requires:
|
||||
```xml
|
||||
<itemInstances>
|
||||
<fieldInstance>
|
||||
<fieldInstanceProperties>
|
||||
<name>uiBehavior</name>
|
||||
<value>none</value> <!-- none|readonly|required -->
|
||||
</fieldInstanceProperties>
|
||||
<fieldItem>Record.FieldName__c</fieldItem>
|
||||
<identifier>RecordFieldName_cField</identifier>
|
||||
</fieldInstance>
|
||||
<fieldInstance>
|
||||
<fieldInstanceProperties>
|
||||
<name>uiBehavior</name>
|
||||
<value>none</value> <!-- none|readonly|required -->
|
||||
</fieldInstanceProperties>
|
||||
<fieldItem>Record.FieldName__c</fieldItem>
|
||||
<identifier>RecordFieldName_cField</identifier>
|
||||
</fieldInstance>
|
||||
</itemInstances>
|
||||
```
|
||||
|
||||
@ -161,38 +151,6 @@ Every fieldInstance requires:
|
||||
|
||||
---
|
||||
|
||||
## Using MCP Actions
|
||||
|
||||
### When to Use Each Action
|
||||
|
||||
#### DISCOVER_UI_COMPONENTS
|
||||
**When:** You want to see what components are available for your page type.
|
||||
|
||||
**Returns:** Component list with names, namespaces, descriptions.
|
||||
|
||||
**Use for:** Finding components to add to your bootstrapped page.
|
||||
|
||||
#### GET_UI_COMPONENT_SCHEMAS
|
||||
**When:** You know which components you want but need to understand their properties. If you have issues configuring a component and need more detailed instructions or knowledge.
|
||||
|
||||
**Returns:** JSON schemas with:
|
||||
- Required vs optional properties
|
||||
- Property types (string, boolean, array, etc.)
|
||||
- Data source references
|
||||
- Descriptions
|
||||
- Additional component-specific instructions or knowledge, often useful for more complex components.
|
||||
|
||||
**Use for:** Understanding how to configure components before adding to XML.
|
||||
|
||||
#### GET_DATA_SOURCE_VALUES
|
||||
**When:** A component property references a data source and you need valid values.
|
||||
|
||||
**Returns:** Valid values (e.g., "1", "2", "3" for column count).
|
||||
|
||||
**Use for:** Ensuring property values match allowed options.
|
||||
|
||||
---
|
||||
|
||||
## Common Deployment Errors
|
||||
|
||||
### "Invalid field reference"
|
||||
@ -207,10 +165,6 @@ Every fieldInstance requires:
|
||||
**Cause:** No uiBehavior specified
|
||||
**Fix:** Add `fieldInstanceProperties` with `uiBehavior`
|
||||
|
||||
### "Invalid component property"
|
||||
**Cause:** Wrong property name or format
|
||||
**Fix:** Use `GET_UI_COMPONENT_SCHEMAS` to see exact property names and types, or to find additional documentation.
|
||||
|
||||
### "Unused Facet"
|
||||
**Cause:** Facet defined but not referenced by any component
|
||||
**Fix:** Remove Facet or reference it in a component property
|
||||
@ -229,36 +183,6 @@ Every fieldInstance requires:
|
||||
|
||||
---
|
||||
|
||||
## Component-Specific Tips
|
||||
|
||||
### dynamicHighlights (RecordPage Header)
|
||||
|
||||
**Location:** Must be in `header` region.
|
||||
**Explicit Fields** (via CLI): Use the most important fields to show a summary of the record. The single primary field is used to identify the record, like a name. The secondary fields (max 12, recommended 6) are used as a summary of the record.
|
||||
```bash
|
||||
--primary-field Name
|
||||
--secondary-fields Phone,Industry,AnnualRevenue
|
||||
```
|
||||
CLI generates Facets with field references automatically.
|
||||
|
||||
### fieldSection
|
||||
|
||||
**Use for:** Displaying fields in columns.
|
||||
|
||||
**Structure:** Three-level nesting:
|
||||
1. Template Region (Region type)
|
||||
2. Column Facets (Facet type)
|
||||
3. Field Facets (Facet type)
|
||||
|
||||
**Referenced in component property:**
|
||||
```xml
|
||||
<componentInstanceProperties>
|
||||
<name>columns</name>
|
||||
<value>Facet-{uuid}</value>
|
||||
</componentInstanceProperties>
|
||||
```
|
||||
---
|
||||
|
||||
## Incremental Development Pattern
|
||||
|
||||
**Philosophy:** Deploy small, working increments. Don't build entire complex page at once.
|
||||
@ -290,14 +214,10 @@ When user provides an existing FlexiPage file path:
|
||||
- Existing component identifiers
|
||||
- Available regions (parse from file, don't assume names)
|
||||
- Existing facets
|
||||
3. **Use MCP actions** for discovery:
|
||||
- DISCOVER_UI_COMPONENTS (find available components)
|
||||
- GET_UI_COMPONENT_SCHEMAS (understand properties and get additional documentation)
|
||||
- GET_DATA_SOURCE_VALUES (validate data source values)
|
||||
4. **Generate component XML** (apply all rules from "Critical XML Rules" section)
|
||||
5. **Insert** into appropriate region
|
||||
6. **Write** modified XML back to file
|
||||
7. **Deploy**: `sf project deploy start --source-dir force-app/...`
|
||||
3. **Generate component XML** (apply all rules from "Critical XML Rules" section)
|
||||
4. **Insert** into appropriate region
|
||||
5. **Write** modified XML back to file
|
||||
6. **Deploy**: `sf project deploy start --source-dir force-app/...`
|
||||
|
||||
---
|
||||
|
||||
@ -347,13 +267,13 @@ When user provides an existing FlexiPage file path:
|
||||
**Insertion pattern**:
|
||||
```xml
|
||||
<flexiPageRegions>
|
||||
<name>main</name> <!-- or whatever region name exists -->
|
||||
<type>Region</type>
|
||||
<itemInstances><!-- Existing component 1 --></itemInstances>
|
||||
<itemInstances><!-- Existing component 2 --></itemInstances>
|
||||
<itemInstances>
|
||||
<!-- INSERT NEW COMPONENT HERE -->
|
||||
</itemInstances>
|
||||
<name>main</name> <!-- or whatever region name exists -->
|
||||
<type>Region</type>
|
||||
<itemInstances><!-- Existing component 1 --></itemInstances>
|
||||
<itemInstances><!-- Existing component 2 --></itemInstances>
|
||||
<itemInstances>
|
||||
<!-- INSERT NEW COMPONENT HERE -->
|
||||
</itemInstances>
|
||||
</flexiPageRegions>
|
||||
```
|
||||
|
||||
@ -367,52 +287,106 @@ Components like tabs, accordions, field sections require facets.
|
||||
```xml
|
||||
<!-- 1. Component in region -->
|
||||
<flexiPageRegions>
|
||||
<itemInstances>
|
||||
<componentInstance>
|
||||
<componentName>flexipage:tabset2</componentName>
|
||||
<identifier>tabs_main_1</identifier>
|
||||
<componentInstanceProperties>
|
||||
<name>tabs</name>
|
||||
<value>tab1_content</value>
|
||||
<value>tab2_content</value>
|
||||
</componentInstanceProperties>
|
||||
</componentInstance>
|
||||
</itemInstances>
|
||||
<name>main</name>
|
||||
<type>Region</type>
|
||||
<itemInstances>
|
||||
<componentInstance>
|
||||
<componentName>flexipage:tabset2</componentName>
|
||||
<identifier>tabs_main_1</identifier>
|
||||
<componentInstanceProperties>
|
||||
<name>tabs</name>
|
||||
<value>tab1_content</value>
|
||||
<value>tab2_content</value>
|
||||
</componentInstanceProperties>
|
||||
</componentInstance>
|
||||
</itemInstances>
|
||||
<name>main</name>
|
||||
<type>Region</type>
|
||||
</flexiPageRegions>
|
||||
|
||||
<!-- 2. Facets (siblings of region, NOT nested inside) -->
|
||||
<!-- 2. Facets (siblings of region, NOT nested inside) -->
|
||||
<flexiPageRegions>
|
||||
<itemInstances><!-- Tab 1 content --></itemInstances>
|
||||
<name>tab1_content</name>
|
||||
<type>Facet</type>
|
||||
<itemInstances><!-- Tab 1 content --></itemInstances>
|
||||
<name>tab1_content</name>
|
||||
<type>Facet</type>
|
||||
</flexiPageRegions>
|
||||
|
||||
<flexiPageRegions>
|
||||
<itemInstances><!-- Tab 2 content --></itemInstances>
|
||||
<name>tab2_content</name>
|
||||
<type>Facet</type>
|
||||
<itemInstances><!-- Tab 2 content --></itemInstances>
|
||||
<name>tab2_content</name>
|
||||
<type>Facet</type>
|
||||
</flexiPageRegions>
|
||||
```
|
||||
|
||||
**Critical**: Facet regions are siblings of template regions at the same level, not nested inside them.
|
||||
---
|
||||
## Component-Specific Tips
|
||||
### dynamicHighlights (RecordPage Header)
|
||||
**Location:** Must be in `header` region.
|
||||
**Explicit Fields** (via CLI): Use the most important fields to show a summary of the record. The single primary field is used to identify the record, like a name. The secondary fields (max 12, recommended 6) are used as a summary of the record.
|
||||
```bash
|
||||
--primary-field Name
|
||||
--secondary-fields Phone,Industry,AnnualRevenue
|
||||
```
|
||||
CLI generates Facets with field references automatically.
|
||||
### fieldSection
|
||||
**Use for:** Displaying fields in columns.
|
||||
**Structure:** Three-level nesting:
|
||||
1. Template Region (Region type)
|
||||
2. Column Facets (Facet type)
|
||||
3. Field Facets (Facet type)
|
||||
**Referenced in component property:**
|
||||
```xml
|
||||
<componentInstanceProperties>
|
||||
<name>columns</name>
|
||||
<value>Facet-{uuid}</value>
|
||||
</componentInstanceProperties>
|
||||
```
|
||||
|
||||
### rich Text component
|
||||
|
||||
Component name: flexipage:richText
|
||||
|
||||
Use for: Displaying HTML-formatted rich text content with support for text formatting, headings, lists, tables, images, links, forms, and multimedia elements. Preserves styling and layout. Escape all special characters in the default text.
|
||||
|
||||
Location: Can be used in any region on any page type (Home, Record, App, Community pages).
|
||||
|
||||
|
||||
CLI generates the component directly without nested structures.
|
||||
|
||||
User: "Add a rich text component to force-app/.../Account_Record_Page.flexipage-meta.xml"
|
||||
|
||||
Structure: Single-level component (no facets):
|
||||
1. Component instance (flexipage:richText) with direct properties
|
||||
|
||||
XML Structure Example:
|
||||
```xml
|
||||
<itemInstances>
|
||||
<componentInstance>
|
||||
<componentInstanceProperties>
|
||||
<name>decorate</name>
|
||||
<value>true</value>
|
||||
</componentInstanceProperties>
|
||||
<componentName>flexipage:richText</componentName>
|
||||
<identifier>flexipage_richText</identifier>
|
||||
</componentInstance>
|
||||
</itemInstances>
|
||||
```
|
||||
|
||||
Identifier Pattern: flexipage_richText or flexipage_richText_{sequence}
|
||||
|
||||
---
|
||||
|
||||
## Required Metadata Structure
|
||||
|
||||
```xml
|
||||
<FlexiPage xmlns="http://soap.sforce.com/2006/04/metadata">
|
||||
<flexiPageRegions>
|
||||
<!-- Regions and components here -->
|
||||
</flexiPageRegions>
|
||||
<masterLabel>Page Label</masterLabel>
|
||||
<template>
|
||||
<name>flexipage:recordHomeTemplateDesktop</name>
|
||||
</template>
|
||||
<type>RecordPage</type>
|
||||
<sobjectType>Object__c</sobjectType> <!-- RecordPage only -->
|
||||
<flexiPageRegions>
|
||||
<!-- Regions and components here -->
|
||||
</flexiPageRegions>
|
||||
<masterLabel>Page Label</masterLabel>
|
||||
<template>
|
||||
<name>flexipage:recordHomeTemplateDesktop</name>
|
||||
</template>
|
||||
<type>RecordPage</type>
|
||||
<sobjectType>Object__c</sobjectType> <!-- RecordPage only -->
|
||||
</FlexiPage>
|
||||
```
|
||||
|
||||
|
||||
254
skills/salesforce-lightning-app-build/SKILL.md
Normal file
254
skills/salesforce-lightning-app-build/SKILL.md
Normal file
@ -0,0 +1,254 @@
|
||||
---
|
||||
name: salesforce-lightning-app-build
|
||||
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.
|
||||
metadata:
|
||||
category: orchestration
|
||||
related-skills: salesforce-custom-object, salesforce-custom-field, salesforce-custom-tab, salesforce-flexipage, salesforce-custom-application, salesforce-flow, salesforce-validation-rule, salesforce-list-view
|
||||
---
|
||||
|
||||
# Salesforce Lightning Application Build
|
||||
|
||||
## Overview
|
||||
|
||||
Build complete Lightning Experience applications from natural language by orchestrating multiple metadata types in proper dependency order. This skill acts as a "conductor" that invokes specialized metadata skills when available, or generates metadata directly when no skill exists.
|
||||
|
||||
## When to Use This Skill
|
||||
**Use when:**
|
||||
- User requests a "complete app", "Lightning app", or "end-to-end solution"
|
||||
- User says "build an app", "create an application", "build a [type] app" (project management, tracking, etc.)
|
||||
- Request involves 3+ metadata types working together (objects + fields + pages + security)
|
||||
- User describes multiple custom objects with relationships between them
|
||||
- User mentions custom objects AND Lightning Record Pages in the same request
|
||||
- User mentions custom objects AND permission sets/security in the same request
|
||||
- Request includes phrases like "allows users to manage/track", "management system", "tracking app"
|
||||
- Need to ensure proper sequencing (Objects → Fields → UI → Security)
|
||||
|
||||
**Examples that should trigger this skill:**
|
||||
- "Build a project management app with Tasks, Resources, and Supplies objects"
|
||||
- "Create an app to track vehicles with Lightning pages and permission sets"
|
||||
- "I need a Space Station management system with multiple objects and relationships"
|
||||
- "Build an employee onboarding app with custom Lightning Record Pages"
|
||||
|
||||
**Do NOT use when:**
|
||||
- Creating a single metadata component (use specific metadata skill instead)
|
||||
- Troubleshooting or debugging existing metadata
|
||||
- Building Salesforce Classic apps (not Lightning Experience)
|
||||
- User asks for just one object, or just one page, or just one permission set (without others)
|
||||
---
|
||||
|
||||
## Metadata Type Registry
|
||||
|
||||
This table shows which metadata types are commonly needed for LEX apps and their skill availability.
|
||||
|
||||
| Metadata Type | Skill Available? | Skill Name | Usage Rule |
|
||||
|---------------|------------------|------------|------------|
|
||||
| **Custom Object** | ✅ YES | `salesforce-custom-object` | MUST use skill |
|
||||
| **Custom Field** | ✅ YES | `salesforce-custom-field` | MUST use skill |
|
||||
| **Custom Tab** | ✅ YES | `salesforce-custom-tab` | MUST use skill |
|
||||
| **FlexiPage** | ✅ YES | `salesforce-flexipage` | MUST use skill |
|
||||
| **Custom Application** | ✅ YES | `salesforce-custom-application` | MUST use skill |
|
||||
| **List View** | ✅ YES | `salesforce-list-view` | MUST use skill |
|
||||
| **Validation Rule** | ✅ YES | `salesforce-validation-rule` | MUST use skill (if requested) |
|
||||
| **Flow** | ✅ YES | `salesforce-flow` | MUST use skill (if requested) |
|
||||
| **Permission Set** | ❌ NO | - | Generate directly using Metadata API knowledge |
|
||||
|
||||
### Skill Usage Rules
|
||||
|
||||
**CRITICAL RULE**: When a skill exists for a metadata type (✅ YES in table above), you **MUST** invoke that skill. Do NOT generate the metadata directly.
|
||||
|
||||
**FALLBACK RULE**: When NO skill exists for a metadata type (❌ NO in table above), you **MAY** generate the metadata directly using your knowledge of Salesforce Metadata API and best practices.
|
||||
|
||||
**RATIONALE**: Specialized skills contain validated patterns, error handling, and field-specific knowledge that prevent deployment failures.
|
||||
|
||||
---
|
||||
|
||||
## Dependency Graph & Build Order
|
||||
|
||||
### Phase 1: Data Model (Foundation)
|
||||
```
|
||||
Custom Objects (no dependencies)
|
||||
↓
|
||||
Custom Fields (depends on: Objects exist)
|
||||
↓
|
||||
Relationships (depends on: Both parent and child objects + fields exist)
|
||||
```
|
||||
|
||||
**Skills to invoke in order:**
|
||||
1. `salesforce-custom-object` for each object
|
||||
2. `salesforce-custom-field` for each field (including Master-Detail, Lookup, Roll-up Summary)
|
||||
|
||||
### Phase 2: Business Logic (Optional - only if requested)
|
||||
```
|
||||
Validation Rules (depends on: Fields exist)
|
||||
↓
|
||||
Flows (depends on: Objects, Fields exist)
|
||||
```
|
||||
|
||||
**Skills to invoke (only if user requested):**
|
||||
1. `salesforce-validation-rule` if validation requirements mentioned
|
||||
2. `salesforce-flow` if automation/workflow requirements mentioned
|
||||
|
||||
### Phase 3: User Interface
|
||||
```
|
||||
List Views (depends on: Objects, Fields exist)
|
||||
↓
|
||||
Custom Tabs (depends on: Objects exist)
|
||||
↓
|
||||
FlexiPages (depends on: Objects, Tabs exist)
|
||||
```
|
||||
|
||||
**Skills to invoke in order:**
|
||||
1. `salesforce-list-view` for filtered record views (if requested)
|
||||
2. `salesforce-custom-tab` for each object tab
|
||||
3. `salesforce-flexipage` for record/home/app pages
|
||||
|
||||
### Phase 4: Application Assembly
|
||||
```
|
||||
Custom Application (depends on: Tabs exist)
|
||||
```
|
||||
|
||||
**Skills to invoke:**
|
||||
1. `salesforce-custom-application` to create the Lightning App container
|
||||
|
||||
### Phase 5: Security & Access
|
||||
```
|
||||
Permission Sets (depends on: Objects, Fields, Tabs, App exist)
|
||||
```
|
||||
|
||||
**Fallback generation (no skill available):**
|
||||
1. Generate Permission Set XML directly with access to:
|
||||
- Objects (Read, Create, Edit, Delete)
|
||||
- Fields (Read, Edit)
|
||||
- Tabs (Visible)
|
||||
- Custom Application (Visible)
|
||||
|
||||
---
|
||||
|
||||
## Execution Workflow
|
||||
|
||||
### STEP 1: Requirements Analysis & Planning
|
||||
|
||||
**Actions:**
|
||||
1. Parse user's natural language request
|
||||
2. Extract business entities (become Custom Objects)
|
||||
3. Extract attributes/properties (become Custom Fields)
|
||||
4. Identify relationships (Master-Detail, Lookup)
|
||||
5. Detect validation requirements (become Validation Rules)
|
||||
6. Detect automation requirements (become Flows)
|
||||
7. Identify user personas (inform Permission Sets)
|
||||
|
||||
**Output: Build Plan**
|
||||
|
||||
Generate a structured plan listing:
|
||||
|
||||
```
|
||||
📋 Lightning App Build Plan: [App Name]
|
||||
|
||||
DATA MODEL:
|
||||
- Custom Objects: [list with object names]
|
||||
- Custom Fields: [list grouped by object]
|
||||
- Relationships: [list M-D and Lookup relationships]
|
||||
|
||||
BUSINESS LOGIC (if applicable):
|
||||
- Validation Rules: [list with object and rule name]
|
||||
- Flows: [list with flow name and type]
|
||||
|
||||
USER INTERFACE:
|
||||
- List Views: [list with object and view name]
|
||||
- Custom Tabs: [list with object]
|
||||
- FlexiPages: [list with page name and type]
|
||||
- Custom Application: [app name]
|
||||
|
||||
SECURITY:
|
||||
- Permission Sets: [list with purpose]
|
||||
|
||||
METADATA SKILLS TO INVOKE:
|
||||
- salesforce-custom-object (x N)
|
||||
- salesforce-custom-field (x N)
|
||||
- salesforce-validation-rule (x N) - if validation requirements identified
|
||||
- salesforce-flow (x N) - if automation requirements identified
|
||||
- salesforce-custom-tab (x N)
|
||||
- salesforce-flexipage (x N)
|
||||
- salesforce-custom-application (x 1)
|
||||
- [fallback] Permission Set XML generation (x N)
|
||||
|
||||
DEPENDENCY ORDER:
|
||||
1. Phase 1: Data Model (Objects → Fields)
|
||||
2. Phase 2: Business Logic (Validation Rules → Flows)
|
||||
3. Phase 3: User Interface (List Views → Tabs → Pages)
|
||||
4. Phase 4: App Assembly (Application)
|
||||
5. Phase 5: Security (Permission Sets)
|
||||
```
|
||||
|
||||
### STEP 2: Skill Invocation Sequence
|
||||
|
||||
Execute in strict dependency order. For each metadata component:
|
||||
|
||||
1. **Check Metadata Type Registry**: Does a skill exist?
|
||||
2. **If YES (✅)**: Invoke the specialized skill with required parameters
|
||||
3. **If NO (❌)**: Generate metadata directly using Metadata API knowledge
|
||||
4. **Handle Errors**: If skill invocation fails, log error and continue (don't block entire app)
|
||||
|
||||
**Invocation Pattern Example:**
|
||||
|
||||
- For Custom Object → Invoke `salesforce-custom-object`
|
||||
- For Custom Field → Invoke `salesforce-custom-field`
|
||||
- For Validation Rule → Invoke `salesforce-validation-rule`
|
||||
- For Flow → Invoke `salesforce-flow`
|
||||
- For Custom Tab → Invoke `salesforce-custom-tab`
|
||||
- For FlexiPage → Invoke `salesforce-flexipage`
|
||||
- For Custom Application → Invoke `salesforce-custom-application`
|
||||
- For Permission Sets (no skill) → Generate XML directly
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Critical Errors (Stop Execution)
|
||||
|
||||
Stop and ask user for clarification if:
|
||||
- User request is too vague to extract any objects or fields
|
||||
- Conflicting requirements detected (e.g., "make it private" + "everyone should see it")
|
||||
- Invalid Salesforce naming detected (reserved words like `Order`, `Group`)
|
||||
|
||||
### Non-Critical Errors (Continue with Warning)
|
||||
|
||||
Log warning and continue if:
|
||||
- Optional component fails (e.g., List View generation fails)
|
||||
- Skill invocation fails for non-critical metadata
|
||||
- Validation Rule or Flow has minor issues
|
||||
|
||||
**Warning Pattern:**
|
||||
```
|
||||
⚠️ Warning: [Component Type] generation encountered issue
|
||||
Component: [Name]
|
||||
Issue: [Description]
|
||||
Impact: [What won't work]
|
||||
Recommendation: [How to fix manually]
|
||||
|
||||
Continuing with remaining components...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### 1. Always Follow Dependency Order
|
||||
Never invoke skills out of sequence. Fields need objects, pages need tabs, apps need tabs.
|
||||
|
||||
### 2. Use Skills When Available
|
||||
Don't reinvent the wheel. Specialized skills have field-specific validation that prevents deployment errors.
|
||||
|
||||
### 3. Generate Thoughtful Defaults
|
||||
When user doesn't specify details:
|
||||
- Use Text name fields for human entities
|
||||
- Use AutoNumber for transactions
|
||||
- Enable Search and Reports for user-facing objects
|
||||
- Set sharingModel based on relationships
|
||||
|
||||
### 5. Validate Before Building
|
||||
Check for:
|
||||
- Reserved words in API names
|
||||
- Relationship limits (max 2 M-D per object)
|
||||
- Name length limits
|
||||
- Duplicate names
|
||||
Loading…
Reference in New Issue
Block a user