Salesforce Component Standards
Apply Salesforce LWC, Aura, and Visualforce quality and security checks when you build or review UI on the platform.
Overview
salesforce-component-standards is an agent skill most often used in Build (also Ship review and security) that enforces Salesforce Lightning UI quality, SLDS 2, accessibility, and platform-specific security patterns.
Install
npx skills add https://github.com/github/awesome-copilot --skill salesforce-component-standardsWhat is this skill?
- Data-access decision table: @wire vs lightning-record-form vs cacheable Apex vs imperative DML
- SLDS 2 compliance and WCAG 2.1 AA accessibility requirements for every component
- Platform security: XSS prevention, CSRF enforcement, FLS/CRUD in @AuraEnabled methods
- Covers LWC, Aura, and Visualforce including view state and Jest test expectations
- Structured review checklist for building or reviewing any Salesforce UI surface
- WCAG 2.1 AA accessibility target
- SLDS 2 compliance coverage
- Structured LWC data-access pattern selection table
Adoption & trust: 636 installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are writing or reviewing Salesforce UI code and need a consistent way to pick data patterns, SLDS, accessibility, and FLS/CRUD rules without mixing in generic web stack advice.
Who is it for?
Indie builders or small teams on Salesforce building LWCs, Aura bundles, or Visualforce who want review-ready UI that passes platform security and a11y norms.
Skip if: Non-Salesforce stacks (Next.js-only SPAs, raw mobile native) or greenfield projects with no Lightning or Visualforce surfaces.
When should I use this skill?
Building or reviewing any Salesforce UI component (LWC, Aura, or Visualforce) to enforce platform-specific security and quality standards.
What do I get? / Deliverables
Your agent applies a structured Salesforce component standards pass so LWC, Aura, or Visualforce work aligns with caching, DML, security, and test expectations before you ship.
- Standards-aligned component guidance
- Review findings mapped to LWC, Aura, or Visualforce sections
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the skill’s core value is choosing correct data-access and component patterns while authoring Salesforce UI. Frontend subphase matches Lightning Web Components, Aura, and Visualforce page work rather than Apex-only backend logic.
Where it fits
Scaffold a new LWC and pick @wire getRecord versus imperative Apex before adding DML.
Run a pre-merge pass on Aura and LWC changes for SLDS 2 and Jest coverage gaps.
Verify @AuraEnabled methods enforce FLS/CRUD and XSS-safe rendering on a Visualforce page.
How it compares
Use as a Salesforce-specific checker on top of general frontend linting—not as a substitute for org security review or deployment runbooks.
Common Questions / FAQ
Who is salesforce-component-standards for?
Solo and small-team developers shipping on Salesforce who need Lightning Web Component, Aura, or Visualforce work reviewed against SLDS, accessibility, and platform security rules.
When should I use salesforce-component-standards?
During Build when authoring new UI, and during Ship when doing code review or security checks on any Salesforce component before release.
Is salesforce-component-standards safe to install?
Treat it like any third-party skill: review the Security Audits panel on this Prism page and confirm the SKILL.md matches what your agent will follow before enabling it in production repos.
SKILL.md
READMESKILL.md - Salesforce Component Standards
# Salesforce Component Quality Standards Apply these checks to every LWC, Aura component, and Visualforce page you write or review. ## Section 1 — LWC Quality Standards ### 1.1 Data Access Pattern Selection Choose the right data access pattern before writing JavaScript controller code: | Use case | Pattern | Why | |---|---|---| | Read a single record reactively (follows navigation) | `@wire(getRecord, { recordId, fields })` | Lightning Data Service — cached, reactive | | Standard CRUD form for a single object | `<lightning-record-form>` or `<lightning-record-edit-form>` | Built-in FLS, CRUD, and accessibility | | Complex server query or filtered list | `@wire(apexMethodName, { param })` on a `cacheable=true` method | Allows caching; wire re-fires on param change | | User-triggered action, DML, or non-cacheable server call | Imperative `apexMethodName(params).then(...).catch(...)` | Required for DML — wired methods cannot be `@AuraEnabled` without `cacheable=true` | | Cross-component communication (no shared parent) | Lightning Message Service (LMS) | Decoupled, works across DOM boundaries | | Multi-object graph relationships | GraphQL `@wire(gql, { query, variables })` | Single round-trip for complex related data | ### 1.2 Security Rules | Rule | Enforcement | |---|---| | No raw user data in `innerHTML` | Use `{expression}` binding in the template — the framework auto-escapes. Never use `this.template.querySelector('.el').innerHTML = userValue` | | Apex `@AuraEnabled` methods enforce CRUD/FLS | Use `WITH USER_MODE` in SOQL or explicit `Schema.sObjectType` checks | | No hardcoded org-specific IDs in component JavaScript | Query or pass as a prop — never embed record IDs in source | | `@api` properties from parent: validate before use | A parent can pass anything — validate type and range before using as a query parameter | ### 1.3 SLDS 2 and Styling Standards - **Never** hardcode colours: `color: #FF3366` → use `color: var(--slds-c-button-brand-color-background)` or a semantic SLDS token. - **Never** override SLDS classes with `!important` — compose with custom CSS properties. - Use `<lightning-*>` base components wherever they exist: `lightning-button`, `lightning-input`, `lightning-datatable`, `lightning-card`, etc. - Base components include built-in SLDS 2, dark mode, and accessibility — avoid reimplementing their behaviour. - If using custom CSS, test in both **light mode** and **dark mode** before declaring done. ### 1.4 Accessibility Requirements (WCAG 2.1 AA) Every LWC component must pass all of these before it is considered done: - [ ] All form inputs have `<label>` or `aria-label` — never use placeholder as the only label - [ ] All icon-only buttons have `alternative-text` or `aria-label` describing the action - [ ] All interactive elements are reachable and operable by keyboard (Tab, Enter, Space, Escape) - [ ] Colour is not the only means of conveying status — pair with text, icon, or `aria-*` attributes - [ ] Error messages are associated with their input via `aria-describedby` - [ ] Focus management is correct in modals — focus moves into the modal on open and back on close ### 1.5 Component Communication Rules | Direction | Mechanism | |---|---| | Parent → Child | `@api` property or calling a `@api` method | | Child → Parent | `CustomEvent` — `this.dispatchEvent(new CustomEvent('eventname', { detail: data }))` | | Sibling / unrelated components | Lightning Message Service (LMS)