Build a complete, deployable Salesforce Lightning Experience application from a natural language description by defining a Lightning Custom Application and orchestrating its dependent metadata types in correct dependency order. Invoke specialized metadata skills when available; generate metadata directly when no skill exists.
When to Use This Skill
Use when:
User requests a "Lightning app", or "end-to-end solution"
User says "build an app", "create an application", "build a [type] app" (project management, tracking, etc.)
The work produces a custom app (CustomApplication) plus supporting metadata, not a lone object, page, or tab in isolation
Examples that should trigger this skill:
"Build a project management lightning app with Tasks, Resources, and Supplies objects"
"Create a LEX 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 lightning 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)
User only needs to create or configure an app container (grouping existing tabs) without other metadata; use
generating-custom-application
instead
Metadata Type Registry
This table shows which metadata types are commonly needed for Lightning Experience apps, their skill availability, and API context requirement.
Metadata Type
Skill Name
API Context
Usage Rule
Custom Object
generating-custom-object
salesforce-api-context
MUST load skill AND call API context
Custom Field
generating-custom-field
salesforce-api-context
MUST load skill AND call API context
Custom Tab
generating-custom-tab
salesforce-api-context
MUST load skill AND call API context
FlexiPage
generating-flexipage
salesforce-api-context
MUST load skill AND call API context
Custom Application
generating-custom-application
salesforce-api-context
MUST load skill AND call API context
List View
generating-list-view
salesforce-api-context
MUST load skill AND call API context (if requested)
Validation Rule
generating-validation-rule
salesforce-api-context
MUST load skill AND call API context (if requested)
Flow
generating-flow
metadata-experts
pipeline
MUST load skill AND run pipeline.
Exempt from
salesforce-api-context
.
Permission Set
generating-permission-set
salesforce-api-context
MUST load skill AND call API context
Usage Rules
SKILL RULE
When a skill exists for a metadata type, you
MUST
load that skill. Do NOT generate metadata directly without loading the skill first.
API CONTEXT RULE
For every metadata type (except Flow), you
MUST
call
salesforce-api-context
tools before generating. Do NOT generate metadata without calling API context first. The skill provides structure and rules; API context confirms what is valid for the current API version. Both are essential.
FALLBACK RULE
When no skill exists for a metadata type you need, generate the metadata directly using your knowledge of Salesforce Metadata API and best practices. API context is still required.
RATIONALE
Skills contain validated patterns and constraints. API context provides version-specific accuracy. Together they 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)
Metadata types in this phase:
generating-custom-object
- once, with all objects
generating-custom-field
- once, with all fields (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)
Metadata types in this phase (only if user requested):
generating-validation-rule
- once, if validation requirements mentioned
generating-flow
- once, 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)
Metadata types in this phase:
generating-list-view
- once, for filtered record views (if requested)
generating-custom-tab
- once, with all object tabs
generating-flexipage
- once, with all record/home/app pages
Phase 4: Application Assembly
Custom Application (depends on: Tabs exist)
Metadata types in this phase:
generating-custom-application
- once, to create the Lightning App container
Phase 5: Security & Access
Permission Sets (depends on: Objects, Fields, Tabs, App exist)
Execute these four steps for each metadata type, one type at a time. Complete all four steps for the current type before moving to the next type. Do NOT skip any step.
Step
What to do
Why
① Load skill
Search for and read the per-type SKILL.md
Gives you the XML structure, required elements, naming rules, and validation constraints
② Call API context
Call
salesforce-api-context
tools for this metadata type using one or more of:
get_metadata_type_sections
,
get_metadata_type_context
,
get_metadata_type_fields
,
get_metadata_type_fields_properties
,
search_metadata_types
Gives you the current valid values — allowed enum values, required vs. optional fields, child types for this API version. The skill provides structure; API context provides version-specific accuracy.
Before presenting the completed build to the user, verify cross-component integrity:
Object-Tab Coverage
Every Custom Object has at least one Custom Tab
Relationship Integrity
Every Custom Object referenced in a relationship (parent or child) exists in the build
Field References in Pages
Every field referenced in a FlexiPage exists on the corresponding object
Tab References in App
Every tab referenced in the Custom Application was successfully created
Permission Set Completeness
Permission Sets grant access to all generated objects, fields, tabs, and the application
No Orphaned Components
No tabs without objects, no pages without corresponding tabs, no app without tabs
Deployment Manifest Completeness
:
package.xml
includes all generated components in proper dependency order
Validation Failure Handling (Category 2):
If validation fails, include failed checks in the Build Summary Report under a
VALIDATION WARNINGS
section
These are post-generation issues — do NOT block delivery of the build, but clearly communicate what needs manual review or correction
Provide specific remediation steps for each failed validation check
Note
Individual component validations (reserved words, name lengths, field types, etc.) are handled by specialized metadata skills and do not need to be re-validated here.
Error Handling
Category 1: Stop and Ask User
Stop execution and ask 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
)
Category 2: Post-Generation Warnings (Log Warning, Continue)
Log warning and continue if:
Cross-component validation check fails (e.g., field referenced in FlexiPage doesn't exist on object)
Optional component generation fails (e.g., List View generation has minor issues)
Validation Rule or Flow has minor output 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
4. Validate Before Building
Check for:
Reserved words in API names
Relationship limits (max 2 M-D per object)
Name length limits
Duplicate names