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](../sf-apex/rule file)
- building Flow XML rather than an LWC screen component → [sf-flow](../sf-flow/rule file)
- deploying metadata → [sf-deploy](../sf-deploy/rule file)
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](../sf-apex/rule file) for controllers / services
- [sf-deploy](../sf-deploy/rule file) for deployment
- [sf-testing](../sf-testing/rule file) only for Apex-side test loops, not Jest
High-Signal Rules
- prefer platform base components over reinventing controls
- use
@wire for 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](../sf-apex/rule file) |
backend logic |
| embed in Flow screens |
[sf-flow](../sf-flow/rule file) |
declarative orchestration |
| deploy component bundle |
[sf-deploy](../sf-deploy/rule file) |
org rollout |
| create metadata like message channels |
[sf-metadata](../sf-metadata/rule file) |
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 |
1---2name: sf-lwc3description: 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.4license: MIT5---67# sf-lwc: Lightning Web Components Development89Use 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.1011## When This Skill Owns the Task1213Use `@sf-lwc` when the work involves:14- `lwc/**/*.js`, `.html`, `.css`, `.js-meta.xml`15- component scaffolding and bundle design16- wire service, Apex integration, GraphQL integration17- SLDS 2, dark mode, and accessibility work18- Jest unit tests for LWC1920Delegate elsewhere when the user is:21- writing Apex controllers or business logic first → [sf-apex](../sf-apex/rule file)22- building Flow XML rather than an LWC screen component → [sf-flow](../sf-flow/rule file)23- deploying metadata → [sf-deploy](../sf-deploy/rule file)2425---2627## Required Context to Gather First2829Ask for or infer:30- component purpose and target surface31- data source: LDS, Apex, GraphQL, LMS, or external system via Apex32- whether the user needs tests33- whether the component must run in Flow, App Builder, Experience Cloud, or dashboard contexts34- accessibility and styling expectations3536---3738## Recommended Workflow3940### 1. Choose the right architecture41Use the **PICKLES** mindset:42- prototype43- integrate the right data source44- compose component boundaries45- define interaction model46- use platform libraries47- optimize execution48- enforce security4950### 2. Choose the right data access pattern51| Need | Default pattern |52|---|---|53| single-record UI | LDS / `getRecord` |54| simple CRUD form | base record form components |55| complex server query | Apex `@AuraEnabled(cacheable=true)` |56| related graph data | GraphQL wire adapter |57| cross-DOM communication | Lightning Message Service |5859### 3. Start from an asset when useful60Use provided assets for:61- basic component bundles62- datatables63- modal patterns64- Flow screen components65- GraphQL components66- LMS message channels67- Jest tests68- TypeScript-enabled components6970### 4. Validate for frontend quality71Check:72- accessibility73- SLDS 2 / dark mode compliance74- event contracts75- performance / rerender safety76- Jest coverage when required7778### 5. Hand off supporting backend or deploy work79Use:80- [sf-apex](../sf-apex/rule file) for controllers / services81- [sf-deploy](../sf-deploy/rule file) for deployment82- [sf-testing](../sf-testing/rule file) only for Apex-side test loops, not Jest8384---8586## High-Signal Rules8788- prefer platform base components over reinventing controls89- use `@wire` for reactive read-only use cases; imperative calls for explicit actions and DML paths90- do not introduce inaccessible custom UI91- avoid hardcoded colors; use SLDS 2-compatible styling hooks / variables92- avoid rerender loops in `renderedCallback()`93- keep component communication patterns explicit and minimal9495---9697## Output Format9899When finishing, report in this order:1001. **Component(s) created or updated**1012. **Data access pattern chosen**1023. **Files changed**1034. **Accessibility / styling / testing notes**1045. **Next implementation or deploy step**105106Suggested shape:107108```text109LWC work: <summary>110Pattern: <wire / apex / graphql / lms / flow-screen>111Files: <paths>112Quality: <a11y, SLDS2, dark mode, Jest>113Next step: <deploy, add controller, or run tests>114```115116---117118## Local Development Server119120Preview LWC components locally with hot reload — no deployment needed:121122```bash123# Preview LWC components in isolation124sf lightning dev component --target-org <alias>125126# Preview a Lightning Experience app locally127sf lightning dev app --target-org <alias>128129# Preview an Experience Cloud site locally130sf lightning dev site --target-org <alias>131```132133In 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.134135---136137## Cross-Skill Integration138139| Need | Delegate to | Reason |140|---|---|---|141| Apex controller or service | [sf-apex](../sf-apex/rule file) | backend logic |142| embed in Flow screens | [sf-flow](../sf-flow/rule file) | declarative orchestration |143| deploy component bundle | [sf-deploy](../sf-deploy/rule file) | org rollout |144| create metadata like message channels | [sf-metadata](../sf-metadata/rule file) | supporting metadata |145146---147148## Reference Map149150### Start here151- [references/component-patterns.md](references/component-patterns.md)152- [references/slds-design-guide.md](references/slds-design-guide.md)153- [references/lwc-best-practices.md](references/lwc-best-practices.md)154- [references/scoring-and-testing.md](references/scoring-and-testing.md)155- [references/jest-testing.md](references/jest-testing.md)156157### Accessibility / performance / state158- [references/accessibility-guide.md](references/accessibility-guide.md)159- [references/performance-guide.md](references/performance-guide.md)160- [references/state-management.md](references/state-management.md)161- [references/template-anti-patterns.md](references/template-anti-patterns.md)162163### Integration / advanced features164- [references/lms-guide.md](references/lms-guide.md)165- [references/flow-integration-guide.md](references/flow-integration-guide.md)166- [references/advanced-features.md](references/advanced-features.md)167- [references/async-notification-patterns.md](references/async-notification-patterns.md)168- [references/triangle-pattern.md](references/triangle-pattern.md)169- [assets/](assets/)170171---172173## Score Guide174175| Score | Meaning |176|---|---|177| 150+ | production-ready LWC bundle |178| 125–149 | strong component with minor polish left |179| 100–124 | functional but review recommended |180| < 100 | needs significant improvement |