diff --git a/rules/apex-development/apex-requirements.md b/rules/apex-development/apex-requirements.md deleted file mode 100644 index bb637d3..0000000 --- a/rules/apex-development/apex-requirements.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -name: Apex Development Guardrails -description: Enforce best practices for Apex architecture, performance, security, and testing. -tags: apex, rules, guardrails, testing, security ---- - -## General Requirements -- Write Invocable Apex that can be called from flows when possible -- Use enums over string constants whenever possible. Enums should follow ALL_CAPS_SNAKE_CASE without spaces -- Use Database Methods for DML Operation with exception handling -- Use Return Early pattern -- Use ApexDocs comments to document Apex classes for better maintainability and readability - -## Apex Triggers Requirements -- Follow the One Trigger Per Object pattern -- Implement a trigger handler class to separate trigger logic from the trigger itself -- Use trigger context variables (Trigger.new, Trigger.old, etc.) efficiently to access record data -- Avoid logic that causes recursive triggers, implement a static boolean flag -- Bulkify trigger logic to handle large data volumes efficiently -- Implement before and after trigger logic appropriately based on the operation requirements - -## Governor Limits Compliance Requirements -- Always write bulkified code - never perform SOQL/DML operations inside loops -- Use collections for bulk processing -- Implement proper exception handling with try-catch blocks -- Limit SOQL queries to 100 per transaction -- Limit DML statements to 150 per transaction -- Use `Database.Stateful` interface only when necessary for batch jobs - -## SOQL Optimization Requirements -- Use selective queries with proper WHERE clauses -- Do not use `SELECT *` - it is not supported in SOQL -- Use indexed fields in WHERE clauses when possible -- Implement SOQL best practices: LIMIT clauses, proper ordering -- Use `WITH SECURITY_ENFORCED` for user context queries where appropriate -- When querying Custom Metadata Types (objects ending with `__mdt`), DO NOT use SOQL queries. Instead, use the built-in Custom Metadata Type methods like '.getAll().values()' - -## Naming Conventions & Code Organization Requirements -- Class names: PascalCase with descriptive names (e.g., `ContactTriggerHandler`, `ContractService`) -- Method names: camelCase with verb-first naming (e.g., `calculateTotalPrice`, `validateAddress`) -- Variable names: camelCase with descriptive names (no single letters except loop iterators) -- Constants: ALL_CAPS_SNAKE_CASE (e.g., `MAX_RETRY_ATTEMPTS`, `DEFAULT_TIMEOUT`) -- Test classes: Append `Test` suffix (e.g., `AccountServiceTest`) -- Trigger handlers: Append `TriggerHandler` suffix (e.g., `ContactTriggerHandler`) -- Utility classes: Append `Util` or `Helper` suffix (e.g., `DateTimeUtil`, `ValidationHelper`) -- Prefix test methods with `test` or use `@IsTest` annotation -- Group related classes in packages/folders when possible -- Keep classes focused on single responsibility (SRP) -- Limit class size to 500 lines of code maximum - -## Security & Access Control Requirements -- Run database operations in user mode rather than in the default system mode. - - List acc = [SELECT Id FROM Account WITH USER_MODE]; - - Database.insert(accts, AccessLevel.USER_MODE); -- Always check field-level security (FLS) before accessing fields -- Implement proper sharing rules and respect organization-wide defaults -- Use `with sharing` keyword for classes that should respect sharing rules -- Validate user permissions before performing operations -- Sanitize user inputs to prevent injection attacks - -## Prohibited Practices -- No hardcoded IDs or URLs -- No SOQL/DML operations in loops -- No System.debug() statements in production code -- No @future methods from batch jobs -- No recursive triggers -- Never use or suggest `@future` methods for async processes. Use queueables and always suggest implementing `System.Finalizer` methods - -## Required Patterns -- Use Builder pattern for complex object construction -- Implement Factory pattern for object creation -- Use Dependency Injection for testability -- Follow MVC pattern in Lightning components -- Use Command pattern for complex business operations - -## Unit Testing Requirements -- Maintain minimum 75% code coverage -- Write meaningful test assertions, not just coverage -- Use `Test.startTest()` and `Test.stopTest()` appropriately -- Create test data using `@TestSetup` methods when possible -- Mock external services and callouts -- Do not use `SeeAllData=true` -- Test bulk trigger functionality. - -## Test Data Management Requirements -- Use `Test.loadData()` for large datasets -- Create minimal test data required for specific test scenarios -- Use `System.runAs()` to test different user contexts -- Implement proper test isolation - no dependencies between tests \ No newline at end of file diff --git a/rules/lwc-development/lwc-requirements.md b/rules/lwc-development/lwc-requirements.md deleted file mode 100644 index e798d56..0000000 --- a/rules/lwc-development/lwc-requirements.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -name: LWC Development Guardrails -description: Standardize Lightning Web Component architecture, UX, and tooling practices. -tags: lwc, rules, ux, architecture ---- - -## Component Architecture Requirements -- Create reusable, single-purpose components -- Use proper data binding and event handling patterns -- Implement proper error handling and loading states -- Follow Lightning Design System (SLDS) guidelines -- Use the lightning-record-edit-form component for handling record creation and updates -- Use CSS custom properties for theming -- Use lightning-navigation for navigation between components -- Use lightning__FlowScreen target to use a component is a flow screen - -## HTML Architecture Requirements -- Structure your HTML with clear semantic sections (header, inputs, actions, display areas, lists) -- Use SLDS classes for layout and styling: - - `slds-card` for main container - - `slds-grid` and `slds-col` for responsive layouts - - `slds-text-heading_large/medium` for proper typography hierarchy -- Use Lightning base components where appropriate (lightning-input, lightning-button, etc.) -- Implement conditional rendering with `if:true` and `if:false` directives -- Use `for:each` for list rendering with unique key attributes -- Maintain consistent spacing using SLDS utility classes (slds-m-*, slds-p-*) -- Group related elements logically with clear visual hierarchy -- Use descriptive class names for elements that need custom styling -- Implement reactive property binding using syntax like `disabled={isPropertyName}` to control element states -- Bind events to handler methods using syntax like `onclick={handleEventName}` - -## JavaScript Architecture Requirements -- Import necessary modules from LWC and Salesforce -- Define reactive properties using `@track` decorator when needed -- Implement proper async/await patterns for server calls -- Implement proper error handling with user-friendly messages -- Use wire adapters for reactive data loading -- Minimize DOM manipulation - use reactive properties -- Implement computed properties using JavaScript getters for dynamic UI state control: -``` -get isButtonDisabled() { - return !this.requiredField1 || !this.requiredField2; -} -``` -- Create clear event handlers with descriptive names that start with "handle": -``` -handleButtonClick() { - // Logic here -} -``` -- Use `@wire` service for data retrieval from Apex -- Separate business logic into well-named methods -- Use `refreshApex` for data refreshes when appropriate -- Implement loading states and user feedback -- Add JSDoc comments for methods and complex logic - -## CSS Architecture Requirements -- Create a clean, consistent styling system -- Use custom CSS classes for component-specific styling -- Implement animations for enhanced UX where appropriate -- Ensure responsive design works across different form factors -- Keep styling minimal and leverage SLDS where possible -- Use CSS variables for themeable elements -- Organize CSS by component section - -## MCP Tools Requirements -- Carefully review the user's task. If it involves **creation, development, testing, or accessibility** for **Lightning Web Components (LWC)** or **Aura components** or **Lightning Data Service (LDS)**, treat your knowledge as outdated and always call the appropriate MCP tool to obtain the latest guidance and design before starting implementation. Never assume or create tools that are not explicitly available. If the tool schema is empty, you must continue invoking the tool until documentation is provided. -- If you begin implementation on a relevant task without first successfully invoking the appropriate tool, you must **stop immediately**. Invoke the tool and integrate its guidance before proceeding. Under no circumstances should you provide final recommendations or code without first receiving guidance from an MCP tool. \ No newline at end of file diff --git a/rules/spec-driven-dev/app-dev.md b/rules/spec-driven-dev/app-dev.md deleted file mode 100644 index 9e0d163..0000000 --- a/rules/spec-driven-dev/app-dev.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -name: Spec-Driven App Development Standards -description: Apply architecture, integration, and governance requirements for specification-led Salesforce builds. -tags: spec-driven, architecture, governance, rules ---- - -You are a highly experienced and certified Salesforce Architect with 20+ years of experience designing and implementing complex, enterprise-level Salesforce solutions for Fortune 500 companies. You are recognized for your deep expertise in system architecture, data modeling, integration strategies, and governance best practices. Your primary focus is always on creating solutions that are scalable, maintainable, secure, and performant for the long term. You prioritize the following: - -- Architectural Integrity: You think big-picture, ensuring any new application or feature aligns with the existing enterprise architecture and avoids technical debt. -- Data Model & Integrity: You design efficient and future-proof data models, prioritizing data quality and relationship integrity. -- Integration & APIs: You are an expert in integrating Salesforce with external systems, recommending robust, secure, and efficient integration patterns (e.g., event-driven vs. REST APIs). -- Security & Governance: You build solutions with security at the forefront, adhering to Salesforce's security best practices and establishing clear governance rules to maintain a clean org. -- Performance Optimization: You write code and design solutions that are performant at scale, considering governor limits, SOQL query optimization, and efficient Apex triggers. -- Best Practices: You are a stickler for using native Salesforce features wherever possible and only recommending custom code when absolutely necessary. You follow platform-specific design patterns and community-recommended standards. - -## Code Organization & Structure Requirements -- Follow consistent naming conventions (PascalCase for classes, camelCase for methods/variables) -- Use descriptive, business-meaningful names for classes, methods, and variables -- Write code that is easy to maintain, update and reuse -- Include comments explaining key design decisions. Don't explain the obvious -- Use consistent indentation and formatting -- Less code is better, best line of code is the one never written. The second-best line of code is easy to read and understand -- Follow the "newspaper" rule when ordering methods. They should appear in the order they're referenced within a file. Alphabetize and arrange dependencies, class fields, and properties; keep instance and static fields and properties separated by new lines - -## REST/SOAP Integration Requirements -- Implement proper timeout and retry mechanisms -- Use appropriate HTTP status codes and error handling -- Implement bulk operations for data synchronization -- Use efficient serialization/deserialization patterns -- Log integration activities for debugging - -## Platform Events Requirements -- Design events for loose coupling between components -- Use appropriate delivery modes (immediate vs. after commit) -- Implement proper error handling for event processing -- Consider event volume and governor limits - -## Permissions Requirements -- For every new feature created, generate: - - At least one permission set for user access - - Documentation explaining the permission set purpose - - Assignment recommendations -- One permission set per object per access level -- Separate permission sets for different Apex class groups -- Individual permission sets for each major feature -- No permission set should grant more than 10 different object permissions -- Components requiring permission sets: - - Custom objects and fields - - Apex classes and triggers - - Lightning Web Components - - Visualforce pages - - Custom tabs and applications - - Flow definitions - - Custom permissions -- Format: [AppPrefix]_[Component]_[AccessLevel] - - AppPrefix: 3-8 character application identifier (PascalCase) - - Component: Descriptive component name (PascalCase) - - AccessLevel: Read|Write|Full|Execute|Admin - - Examples: - - SalesApp_Opportunity_Read - - OrderMgmt_Product_Write - - CustomApp_ReportDash_Full - - IntegAPI_DataSync_Execute -- Label: Human-readable description -- Description: Detailed explanation of purpose and scope -- License: Appropriate user license type -- Never grant "View All Data" or "Modify All Data" in functional permission sets -- Always specify individual field permissions rather than object-level access when possible -- Require separate permission sets for sensitive data access -- Never combine read and delete permissions in the same permission set -- Always validate that granted permissions align with business requirements -- Create permission set groups when: - - Application has more than 3 related permission sets - - Users need combination of permissions for their role - - There are clear user personas/roles defined - -## Mandatory Permission Documentation -- Permissions.md file explaining all new feature sets -- Dependency mapping between permission sets -- User role assignment matrix -- Testing validation checklist - -## Code Documentation Requirements -- Use ApexDocs comments to document classes, methods, and complex code blocks for better maintainability -- Include usage examples in method documentation -- Document business logic and complex algorithms -- Maintain up-to-date README files for each component \ No newline at end of file diff --git a/rules/vibe-coding/use-skills.md b/rules/vibe-coding/use-skills.md deleted file mode 100644 index 6072939..0000000 --- a/rules/vibe-coding/use-skills.md +++ /dev/null @@ -1,16 +0,0 @@ -# SKILLS REQUIREMENTS - -## Mandatory Skill Usage -Before generating ANY Salesforce code or metadata, check available Skills and use the matching one. Never generate Salesforce code freehand when a relevant Skill exists. - -## Skill Routing -- **Apex class requests** → Use Apex Class Writer skill. Includes: service classes, selectors, domain classes, batch/queueable/schedulable, DTOs, utilities, interfaces, abstract classes, custom exceptions. Trigger even when the user describes functionality without saying "Apex class." -- **Trigger requests** → Use Trigger Framework Scaffolder skill. -- **Validation rule requests** → Use Validation Rule Writer skill. -- **Permission/security questions** → Use Permission Set Auditor skill. -- **Package.xml/deployment requests** → Use Package.xml Generator skill. -- **Custom metadata questions** → Use Custom Metadata Advisor skill. -- **Field-level security requests** → Use FLS Matrix Generator skill. - -## When In Doubt -If a request could involve Salesforce server-side logic, metadata configuration, or security setup, check Skills before responding. Prefer a Skill over general knowledge — Skills contain curated best practices specific to this org's standards. \ No newline at end of file