@salesforce/afv-skills 1.27.0 → 1.29.0

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

@@ -17,16 +17,16 @@ Use this skill when you need to:
 
 # CustomTab Metadata Specification
 
-## 📋 Overview
+## Overview
 Custom tabs for navigating to objects, web content, or Visualforce pages within Salesforce applications.
 
-## 🎯 Purpose
+## Purpose
 - Provide navigation to custom objects
 - Link to external web content
 - Access Visualforce pages
 - Organize application navigation
 
-## ⚙️ Required Properties
+## Required Properties
 
 ### Core Tab Properties
 - **customObject**: `true` for custom object tabs, `false` for all others.
@@ -36,7 +36,7 @@ Custom tabs for navigating to objects, web content, or Visualforce pages within
 - **page**: Visualforce page name (for Visualforce tabs)
 
 
-### 🚨 STRICT ELEMENT ALLOWLIST — READ THIS FIRST
+### STRICT ELEMENT ALLOWLIST — READ THIS FIRST
 
 **The root element MUST always be `<CustomTab>` (NOT `<Tab>`).** The XML namespace must be `xmlns="http://soap.sforce.com/2006/04/metadata"`.
 
@@ -48,7 +48,7 @@ Only the elements listed below are valid. **Any element not on this list WILL ca
 | **Web tabs** | `<customObject>` (required, set to `false`), `<label>` (required), `<motif>` (required), `<url>` (required), `<urlEncodingKey>` (required, set to `UTF-8`), `<description>` (optional), `<frameHeight>` (optional) |
 | **Visualforce tabs** | `<customObject>` (required, set to `false`), `<label>` (required), `<motif>` (required), `<page>` (required), `<description>` (optional) |
 
-### ⚠️ FORBIDDEN ELEMENTS (every one of these causes a deployment error)
+### FORBIDDEN ELEMENTS (every one of these causes a deployment error)
 `<sobjectName>`, `<name>`, `<fullName>`, `<apiVersion>`, `<isHidden>`, `<tabVisibility>`, `<type>`, `<mobileReady>`, `<urlFrameHeight>`, `<urlType>`, `<urlRedirect>`, `<encodingKey>`, `<height>`, `<auraComponent>`
 
 Also forbidden:
@@ -57,7 +57,7 @@ Also forbidden:
 - Empty elements like `<page></page>` or `<description></description>`
 - Any element not in the allowlist table above
 
-## 🔧 Tab Types
+## Tab Types
 
 ### Object Tabs
 - **Purpose**: Navigate to custom or standard objects
@@ -123,7 +123,7 @@ Also forbidden:
 </CustomTab>
 ```
 
-## 🎨 Tab Configuration
+## Tab Configuration
 
 ### Tab Style
 - **Default**: Use standard tab styling
@@ -133,17 +133,17 @@ Also forbidden:
 - **Default**: Visible to all users with access
 - **Custom**: Can be configured for specific user profiles
 
-## 📱 Supported Applications
+## Supported Applications
 - **Standard Apps**: Available in standard Salesforce applications
 - **Custom Apps**: Can be included in custom applications
 - **Community Apps**: Available in community applications
 
-## 🔗 Integration Points
+## Integration Points
 - **Object Relationships**: Links to related object records
 - **Web Content**: External website integration
 - **Visualforce Pages**: Custom page functionality
 - **Lightning Components**: Modern component integration
-## ✅ Best Practices
+## Best Practices
 - Use clear, descriptive tab labels
 - Choose appropriate tab types for functionality
 - **Select a unique, contextually relevant motif for each tab** — do not default every tab to the same icon

package/skills/platform-data-manage/references/orchestration.md

@@ -27,7 +27,7 @@ This document details how platform-data-manage fits into the multi-skill workflo
 
 ---
 
-## ⚠️ Why platform-data-manage Goes LAST
+## Why platform-data-manage Goes LAST
 
 **platform-data-manage operates on REMOTE org data.** Objects/fields must be deployed before platform-data-manage can:
 - Insert records

package/skills/platform-list-view-generate/SKILL.md

@@ -17,14 +17,14 @@ Use this skill when you need to:
 
 # Salesforce List View Metadata Knowledge
 
-## 📋 Overview
+## Overview
 Salesforce List Views define filtered, column-based record listings on an object's tab.
 
-## 🎯 Purpose
+## Purpose
 - Provide curated, role- or task-specific subsets of records
 - Standardize commonly used filters and visible fields across teams
 
-## 🔧 Configuration
+## Configuration
 
 Unless specifically requested to be generated inline, List Views are stored at:
 - force-app/main/default/objects/<ObjectName>/listViews/<fullName>.listView-meta.xml

package/skills/platform-metadata-api-context-get/README.md

@@ -49,7 +49,7 @@ This skill is designed for use with Claude Code. To use it:
 
 - **SKILL.md**: Complete skill documentation with usage guidelines
 - **references/metadata_index_table.md**: Index of all metadata types
-- **data/metadata_api/**: JSON files for each metadata type
+- **assets/metadata_api/**: JSON files for each metadata type
 
 ## Token Optimization
 

package/skills/platform-metadata-api-context-get/SKILL.md

@@ -28,11 +28,11 @@ The Salesforce Metadata API allows you to retrieve, deploy, create, update, or d
 
 ## How to Use This Skill
 
-### ⚡ CRITICAL: Section-Specific Consumption
+### CRITICAL: Section-Specific Consumption
 
 **ALWAYS consume only the specific sections you need from JSON files, NOT entire files.**
 
-**CRITICAL: For `data/metadata_api/*.json` files, always use `jq` or programmatic JSON parsing to extract only the specific sections you need.** Do not load these files whole via `Read`, `cat`, `read_file`, or any other tool that injects the complete file — they contain verbose WSDL segments and other sections that waste 60-80% of tokens. (Loading small files like this SKILL.md or the index table with `Read` is fine; the rule applies specifically to the large metadata-type JSON files.)
+**CRITICAL: For `assets/metadata_api/*.json` files, always use `jq` or programmatic JSON parsing to extract only the specific sections you need.** Do not load these files whole via `Read`, `cat`, `read_file`, or any other tool that injects the complete file — they contain verbose WSDL segments and other sections that waste 60-80% of tokens. (Loading small files like this SKILL.md or the index table with `Read` is fine; the rule applies specifically to the large metadata-type JSON files.)
 
 Each JSON file contains multiple sections (fields, description, wsdl_segment, etc.). Most use cases only require 1-2 sections:
 
@@ -62,7 +62,7 @@ To get information about a specific metadata type:
 
 ## JSON File Structure
 
-Each metadata type is stored as a JSON file in `data/metadata_api/` with the following structure:
+Each metadata type is stored as a JSON file in `assets/metadata_api/` with the following structure:
 
 ```json
 {
@@ -142,13 +142,13 @@ See [`examples/README.md`](examples/README.md) for complete documentation and us
 
 **❌ NEVER use the `read_file` tool on these JSON files**:
 ```text
-read_file data/metadata_api/CustomObject.json  # Loads entire file into context!
-read_file data/metadata_api/Flow.json          # Wastes 60-80% tokens!
+read_file assets/metadata_api/CustomObject.json  # Loads entire file into context!
+read_file assets/metadata_api/Flow.json          # Wastes 60-80% tokens!
 ```
 
 **❌ NEVER load all files**:
 ```text
-read_file data/metadata_api/*.json  # This loads ~15MB of data!
+read_file assets/metadata_api/*.json  # This loads ~15MB of data!
 ```
 
 **Token Impact**:
@@ -194,7 +194,7 @@ Use one of these methods:
 - **Index search**: Check `references/metadata_index_table.md` for related types
 - **Common types**: See the "Quick Reference: Common Metadata Types" section below
 
-### Step 3: Load Selectively (Section-Specific) ⚡
+### Step 3: Load Selectively (Section-Specific)
 
 **Decision Tree for Section Loading**:
 
@@ -235,7 +235,7 @@ Use the loaded information to:
 All metadata type JSON files are located in:
 
 ```text
-data/metadata_api/
+assets/metadata_api/
 ├── CustomObject.json
 ├── Flow.json
 ├── ApexClass.json
@@ -247,8 +247,8 @@ data/metadata_api/
 ### Path Resolution
 
 When using this skill, files are referenced as:
-- Absolute: `data/metadata_api/CustomObject.json`
-- Relative to skill root: `./data/metadata_api/CustomObject.json`
+- Absolute: `assets/metadata_api/CustomObject.json`
+- Relative to skill root: `./assets/metadata_api/CustomObject.json`
 
 The skill will automatically resolve paths based on the working directory.
 
@@ -409,11 +409,11 @@ When the `fields` section gives a complex type name like `ProfileObjectPermissio
 
 ```bash
 # 1. Get the field type name from the fields section
-jq '.fields.objectPermissions' data/metadata_api/Profile.json
+jq '.fields.objectPermissions' assets/metadata_api/Profile.json
 # → {"type": "ProfileObjectPermissions[]", ...}
 
 # 2. Pull just the matching complexType from wsdl_segment using grep -A
-jq -r '.wsdl_segment' data/metadata_api/Profile.json   | grep -A 30 'complexType name="ProfileObjectPermissions"'
+jq -r '.wsdl_segment' assets/metadata_api/Profile.json   | grep -A 30 'complexType name="ProfileObjectPermissions"'
 ```
 
 The `grep -A N` window keeps token cost ~150 tokens instead of loading the whole `wsdl_segment` (which can be 5K+ tokens on large types). Use this pattern any time `fields` returns a `Foo[]` type and you need Foo's sub-fields.

package/skills/platform-metadata-api-context-get/examples/README.md

@@ -2,7 +2,7 @@
 
 This directory contains working code examples demonstrating how to programmatically load only specific sections from metadata JSON files.
 
-## ⚠️ Critical Warning
+## Critical Warning
 
 **NEVER use built-in tools like Read, cat, or any other tool that loads entire JSON files into context!**
 
@@ -27,7 +27,7 @@ python3 examples/python_section_loading.py
 **Key Pattern**:
 ```python
 import json
-with open('data/metadata_api/CustomObject.json') as f:
+with open('assets/metadata_api/CustomObject.json') as f:
     data = json.load(f)
     fields_only = data.get('fields', {})  # Only extract 'fields'
 ```
@@ -49,7 +49,7 @@ node examples/javascript_section_loading.js
 **Key Pattern**:
 ```javascript
 const fs = require('fs');
-const data = JSON.parse(fs.readFileSync('data/metadata_api/CustomObject.json', 'utf-8'));
+const data = JSON.parse(fs.readFileSync('assets/metadata_api/CustomObject.json', 'utf-8'));
 const fieldsOnly = data.fields || {};  // Only extract 'fields'
 ```
 
@@ -82,7 +82,7 @@ chmod +x examples/bash_section_loading.sh
 **Key Pattern**:
 ```bash
 # Extract only the 'fields' section
-jq '.fields' data/metadata_api/CustomObject.json
+jq '.fields' assets/metadata_api/CustomObject.json
 ```
 
 ## Token Savings
@@ -130,23 +130,23 @@ Choose based on your need:
 
 ## Anti-Patterns (What NOT to Do)
 
-### ❌ Wrong: Using Read Tool
+### Wrong: Using Read Tool
 ```bash
 # This loads the ENTIRE file into context (2,000 tokens)
-Read data/metadata_api/CustomObject.json
+Read assets/metadata_api/CustomObject.json
 ```
 
-### ❌ Wrong: Using cat/type
+### Wrong: Using cat/type
 ```bash
 # This loads the ENTIRE file into context (2,000 tokens)
-cat data/metadata_api/CustomObject.json
-type data/metadata_api/CustomObject.json
+cat assets/metadata_api/CustomObject.json
+type assets/metadata_api/CustomObject.json
 ```
 
-### ✅ Correct: Programmatic Section Extraction
+### Correct: Programmatic Section Extraction
 ```bash
 # This loads only the 'fields' section (200 tokens)
-jq '.fields' data/metadata_api/CustomObject.json
+jq '.fields' assets/metadata_api/CustomObject.json
 ```
 
 ## Adapting to Other Languages

package/skills/platform-metadata-api-context-get/examples/bash_section_loading.sh

@@ -17,7 +17,7 @@
 # Ensure jq is available before doing anything else
 command -v jq >/dev/null 2>&1 || { echo "Error: jq is required but not installed." >&2; exit 1; }
 
-METADATA_DIR="data/metadata_api"
+METADATA_DIR="assets/metadata_api"
 
 
 # Example 1: Load ONLY the 'fields' section from CustomObject.json
@@ -115,10 +115,10 @@ extract_specific_fields() {
 # This is what NOT to do - it loads the entire file into context:
 #
 # Read tool approach (WRONG):
-# Read data/metadata_api/CustomObject.json  # Loads ALL sections!
+# Read assets/metadata_api/CustomObject.json  # Loads ALL sections!
 #
 # cat approach (WRONG):
-# cat data/metadata_api/CustomObject.json  # Loads entire file!
+# cat assets/metadata_api/CustomObject.json  # Loads entire file!
 #
 # This injects the entire file (including massive WSDL segments)
 # into your context, wasting 60-80% of tokens.

package/skills/platform-metadata-api-context-get/examples/javascript_section_loading.js

@@ -32,7 +32,7 @@ function loadMetadataJson(metadataFile) {
  * Token savings: ~70-80% compared to loading entire file
  */
 function loadSingleSectionExample() {
-    const metadataFile = path.join('data', 'metadata_api', 'CustomObject.json');
+    const metadataFile = path.join('assets', 'metadata_api', 'CustomObject.json');
 
     // Read and parse the JSON file
     const data = loadMetadataJson(metadataFile);
@@ -52,7 +52,7 @@ function loadSingleSectionExample() {
  * Token savings: ~60-75% compared to loading entire file
  */
 function loadMultipleSectionsExample() {
-    const metadataFile = path.join('data', 'metadata_api', 'Flow.json');
+    const metadataFile = path.join('assets', 'metadata_api', 'Flow.json');
 
     const data = loadMetadataJson(metadataFile);
 
@@ -72,7 +72,7 @@ function loadMultipleSectionsExample() {
  * Best practice: Always check what sections are available
  */
 function loadWithSectionCheck() {
-    const metadataFile = path.join('data', 'metadata_api', 'Profile.json');
+    const metadataFile = path.join('assets', 'metadata_api', 'Profile.json');
 
     const data = loadMetadataJson(metadataFile);
 
@@ -102,7 +102,7 @@ function loadWithSectionCheck() {
  * Example 4: Async/Promise version (modern Node.js)
  */
 async function loadSingleSectionAsync() {
-    const metadataFile = path.join('data', 'metadata_api', 'ApexClass.json');
+    const metadataFile = path.join('assets', 'metadata_api', 'ApexClass.json');
 
     // Use async file operations
     const fileContent = await fs.promises.readFile(metadataFile, 'utf-8');
@@ -127,7 +127,7 @@ async function loadSingleSectionAsync() {
  * This is what NOT to do - it loads the entire file into context:
  *
  * // Read tool approach (WRONG):
- * // Read data/metadata_api/CustomObject.json  // Loads ALL sections!
+ * // Read assets/metadata_api/CustomObject.json  // Loads ALL sections!
  *
  * // This injects the entire file (including massive WSDL segments)
  * // into your context, wasting 60-80% of tokens.

package/skills/platform-metadata-api-context-get/examples/python_section_loading.py

@@ -14,7 +14,7 @@ from pathlib import Path
 
 # Resolve the data directory relative to this file, so the examples work
 # regardless of the current working directory.
-METADATA_DIR = Path(__file__).resolve().parent.parent / 'data' / 'metadata_api'
+METADATA_DIR = Path(__file__).resolve().parent.parent / 'assets' / 'metadata_api'
 
 
 def load_single_section_example():
@@ -93,7 +93,7 @@ def wrong_approach_example():
     This is what NOT to do - it loads the entire file into context:
 
     # Read tool approach (WRONG):
-    # Read data/metadata_api/CustomObject.json  # Loads ALL sections!
+    # Read assets/metadata_api/CustomObject.json  # Loads ALL sections!
 
     # This injects the entire file (including massive WSDL segments)
     # into your context, wasting 60-80% of tokens.

package/skills/platform-metadata-api-context-get/references/usage_guide.md

@@ -95,7 +95,7 @@ Approximate token counts for different loading strategies:
 **User**: "I need to create a custom object metadata file for a Student object"
 
 **Response approach** (Token-efficient):
-1. Load ONLY the `fields` section from `data/metadata_api/CustomObject.json`
+1. Load ONLY the `fields` section from `assets/metadata_api/CustomObject.json`
 2. Review required fields: `label`, `nameField`, `deploymentStatus`, `sharingModel`
 3. If needed, also load the `declarative_metadata_sample_definition` section for XML structure example
 4. Generate XML with correct namespace
@@ -108,7 +108,7 @@ Approximate token counts for different loading strategies:
 **User**: "What fields are available in a Flow metadata type?"
 
 **Response approach** (Token-efficient):
-1. Load ONLY the `fields` section from `data/metadata_api/Flow.json`
+1. Load ONLY the `fields` section from `assets/metadata_api/Flow.json`
 2. List field names, types, and descriptions
 3. Highlight required fields and common patterns
 4. Skip `wsdl_segment`, `description`, and other sections
@@ -120,7 +120,7 @@ Approximate token counts for different loading strategies:
 **User**: "How do I add object permissions to a Profile?"
 
 **Response approach** (Token-efficient):
-1. Load ONLY the `fields` section from `data/metadata_api/Profile.json`
+1. Load ONLY the `fields` section from `assets/metadata_api/Profile.json`
 2. Find `objectPermissions` field definition within that section
 3. Show structure and required sub-fields
 4. If XML example needed, separately load `declarative_metadata_sample_definition`
@@ -132,7 +132,7 @@ Approximate token counts for different loading strategies:
 **User**: "What's the metadata file structure for an Apex class?"
 
 **Response approach** (Token-efficient):
-1. Load the `fields` and `description` sections from `data/metadata_api/ApexClass.json`
+1. Load the `fields` and `description` sections from `assets/metadata_api/ApexClass.json`
 2. Show the simple structure (apiVersion, status)
 3. Explain the relationship between `.cls` and `.cls-meta.xml` files
 4. Load `file_information` section only if directory structure details needed

package/skills/platform-metadata-retrieve/SKILL.md

@@ -12,7 +12,7 @@ Retrieves metadata from a Salesforce org to your local project using `sf project
 
 ---
 
-## ⚠️ Tool Restrictions
+## Tool Restrictions
 
 **Use ONLY the Bash tool** to execute `sf project retrieve start`. Do NOT use MCP tools — ignore them completely.
 

package/skills/platform-soql-query/references/field-coverage-rules.md

@@ -36,7 +36,7 @@ This error is particularly common in LLM-generated code because the LLM may:
 
 ### Rule: Every field accessed must be in the SELECT clause
 
-### ❌ BAD: Accessing Unqueried Fields
+### BAD: Accessing Unqueried Fields
 
 ```apex
 // Query only includes Id and Name
@@ -54,7 +54,7 @@ for (Account acc : accounts) {
 }
 ```
 
-### ✅ GOOD: Query All Accessed Fields
+### GOOD: Query All Accessed Fields
 
 ```apex
 // Query ALL fields that will be accessed
@@ -91,7 +91,7 @@ Fields can be accessed in many places—ensure coverage for all:
 
 ### Rule: Parent relationship fields require dot notation in SELECT
 
-### ❌ BAD: Missing Relationship Fields
+### BAD: Missing Relationship Fields
 
 ```apex
 // Contact query without Account relationship fields
@@ -108,7 +108,7 @@ for (Contact c : contacts) {
 }
 ```
 
-### ✅ GOOD: Include Relationship Fields
+### GOOD: Include Relationship Fields
 
 ```apex
 // Use dot notation to include parent fields
@@ -136,7 +136,7 @@ for (Contact c : contacts) {
 | Parent (lookup/master-detail) | 5 levels | `Contact.Account.Owner.Manager.Name` |
 | Child (subquery) | 1 level | `Account -> Contacts` (cannot nest subqueries) |
 
-### ❌ BAD: Assuming Relationship is Populated
+### BAD: Assuming Relationship is Populated
 
 ```apex
 List<Contact> contacts = [SELECT Id, AccountId FROM Contact];
@@ -150,7 +150,7 @@ for (Contact c : contacts) {
 }
 ```
 
-### ✅ GOOD: Query Relationship or Use Separate Query
+### GOOD: Query Relationship or Use Separate Query
 
 ```apex
 // Option 1: Include relationship field
@@ -189,7 +189,7 @@ for (Contact c : contacts) {
 
 ### Rule: Dynamic field access (using `get()`) also requires queried fields
 
-### ❌ BAD: Dynamic Access to Unqueried Field
+### BAD: Dynamic Access to Unqueried Field
 
 ```apex
 List<Account> accounts = [SELECT Id, Name FROM Account];
@@ -201,7 +201,7 @@ for (Account acc : accounts) {
 }
 ```
 
-### ✅ GOOD: Query Fields Used Dynamically
+### GOOD: Query Fields Used Dynamically
 
 ```apex
 // If you know which fields will be accessed dynamically, query them
@@ -213,7 +213,7 @@ for (Account acc : accounts) {
 }
 ```
 
-### ✅ GOOD: Build Dynamic Query
+### GOOD: Build Dynamic Query
 
 ```apex
 // For truly dynamic scenarios, build the query dynamically
@@ -232,7 +232,7 @@ List<Account> accounts = Database.query(query);
 
 ### Rule: Aggregate queries return `AggregateResult`, not sObjects
 
-### ❌ BAD: Treating Aggregate as sObject
+### BAD: Treating Aggregate as sObject
 
 ```apex
 // This returns AggregateResult, not Account
@@ -255,7 +255,7 @@ for (AggregateResult ar : results) {
 }
 ```
 
-### ✅ GOOD: Use get() for Aggregate Results
+### GOOD: Use get() for Aggregate Results
 
 ```apex
 AggregateResult[] results = [
@@ -291,7 +291,7 @@ for (AggregateResult ar : results) {
 
 ### Rule: Child relationship subqueries create nested lists
 
-### ❌ BAD: Accessing Subquery Fields Incorrectly
+### BAD: Accessing Subquery Fields Incorrectly
 
 ```apex
 // Query with contact subquery
@@ -312,7 +312,7 @@ for (Account acc : accounts) {
 }
 ```
 
-### ✅ GOOD: Proper Subquery Field Access
+### GOOD: Proper Subquery Field Access
 
 ```apex
 // Query all needed fields in subquery

package/skills/platform-validation-rule-generate/SKILL.md

@@ -18,15 +18,15 @@ Use this skill when you need to:
 
 # ValidationRule Metadata Specification
 
-### 📋 Overview
+### Overview
 Validation Rules are declarative metadata components used to enforce data quality and business logic in Salesforce. They evaluate a formula expression when a record is saved and prevent the save operation if the expression returns TRUE.
 
-### 🎯 Purpose
+### Purpose
 -Enforce business rules at the data layer
 -Prevent invalid or incomplete records from being saved
 -Display meaningful error messages to guide users
 
-### ⚙️ Required Properties
+### Required Properties
 
 #### Core Validation Rule Properties