Agent skill · forcedotcom
experience-lds-best-practices-apply
Use when reviewing or implementing Lightning Data Service best practices in an LWC (.js, .html, .js-meta.xml) — UIAPI vs Apex, refreshApex / notifyRecordUpdateAvailable, @salesforce/schema imports, LDS record-form data patterns. TRIGGER on \"apply LDS best practices to this LWC\", \"review this LWC for LDS best-practice issues\", \"review this component for Lightning Data Service issues\", \"UIAPI or Apex for this data?\", \"fix stale data after record save\", \"sync LDS cache\", \"use @salesforce/schema for field names\", \"choose between getRecord and Apex\". DO NOT TRIGGER when building a new LWC (use experience-lwc-generate), applying SLDS design tokens (use design-systems-slds-apply), picking or wiring a `lightning-*` base component's props/events/slots generically (use experience-lwc-base-components-integrate — this skill covers only the LDS data-layer rationale, even when the fix involves a base record form), or for security / RTL / accessibility reviews (separate passes).
What it needs
About 7k tokens when loaded.
What this skill does
<!-- adk-managed-skill --> Applying LDS Best Practices Apply the Lightning Data Service guidelines to a Lightning Web Component. Three pillars: data consistency, referential integrity, and UIAPI vs Apex. Focused on the UI API path — GraphQL and upstream data-requirements analysis are handled out-of-band. When to Use Reviewing a component's data layer for LDS compliance (hand-rolled forms, stringly-typed field names, un-synchronized Apex + LDS, Apex overuse). Implementing CRUD on standard or custom objects. Deciding between getRecord, getRecords, createRecord, updateRecord, deleteRecord, base record form components, or Apex. Fixing stale-data bugs after record mutation. Adding schema imports (@salesforce/schema/...) to replace hard-coded field/object names. Do NOT use this skill for: GraphQL query/mutation generation — handled out-of-band today. Upstream data-requirements discovery — handled out-of-band today. SLDS class / design-token work (use design-systems-slds-apply). Accessibility, security, or RTL review — those are separate passes run with their own tooling. Prerequisites Component path. Understanding of the component's data operations (read / write / both) and whether Apex is already involved. Access to the org's schema for @salesforce/schema imports (Setup → Object Manager → <Object> → Details → API Name; or, when GraphQL serves the read, an SDL pulled from the target org). Knowledge Bases references/lds-expert.md — authoritative LDS knowledge (patterns, adapters, caching, mutation flows). references/lds-data-consistency.md — cache invalidation, refreshApex, notifyRecordUpdateAvailable, wire result propagation. references/lds-referential-integrity.md — @salesforce/schema imports, field constants, object-name resolution, and their propagation through refactors. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills forcedotcom/experience-lds-best-practices-apply