@salesforce/afv-skills 1.1.0 → 1.3.0

package/skills/deployment-readiness-check/references/rollback_procedures.md

@@ -1,308 +0,0 @@
-# Rollback Procedures
-
-This guide provides step-by-step instructions for rolling back a Salesforce deployment if issues are discovered after release.
-
-## When to Rollback
-
-Execute a rollback when:
-- **Critical functionality is broken** and cannot be hotfixed quickly
-- **Data integrity issues** are discovered
-- **Performance degradation** exceeds 50% of baseline
-- **Security vulnerabilities** are introduced
-- **Stakeholder approval** to rollback is obtained
-
-Do NOT rollback for:
-- Minor UI issues that don't impact functionality
-- Issues that can be hotfixed in < 2 hours
-- Edge cases affecting < 5% of users
-- Cosmetic problems
-
-## Pre-Rollback Checklist
-
-Before initiating rollback:
-
-- [ ] Confirm the issue severity justifies rollback
-- [ ] Obtain stakeholder approval
-- [ ] Notify all users of upcoming rollback
-- [ ] Backup current production state (post-deployment)
-- [ ] Verify pre-deployment backup is available
-- [ ] Review rollback plan with team
-- [ ] Prepare communication for completion
-
-## Rollback Methods
-
-### Method 1: Redeploy Previous Version (Recommended)
-
-**Best for**: Metadata-only deployments with no data changes.
-
-**Steps**:
-
-1. **Retrieve pre-deployment state from version control**:
-   ```bash
-   git checkout pre-deployment-YYYYMMDD
-   ```
-
-2. **Validate rollback deployment**:
-   ```bash
-   sf project deploy validate \
-     --manifest manifest/package.xml \
-     --test-level RunLocalTests \
-     --target-org production
-   ```
-
-3. **Deploy previous version**:
-   ```bash
-   sf project deploy start \
-     --manifest manifest/package.xml \
-     --test-level RunLocalTests \
-     --target-org production
-   ```
-
-4. **Verify rollback**:
-   - Test critical user flows
-   - Check for errors in debug logs
-   - Confirm with stakeholders
-
-**Timeline**: 30-60 minutes
-
-### Method 2: Selective Component Rollback
-
-**Best for**: When only specific components are problematic.
-
-**Steps**:
-
-1. **Identify problematic components**:
-   - Review error logs
-   - Isolate failing functionality
-   - List components to rollback
-
-2. **Create targeted package.xml**:
-   ```xml
-   <?xml version="1.0" encoding="UTF-8"?>
-   <Package xmlns="http://soap.sforce.com/2006/04/metadata">
-       <types>
-           <members>ProblematicClass</members>
-           <name>ApexClass</name>
-       </types>
-       <version>59.0</version>
-   </Package>
-   ```
-
-3. **Retrieve previous version of components**:
-   ```bash
-   git show pre-deployment-YYYYMMDD:force-app/main/default/classes/ProblematicClass.cls > temp/ProblematicClass.cls
-   ```
-
-4. **Deploy only those components**:
-   ```bash
-   sf project deploy start \
-     --manifest rollback-package.xml \
-     --target-org production
-   ```
-
-**Timeline**: 15-30 minutes
-
-### Method 3: Destructive Changes
-
-**Best for**: When new components must be removed entirely.
-
-**Steps**:
-
-1. **Create destructiveChanges.xml**:
-   ```xml
-   <?xml version="1.0" encoding="UTF-8"?>
-   <Package xmlns="http://soap.sforce.com/2006/04/metadata">
-       <types>
-           <members>NewComponentToDelete</members>
-           <name>ApexClass</name>
-       </types>
-       <version>59.0</version>
-   </Package>
-   ```
-
-2. **Create empty package.xml**:
-   ```xml
-   <?xml version="1.0" encoding="UTF-8"?>
-   <Package xmlns="http://soap.sforce.com/2006/04/metadata">
-       <version>59.0</version>
-   </Package>
-   ```
-
-3. **Deploy destructive changes**:
-   ```bash
-   sf project deploy start \
-     --manifest package.xml \
-     --pre-destructive-changes destructiveChanges.xml \
-     --test-level RunLocalTests \
-     --target-org production
-   ```
-
-4. **Verify deletion**:
-   ```bash
-   sf org list metadata --metadata-type ApexClass --target-org production
-   ```
-
-**Timeline**: 20-40 minutes
-
-## Data Rollback Considerations
-
-If the deployment included data changes:
-
-### Option A: Restore from Backup
-
-1. **Locate pre-deployment data backup**:
-   - Data Export Service snapshot
-   - Backup tool (OwnBackup, Spanning, etc.)
-   - Manual CSV exports
-
-2. **Restore data**:
-   ```bash
-   sf data import tree --plan data-backup/data-plan.json --target-org production
-   ```
-
-3. **Validate data integrity**:
-   - Run data quality checks
-   - Verify record counts
-   - Check relationships
-
-**Timeline**: 1-4 hours (depending on data volume)
-
-### Option B: Reverse Data Changes (Scripted)
-
-1. **Identify affected records**:
-   ```bash
-   sf data query --query "SELECT Id FROM Account WHERE LastModifiedDate >= YESTERDAY"
-   ```
-
-2. **Apply reverse operations**:
-   - Create Apex script to reverse changes
-   - Test in sandbox first
-   - Execute in production
-
-**Timeline**: 2-6 hours
-
-## Post-Rollback Steps
-
-After rollback is complete:
-
-1. **Verify Functionality**:
-   - [ ] Execute smoke tests
-   - [ ] Confirm critical workflows work
-   - [ ] Check automation (triggers, flows) operates correctly
-   - [ ] Review debug logs for errors
-
-2. **Communication**:
-   - [ ] Notify users rollback is complete
-   - [ ] Send post-mortem summary to stakeholders
-   - [ ] Update status page / internal wiki
-
-3. **Root Cause Analysis**:
-   - [ ] Document what went wrong
-   - [ ] Identify why issues weren't caught pre-deployment
-   - [ ] Update deployment checklist to prevent recurrence
-   - [ ] Schedule retrospective with team
-
-4. **Next Steps**:
-   - [ ] Fix issues in development environment
-   - [ ] Add test cases to catch similar issues
-   - [ ] Re-validate deployment in sandbox
-   - [ ] Schedule new deployment with fixes
-
-## Emergency Contacts
-
-**Production Issues**:
-- On-call DevOps: [contact info]
-- Salesforce Support: [premier support phone]
-- Release Manager: [contact info]
-
-**Stakeholder Notifications**:
-- Product Owner: [contact info]
-- Business Analyst: [contact info]
-- Executive Sponsor: [contact info]
-
-## Rollback Decision Matrix
-
-| Severity | Impact | Rollback? | Timeline |
-|----------|--------|-----------|----------|
-| **Critical** | >50% users affected, core functionality broken | Yes | Immediate (< 1 hour) |
-| **High** | 10-50% users affected, workaround exists | Consider | Within 2-4 hours |
-| **Medium** | <10% users affected, non-critical features | No, hotfix instead | Plan fix for next release |
-| **Low** | Edge case, cosmetic issues | No | Address in backlog |
-
-## Lessons Learned Template
-
-After each rollback, document lessons learned:
-
-```markdown
-# Rollback Post-Mortem: [Date]
-
-## Deployment Summary
-- Deployment date/time: [timestamp]
-- Components deployed: [list]
-- Rollback date/time: [timestamp]
-- Rollback method used: [method]
-
-## Issue Description
-[Describe what went wrong]
-
-## Root Cause
-[Why did the issue occur?]
-
-## Detection
-- How was the issue discovered?
-- How long after deployment?
-- Who reported it?
-
-## Impact
-- Number of users affected: [count]
-- Business processes impacted: [list]
-- Duration of impact: [timespan]
-
-## Resolution
-- Rollback timeline: [start - end]
-- Additional fixes required: [list]
-
-## Prevention
-- What tests would have caught this?
-- Process improvements needed:
-- Deployment checklist updates:
-
-## Action Items
-- [ ] [Action item with owner]
-- [ ] [Action item with owner]
-```
-
-## Best Practices
-
-1. **Practice rollbacks in sandbox** - Don't wait for an emergency to learn the process
-2. **Maintain detailed backups** - Automate metadata and data backups before every deployment
-3. **Use version control tags** - Tag every production deployment for easy identification
-4. **Document everything** - Keep a deployment log with timestamps and decisions
-5. **Communicate proactively** - Keep stakeholders informed throughout the process
-6. **Set time limits** - If rollback takes >2 hours, consider alternative approaches
-7. **Test the rollback** - Validate in sandbox that the rollback process works
-
-## Rollback Scripts Repository
-
-Keep commonly-used rollback scripts in version control:
-
-```
-scripts/rollback/
-├── rollback-apex.sh          # Rollback Apex classes
-├── rollback-lwc.sh           # Rollback Lightning Web Components
-├── rollback-flows.sh         # Rollback flows and processes
-├── rollback-data.sh          # Restore data from backup
-└── verify-rollback.sh        # Post-rollback verification
-```
-
-## Testing Rollback Procedures
-
-**Quarterly rollback drill**:
-1. Deploy a test change to sandbox
-2. Wait 1 hour
-3. Execute full rollback procedure
-4. Time the process
-5. Document any issues
-6. Update procedures as needed
-
-This ensures the team is prepared when a real rollback is needed.

package/skills/deployment-readiness-check/scripts/check_metadata.sh

@@ -1,207 +0,0 @@
-#!/bin/bash
-# Metadata validation script for Salesforce deployments
-# Checks for common issues before deployment
-
-set -e
-
-# Colors for output
-RED='\033[0;31m'
-YELLOW='\033[1;33m'
-GREEN='\033[0;32m'
-NC='\033[0m' # No Color
-
-ERRORS=0
-WARNINGS=0
-
-echo "=========================================="
-echo "Salesforce Metadata Validation"
-echo "=========================================="
-echo ""
-
-# Check if we're in an SFDX project
-if [ ! -f "sfdx-project.json" ]; then
-    echo -e "${RED}ERROR: Not in an SFDX project directory${NC}"
-    echo "Please run this script from your project root"
-    exit 1
-fi
-
-echo "✓ Found SFDX project"
-echo ""
-
-# 1. Check XML format
-echo "Checking XML format..."
-XML_ERRORS=0
-
-find force-app -name "*.xml" -o -name "*.object" -o -name "*.layout" | while read file; do
-    if ! xmllint --noout "$file" 2>/dev/null; then
-        echo -e "${RED}✗ Invalid XML: $file${NC}"
-        XML_ERRORS=$((XML_ERRORS + 1))
-    fi
-done
-
-if [ $XML_ERRORS -eq 0 ]; then
-    echo -e "${GREEN}✓ All XML files are well-formed${NC}"
-else
-    echo -e "${RED}✗ Found $XML_ERRORS XML errors${NC}"
-    ERRORS=$((ERRORS + XML_ERRORS))
-fi
-echo ""
-
-# 2. Check API versions
-echo "Checking API versions..."
-MIN_API_VERSION=56.0
-
-find force-app -name "*.cls-meta.xml" -o -name "*.trigger-meta.xml" | while read file; do
-    VERSION=$(grep -o '<apiVersion>[0-9.]*</apiVersion>' "$file" | grep -o '[0-9.]*')
-    if [ -n "$VERSION" ] && (( $(echo "$VERSION < $MIN_API_VERSION" | bc -l) )); then
-        echo -e "${YELLOW}⚠ Old API version $VERSION in: $file${NC}"
-        WARNINGS=$((WARNINGS + 1))
-    fi
-done
-
-echo -e "${GREEN}✓ API version check complete${NC}"
-echo ""
-
-# 3. Check for deprecated features
-echo "Checking for deprecated features..."
-
-# Check for old-style custom settings
-DEPRECATED_SETTINGS=$(find force-app -name "*.object-meta.xml" -exec grep -l "customSettingsType>List" {} \; | wc -l)
-if [ $DEPRECATED_SETTINGS -gt 0 ]; then
-    echo -e "${YELLOW}⚠ Found $DEPRECATED_SETTINGS list custom settings (consider Custom Metadata Types)${NC}"
-    WARNINGS=$((WARNINGS + 1))
-fi
-
-# Check for old Aura components (should migrate to LWC)
-AURA_COMPONENTS=$(find force-app -name "*.cmp" | wc -l)
-if [ $AURA_COMPONENTS -gt 5 ]; then
-    echo -e "${YELLOW}⚠ Found $AURA_COMPONENTS Aura components (consider migrating to LWC)${NC}"
-    WARNINGS=$((WARNINGS + 1))
-fi
-
-echo -e "${GREEN}✓ Deprecation check complete${NC}"
-echo ""
-
-# 4. Check naming conventions
-echo "Checking naming conventions..."
-
-# Check for spaces in API names (not allowed)
-SPACE_ERRORS=$(find force-app -name "*.xml" -exec grep -l "fullName>.*\s.*<" {} \; | wc -l)
-if [ $SPACE_ERRORS -gt 0 ]; then
-    echo -e "${RED}✗ Found $SPACE_ERRORS files with spaces in API names${NC}"
-    ERRORS=$((ERRORS + SPACE_ERRORS))
-fi
-
-# Check for lowercase custom object names (should be PascalCase)
-LOWERCASE_OBJECTS=$(find force-app/main/default/objects -name "*.object-meta.xml" -exec basename {} \; | grep -E "^[a-z]" | wc -l)
-if [ $LOWERCASE_OBJECTS -gt 0 ]; then
-    echo -e "${YELLOW}⚠ Found $LOWERCASE_OBJECTS custom objects with lowercase names${NC}"
-    WARNINGS=$((WARNINGS + 1))
-fi
-
-echo -e "${GREEN}✓ Naming convention check complete${NC}"
-echo ""
-
-# 5. Check for hardcoded IDs or URLs
-echo "Checking for hardcoded values..."
-
-# Check for record IDs (15 or 18 character Salesforce IDs)
-HARDCODED_IDS=$(grep -r -E "'[a-zA-Z0-9]{15,18}'" force-app/main/default/classes force-app/main/default/triggers 2>/dev/null | wc -l)
-if [ $HARDCODED_IDS -gt 0 ]; then
-    echo -e "${YELLOW}⚠ Found $HARDCODED_IDS potential hardcoded record IDs in Apex${NC}"
-    echo "  Review and replace with custom settings or custom metadata"
-    WARNINGS=$((WARNINGS + 1))
-fi
-
-# Check for hardcoded URLs
-HARDCODED_URLS=$(grep -r "https://.*\.salesforce\.com" force-app/main/default/ 2>/dev/null | wc -l)
-if [ $HARDCODED_URLS -gt 0 ]; then
-    echo -e "${YELLOW}⚠ Found $HARDCODED_URLS hardcoded Salesforce URLs${NC}"
-    echo "  Consider using Named Credentials or Custom Settings"
-    WARNINGS=$((WARNINGS + 1))
-fi
-
-echo -e "${GREEN}✓ Hardcoded value check complete${NC}"
-echo ""
-
-# 6. Check meta.xml files
-echo "Checking for missing meta.xml files..."
-
-MISSING_META=0
-find force-app -name "*.cls" | while read file; do
-    if [ ! -f "${file}-meta.xml" ]; then
-        echo -e "${RED}✗ Missing meta.xml for: $file${NC}"
-        MISSING_META=$((MISSING_META + 1))
-    fi
-done
-
-if [ $MISSING_META -eq 0 ]; then
-    echo -e "${GREEN}✓ All source files have meta.xml files${NC}"
-else
-    echo -e "${RED}✗ Found $MISSING_META missing meta.xml files${NC}"
-    ERRORS=$((ERRORS + MISSING_META))
-fi
-echo ""
-
-# 7. Check for test classes
-echo "Checking test coverage..."
-
-TOTAL_CLASSES=$(find force-app -name "*.cls" | wc -l)
-TEST_CLASSES=$(find force-app -name "*Test.cls" -o -name "*_Test.cls" | wc -l)
-
-if [ $TOTAL_CLASSES -gt 0 ]; then
-    TEST_RATIO=$(echo "scale=2; $TEST_CLASSES / $TOTAL_CLASSES * 100" | bc)
-    echo "Test class ratio: $TEST_CLASSES/$TOTAL_CLASSES (${TEST_RATIO}%)"
-    
-    if (( $(echo "$TEST_RATIO < 50" | bc -l) )); then
-        echo -e "${YELLOW}⚠ Low test class coverage (${TEST_RATIO}%)${NC}"
-        echo "  Consider adding more test classes"
-        WARNINGS=$((WARNINGS + 1))
-    else
-        echo -e "${GREEN}✓ Good test class coverage (${TEST_RATIO}%)${NC}"
-    fi
-else
-    echo "No Apex classes found"
-fi
-echo ""
-
-# 8. Check package.xml
-echo "Checking package.xml..."
-
-if [ -f "manifest/package.xml" ]; then
-    echo -e "${GREEN}✓ Found package.xml${NC}"
-    
-    # Validate it's well-formed XML
-    if xmllint --noout manifest/package.xml 2>/dev/null; then
-        echo -e "${GREEN}✓ package.xml is valid XML${NC}"
-    else
-        echo -e "${RED}✗ package.xml is invalid XML${NC}"
-        ERRORS=$((ERRORS + 1))
-    fi
-else
-    echo -e "${YELLOW}⚠ No package.xml found in manifest/ directory${NC}"
-    WARNINGS=$((WARNINGS + 1))
-fi
-echo ""
-
-# Summary
-echo "=========================================="
-echo "Validation Summary"
-echo "=========================================="
-echo -e "Errors: ${RED}$ERRORS${NC}"
-echo -e "Warnings: ${YELLOW}$WARNINGS${NC}"
-echo ""
-
-if [ $ERRORS -eq 0 ] && [ $WARNINGS -eq 0 ]; then
-    echo -e "${GREEN}✓ Metadata validation passed!${NC}"
-    echo "Your metadata is ready for deployment."
-    exit 0
-elif [ $ERRORS -eq 0 ]; then
-    echo -e "${YELLOW}⚠ Validation passed with warnings${NC}"
-    echo "Review warnings before deploying."
-    exit 0
-else
-    echo -e "${RED}✗ Validation failed${NC}"
-    echo "Fix errors before deploying."
-    exit 1
-fi

package/skills/salesforce-custom-tab/SKILL.md

@@ -1,78 +0,0 @@
----
-name: salesforce-custom-tab
-description: Use this skill when users need to create or configure Salesforce Custom Tabs. Trigger when users mention tabs, navigation tabs, object tabs, web tabs, Visualforce tabs, Lightning component tabs, app page tabs, or tab configuration. Also use when users want to add navigation to custom objects, create tabs for external content, or set up Lightning page tabs. Always use this skill for any custom tab work.
----
-
-## When to Use This Skill
-
-Use this skill when you need to:
-- Create tabs for objects, web pages, or Visualforce pages
-- Add navigation tabs to applications
-- Configure tab visibility and access
-- Troubleshoot deployment errors related to custom tabs
-
-## Specification
-
-# CustomTab Metadata Specification
-
-## 📋 Overview
-Custom tabs for navigating to objects, web content, or Visualforce pages within Salesforce applications.
-
-## 🎯 Purpose
-- Provide navigation to custom objects
-- Link to external web content
-- Access Visualforce pages
-- Organize application navigation
-
-## ⚙️ Required Properties
-
-### Core Tab Properties
-- **label**: Display name of the tab
-- **fullName**: API name of the object (for object tabs)
-- **url**: Web URL (for web tabs)
-- **page**: Visualforce page name (for Visualforce tabs)
-
-## 🔧 Tab Types
-
-### Object Tabs
-- **Purpose**: Navigate to custom or standard objects
-- **Required**: `fullName` property (set to object API name)
-- **Example**: `<fullName>CustomObject__c</fullName>`
-
-### Web Tabs
-- **Purpose**: Link to external websites or web applications
-- **Required**: `url` property
-- **Example**: `<url>https://example.com</url>`
-
-### Visualforce Tabs
-- **Purpose**: Access custom Visualforce pages
-- **Required**: `page` property
-- **Example**: `<page>CustomPage</page>`
-
-## 🎨 Tab Configuration
-
-### Tab Style
-- **Default**: Use standard tab styling
-- **Custom**: Can specify custom tab styles if needed
-
-### Tab Visibility
-- **Default**: Visible to all users with access
-- **Custom**: Can be configured for specific user profiles
-
-## 📱 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
-- **Object Relationships**: Links to related object records
-- **Web Content**: External website integration
-- **Visualforce Pages**: Custom page functionality
-- **Lightning Components**: Modern component integration
-## ✅ Best Practices
-- Use clear, descriptive tab labels
-- Choose appropriate tab types for functionality
-- Consider user experience and navigation flow
-- Test tab functionality across different applications
-- Ensure proper permissions and visibility settings
-- Follow consistent naming conventions