sf-lwc
jaganpro/sf-skills
Lightning Web Components with PICKLES methodology and 165-point quality scoring.
What is sf-lwc?
Build production-ready Lightning Web Components using the PICKLES architecture mindset. This skill handles component bundles, wire patterns, Apex/GraphQL integration, SLDS 2 styling, accessibility, performance, and Jest testing. Use it when creating or editing LWC files, wire services, or component logic.
- Scaffold and design LWC component bundles with proper file structure
- Implement data access patterns (LDS, Apex @AuraEnabled, GraphQL, LMS)
- Apply SLDS 2 and dark mode compliant styling with accessibility
- Build Jest unit tests for LWC components
- Integrate with Apex controllers, GraphQL, and Lightning Message Service
- Validate components against 165-point quality scoring rubric
How to install sf-lwc
npx skills add https://github.com/jaganpro/sf-skills --skill sf-lwc- Salesforce CLI (sf) installed
- Active org connection for local dev server and data access
- Node.js for Jest testing (included with Salesforce CLI)
How to use sf-lwc
- 1.Gather component requirements: purpose, data source, target surface (App Builder, Flow, Experience Cloud)
- 2.Choose the appropriate data access pattern from the provided table (LDS, Apex, GraphQL, LMS)
- 3.Use provided assets or scaffold a new LWC bundle with .js, .html, .css, and .js-meta.xml files
- 4.Implement component logic following PICKLES methodology: prototype, integrate, compose, define interactions, use platform libraries, optimize, enforce security
- 5.Apply SLDS 2 styling and validate accessibility standards
- 6.Write Jest unit tests for component behavior and wire service integration
- 7.Run local dev server with `sf lightning dev component` for hot-reload preview
- 8.Validate against 165-point scoring rubric before handoff to deployment
Use cases
- Create a data-driven component that fetches records via Apex and displays them in a datatable with sorting and filtering
- Build a Flow screen component that captures user input and communicates via Lightning Message Service
- Develop a reusable modal or form component with full accessibility and SLDS 2 styling
- Write Jest tests for component logic including wire service mocking and event handling
- Refactor an existing component to improve performance, accessibility, or dark mode compliance
- Salesforce developers building Lightning Experience components
- Flow builders embedding custom LWC screen components
- Teams standardizing on SLDS 2 and accessibility compliance
- Developers writing testable, maintainable component code
sf-lwc FAQ
Use @wire for reactive, read-only use cases where you want automatic reactivity. Use imperative calls for explicit actions, DML operations, and when you need fine-grained control over when data is fetched.
Use LDS/getRecord for single-record UI, base record form components for simple CRUD, Apex @AuraEnabled(cacheable=true) for complex queries, GraphQL for related graph data, and Lightning Message Service for cross-DOM communication.
Use `sf lightning dev component --target-org <alias>` to preview components with hot reload. Changes to .js, .html, and .css files auto-reload instantly. Requires an active org connection for data and Apex callouts.
Validate accessibility, SLDS 2 / dark mode compliance, event contracts, performance (no rerender loops), and Jest coverage. Components scoring 150+ on the 165-point rubric are production-ready.
Use sf-apex for Apex controllers and business logic, sf-flow for Flow XML and orchestration, sf-deploy for metadata deployment, and sf-metadata for supporting metadata like message channels.
Full instructions (SKILL.md)
Source of truth, from jaganpro/sf-skills.
name: sf-lwc description: > Lightning Web Components with PICKLES methodology and 165-point scoring. TRIGGER when: user creates/edits LWC components, touches lwc/**/*.js, .html, .css, .js-meta.xml files, or asks about wire service, SLDS, or Jest LWC tests. DO NOT TRIGGER when: Apex classes (use sf-apex), Aura components, or Visualforce. license: MIT metadata: version: "2.1.0" author: "Jag Valaiyapathy" scoring: "165 points across 8 categories (SLDS 2 + Dark Mode compliant)"
sf-lwc: Lightning Web Components Development
Use this skill when the user needs Lightning Web Components: LWC bundles, wire patterns, Apex/GraphQL integration, SLDS 2 styling, accessibility, performance work, or Jest unit tests.
When This Skill Owns the Task
Use sf-lwc when the work involves:
lwc/**/*.js,.html,.css,.js-meta.xml- component scaffolding and bundle design
- wire service, Apex integration, GraphQL integration
- SLDS 2, dark mode, and accessibility work
- Jest unit tests for LWC
Delegate elsewhere when the user is:
- writing Apex controllers or business logic first → sf-apex
- building Flow XML rather than an LWC screen component → sf-flow
- deploying metadata → sf-deploy
Required Context to Gather First
Ask for or infer:
- component purpose and target surface
- data source: LDS, Apex, GraphQL, LMS, or external system via Apex
- whether the user needs tests
- whether the component must run in Flow, App Builder, Experience Cloud, or dashboard contexts
- accessibility and styling expectations
Recommended Workflow
1. Choose the right architecture
Use the PICKLES mindset:
- prototype
- integrate the right data source
- compose component boundaries
- define interaction model
- use platform libraries
- optimize execution
- enforce security
2. Choose the right data access pattern
| Need | Default pattern |
|---|---|
| single-record UI | LDS / getRecord |
| simple CRUD form | base record form components |
| complex server query | Apex @AuraEnabled(cacheable=true) |
| related graph data | GraphQL wire adapter |
| cross-DOM communication | Lightning Message Service |
3. Start from an asset when useful
Use provided assets for:
- basic component bundles
- datatables
- modal patterns
- Flow screen components
- GraphQL components
- LMS message channels
- Jest tests
- TypeScript-enabled components
4. Validate for frontend quality
Check:
- accessibility
- SLDS 2 / dark mode compliance
- event contracts
- performance / rerender safety
- Jest coverage when required
5. Hand off supporting backend or deploy work
Use:
- sf-apex for controllers / services
- sf-deploy for deployment
- sf-testing only for Apex-side test loops, not Jest
High-Signal Rules
- prefer platform base components over reinventing controls
- use
@wirefor reactive read-only use cases; imperative calls for explicit actions and DML paths - do not introduce inaccessible custom UI
- avoid hardcoded colors; use SLDS 2-compatible styling hooks / variables
- avoid rerender loops in
renderedCallback() - keep component communication patterns explicit and minimal
Output Format
When finishing, report in this order:
- Component(s) created or updated
- Data access pattern chosen
- Files changed
- Accessibility / styling / testing notes
- Next implementation or deploy step
Suggested shape:
LWC work: <summary>
Pattern: <wire / apex / graphql / lms / flow-screen>
Files: <paths>
Quality: <a11y, SLDS2, dark mode, Jest>
Next step: <deploy, add controller, or run tests>
Local Development Server
Preview LWC components locally with hot reload — no deployment needed:
# Preview LWC components in isolation
sf lightning dev component --target-org <alias>
# Preview a Lightning Experience app locally
sf lightning dev app --target-org <alias>
# Preview an Experience Cloud site locally
sf lightning dev site --target-org <alias>
In current SF CLI releases, these Local Dev commands are installed just-in-time the first time you run them. They are long-running processes that open a browser with live preview. Changes to .js, .html, and .css files auto-reload instantly. Requires an active org connection for data and Apex callouts.
Cross-Skill Integration
| Need | Delegate to | Reason |
|---|---|---|
| Apex controller or service | sf-apex | backend logic |
| embed in Flow screens | sf-flow | declarative orchestration |
| deploy component bundle | sf-deploy | org rollout |
| create metadata like message channels | sf-metadata | supporting metadata |
Reference Map
Start here
- references/component-patterns.md
- references/slds-design-guide.md
- references/lwc-best-practices.md
- references/scoring-and-testing.md
- references/jest-testing.md
Accessibility / performance / state
- references/accessibility-guide.md
- references/performance-guide.md
- references/state-management.md
- references/template-anti-patterns.md
Integration / advanced features
- references/lms-guide.md
- references/flow-integration-guide.md
- references/advanced-features.md
- references/async-notification-patterns.md
- references/triangle-pattern.md
- assets/
Score Guide
| Score | Meaning |
|---|---|
| 150+ | production-ready LWC bundle |
| 125–149 | strong component with minor polish left |
| 100–124 | functional but review recommended |
| < 100 | needs significant improvement |
Related skills
More from jaganpro/sf-skills and the wider catalog.
sf-metadata
Generate and query Salesforce metadata with 120-point quality scoring.
sf-permissions
Permission Set analysis, hierarchy viewing, and access auditing for Salesforce orgs.
sf-soql
SOQL/SOSL query generation, optimization, and performance scoring for Salesforce.
sf-testing
Run Apex tests, analyze coverage, and fix failures with structured test-fix loops.
sf-vlocity-build-deploy
>
transitions-dev
Production-ready CSS transitions for web apps. Use when implementing notification badges, dropdowns, modals, panel reveals, page transitions, card resizes, number pop-ins, text swaps, icon swaps, success checks, avatar group hovers, or error state shakes. Triggers on "add a transition", "animate the dropdown", "make the modal open smoothly", "swap icon", "page slide", "stagger animation", "open / close transition", "make it animate", "tween the size", "fade between", "smooth open", "smooth close", "success animation", "checkmark animation", "confirmation animation", "form error", "shake on invalid", "validation feedback", "hover lift", "avatar stack hover", "chip group hover".