/experience-lwc-base-components-integrate

name: experience-lwc-base-components-integrate
description: "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 Lightning modal / datatable / combobox / record form\", ask which `lightning-*` component fits a use case, want a shortlist of LBC candidates, are about to hand-roll a UI that a base component already provides, or are editing an LWC bundle's `.html` / `.js` / `.css` and need to select or wire a base component. Also triggers on \"Lightning base component\", \"LBC\", \"lightning-combobox\", \"lightning-datatable\", \"use `lightning-` tag\". DO NOT TRIGGER for applying SLDS design tokens, blueprints, or styling guidance in general — that is `design-systems-slds-apply`; this skill only selects and wires `lightning-*` base components."
metadata:
  version: "1.0"
  domains: ["Experience"]
  relatedSkills:
    - design-systems-slds-apply

<!-- 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:

scripts/extract-component-docs.sh <camelCaseName> [<camelCaseName>...]

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