Pick the right Lightning Base Component (`lightning-*`) for a given UI task, retrieve its full API (props, methods, events, slots) from the bundled per-component reference, and wire it into an LWC (LWC `.html`, `.js`, and `.css` files) without breaking SLDS. Use this skill when users say "I need a L

<! adk managed skill Using Lightning Base Components Lightning Base Components (LBC) are the lightning web components shipped by Salesforce. This skill routes an agent through the right decision sequence so the final component choice is as specific as possible and backed by real API docs — not a hand rolled reimplementation of something that already exists. When to Use This Skill User describes a UI need ("searchable dropdown", "record edit form", "modal with footer") and asks which lightning component fits. User is about to build a primitive (button group, combobox, toast) and should be using LBC instead. User asks you to review LWC markup for LBC related issues — specifically overriding SLDS classes or restyling LBC internals. User needs the authoritative props/events/slots for a specific lightning tag. Prerequisites Knowledge of which LBC namespace your org uses ( lightning is the default public namespace; some platforms expose lightning community or others — the user's meta files will clarify). The skill ships authoritative API docs for every Lightning Base Component in [references/lightning components.md](references/lightning components.md). Each component is a Component API Structure block; grep for Name: <camelCaseName (e.g. Name: datatable ) to jump to its Properties / Methods / Events / Slots. Read this rather than relying on cached knowledge — LBC evolves and the reference is the source of truth. Workflow Step 1 — Read the entire component index first Open [lightning component index.md](references/lightning component index.md) and scan all entries before making any selection. This is non negotiable: LBC's value comes from picking the most specialized component, and skipping the scan leads to reinventing compound widgets out of primitives. As you scan, compile a candidate list — every component whose description touches any aspect of the use case. Do not filter or rank yet. Step 2 — Narrow to the most specific fit per feature Once the scan is complete: For each feature in the use case, select the most specific component that covers it. Prefer a specialized compound ( lightning record form , lightning tabset , lightning datatable ) over a generic primitive ( lightning input , lightning button ) when the specialized one covers the scenario end to end. Avoid duplication: if lightning record form already renders fields for a record, do not pair it with lightning input field unless you're explicitly overriding behavior. Step 3 — Share the shortlist and confirm Present the final shortlist to the developer with a one line rationale per component. Wait for explicit confirmation before pulling full API docs. This prevents the agent from burning context on components the developer has already mentally ruled out. Step 4 — Retrieve full API docs Once confirmed, use the bundled helper to pull the exact API blocks — this avoids ad hoc grepping across a large reference: Convert lightning <foo tags to camelCase (no lightning prefix): lightning datatable → datatable lightning record edit form → recordEditForm lightning button icon → buttonIcon Each returned block has the same shape: Basic Information (tag, namespace, type), Properties (name, type, default, description), Methods , Events , Slots , and (where applicable) usage notes. This skill is about picking the components; the bundled reference is about wiring them. Step 5 — Produce integration guidance Using the per component reference, walk the developer through: The exact <lightning ... tag and required attributes. Which events to bind ( onchange , oncommit , onsuccess , …) and what the event payload contains. Any slots to fill (headers, footers, custom content). Known constraints from the component docs (e.g. lightning record form requires object api name and record id for edit/view modes). Step 6 — Respect LBC styling rules Do not override SLDS classes on LBC internals. See [lbc expert guidance.md](references/lbc expert guidance.md) for specifics. Common issues: Targeting .slds button or .slds input in the host component's CSS to restyle an LBC — LBC ships inside a shadow root, so these selectors either leak into sibling components or get stripped entirely. Use the component's documented styling hooks ( sds c button , etc.) instead. Wrapping an LBC just to mutate its internal markup. You can't — the markup is hidden behind the shadow root. If the component doesn't expose the slot/prop you need, that's a platform level gap, not a restyling job. Examples Example — "I need a multi select combobox with typeahead" 1. Scan the component index end to end. 2. Candidate list includes: lightning combobox , lightning dual listbox , lightning record picker . 3. Shortlist: lightning dual listbox (the documented multi select base component). Rule out lightning combobox — its documented API is single select; it has no type="multi" and no multi select mode. Flag that lightning record picker only fits if the values are record IDs. 4. Developer confirms lightning dual listbox . 5. Run scripts/extract component docs.sh dualListbox . 6. Return the options , value , onchange payload, and required label props from the block's Properties / Events sections. Example — "I'm going to write my own modal" 1. Scan finds lightning modal , lightning modal body , lightning modal footer , lightning modal header . 2. Shortlist is the 4 modal components. 3. Confirm. 4. Run scripts/extract component docs.sh modal modalHeader modalBody modalFooter → full modal API (how to extend LightningModal , the static .open() pattern, slotting the header/body/footer). 5. Steer the developer away from rolling their own dialog. Verification Checklist [ ] The full component index was scanned before any selection (no keyword search shortcutting). [ ] Candidate list included every component that touches the use case. [ ] Final shortlist selects the most specific component per feature. [ ] Developer confirmed the shortlist before the bundled component reference was opened. [ ] Integration guidance cites props / events / slots from the real API docs (not inferred). [ ] No suggestions to restyle LBC by overriding SLDS classes. Troubleshooting Grep for Name: <name returns no match — name is wrong, or the reference uses a different camelCase. Double check against the component index ( lightning record form → recordForm , lightning record view form → recordViewForm , lightning button icon → buttonIcon ). Proposed component doesn't have the prop you expected — trust the real API doc over memory. LBC evolves; cached knowledge lies. Developer resists the shortlist — don't skip Step 4. Still retrieve the docs for the developer's preferred choice so they see the actual trade offs. Developer wants to restyle LBC internals — redirect to styling hooks (see the LBC Expert reference). Refusing shadow DOM penetration is the correct answer.

experience-lwc-base-components-integrate