@salesforce/afv-skills 1.1.0 → 1.3.0

package/skills/salesforce-experience-site/SKILL.md

@@ -1,178 +0,0 @@
----
-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.

package/skills/salesforce-fragment/SKILL.md

@@ -1,42 +0,0 @@
----
-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[]
-}
-```

package/skills/salesforce-lightning-app-build/SKILL.md

@@ -1,254 +0,0 @@
----
-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

package/skills/salesforce-web-app-creating-records/SKILL.md

@@ -1,84 +0,0 @@
----
-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.

package/skills/salesforce-web-app-feature/SKILL.md

@@ -1,70 +0,0 @@
----
-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
-```

package/skills/salesforce-web-app-list-and-create-records/SKILL.md

@@ -1,36 +0,0 @@
----
-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.