Creating LWC Components from Design

Orchestrate the end-to-end creation of a new Lightning Web Component from a design input (Figma, PRD, Aura source, or user description). This is the top-level workflow skill — it sequences the specialized sibling skills that own each stage. Org-aware data (LDS schema introspection, design-frame inspection) is resolved by handing off to

experience-lds-data-requirements-generate

or via design-tool URLs the user provides.

When to Use

Building a brand-new LWC from a Figma frame, PRD, or written spec.
Migrating an Aura component to LWC as a fresh build (in-place Aura → LWC porting is out of scope for this skill).
Creating a component whose requirements are still partly implicit and need distillation into a PRD before coding.

Do NOT use this skill for:

Refactoring an existing LWC (use
```
experience-lwc-generate
```
).
Aura → LWC in-place migration (out of scope for this skill).
Pure styling or data-layer work (use the specialized skills directly).

Prerequisites

At least one design input: Figma URL, PRD markdown, Aura component source, or a textual spec.
Target path (module folder) for the new LWC.
For data-backed components: access to the org so
```
experience-lds-data-requirements-generate
```
and
```
experience-lds-best-practices-apply
```
can resolve the schema and adapter shapes.

Knowledge Bases

references/prd-analysis-template.md — PRD section skeleton (copy it verbatim when producing a PRD).
references/figma-to-prd-blueprint.md — Figma-specific guidance for translating a frame into PRD sections (componentName/tagName, contentRequirements, dataRequirements, interactions, componentCommunication, states, accessibility/responsiveness/styling/localization/security). Read this before Phase 1.2 when the input is a Figma design.

Workflow (mandatory five phases)

Phase 1 — Gather PRD & requirements

Goal: produce a consolidated PRD that every later phase consumes.

Obtain raw requirements — collect the PRD, design spec, Figma URL, Aura source, or user text.
Figma → PRD (if applicable): follow references/figma-to-prd-blueprint.md for the full Figma-frame analysis and PRD section guidelines. Inputs you need from the user: the Figma URL, a screenshot of the target frame, and (if Dev Mode is available) the metadata export for the node. Translate into the PRD skeleton from references/prd-analysis-template.md using the section-by-section guidance in the blueprint.
Aura → PRD (if migrating): enumerate the Aura component's functionality that must be preserved — markup, controller/helper actions, events, attributes, and wired data — and feed that inventory into the PRD as explicit requirements. (In-place Aura → LWC porting is out of scope; this step only captures behavior for a fresh build.)
Data requirements (if the component reads/writes data): hand off to
```
experience-lds-data-requirements-generate
```
. That skill produces a validated data specification (object/field API names, recommended LDS API, implementation approach). Paste its output verbatim into the PRD.
Adapter exploration: hand off to
```
experience-lds-best-practices-apply
```
for the adapter selection rules (UI API vs GraphQL vs Apex) and the recommended wiring for the chosen approach.
Naming:
```
componentName
```
must be camelCase (e.g.,
```
productCard
```
) and
```
tagName
```
must be its kebab-case form (e.g.,
```
product-card
```
). Validate both with the bundled script — do not eyeball the check:
bash
```
"<skill_dir>/scripts/check-component-name.sh" <componentName> <tagName>
```
The script exits nonzero (with an actionable stderr message) if either name is malformed or if the kebab form of
```
componentName
```
does not equal
```
tagName
```
.

Deliverable: a comprehensive PRD covering purpose, content, data, interactions, states, a11y, responsiveness, styling direction, localization, and security. Keep it checked into the workspace (e.g.,

packages/skills/<skill>-workspace/<iteration>/PRD.md

Phase 2 — Generate component code

Goal: initial

.html

.js

.css

.js-meta.xml

that strictly reflect the PRD.

Hand off to
```
experience-lwc-generate
```
with the PRD content as the spec. That skill owns PRD → code translation (events, getters,
```
@api
```
,
```
.js-meta.xml
```
, AI metadata) and is the authoring source of truth.
Use the SLDS decision hierarchy from
```
design-systems-slds-apply
```
:
1. Prefer a matching Lightning Base Component (
```
experience-lwc-base-components-integrate
```
  ).
2. Otherwise pick an SLDS Blueprint or utility class (per
```
design-systems-slds-apply
```
  ).
3. Otherwise write custom CSS using SLDS styling hooks (also covered in
```
design-systems-slds-apply
```
  ).
Re-confirm the authoring baseline by walking the
```
experience-lwc-generate
```
checklist before proceeding.
Translate every PRD data requirement to either a wire adapter (UIAPI / GraphQL) or an explicit TODO.
Adhere strictly to the PRD:
- Only include features and behaviors the PRD describes.
- Mark uncertain areas with
```
// TODO:
```
  comments that quote the PRD language raising the ambiguity.
- Add extensive code comments explaining intent.
- Do not split the component into more sub-components than the PRD implies.

Deliverable: a first-pass LWC bundle in the target path.

Phase 3 — Optimize component

Goal: apply performance, maintainability, and best-practice fixes.

Walk the optimization checklist below before any other review:
- Single responsibility, encapsulation, reusability.
- Minimize DOM operations; batch updates via properties.
- Audit event handlers and lifecycle hook usage (
```
renderedCallback
```
  guards).
- Consider lazy loading for heavy children.
Hand off to
```
experience-lwc-generate
```
for the LWC best-practices review pass (anti-patterns, reactivity, composition).
Hand off to the compliance suite for the pre-ship review —
```
experience-lwc-accessibility-validate
```
(a11y),
```
experience-lwc-security-validate
```
(LWS + Product Security), and
```
experience-lwc-rtl-validate
```
(RTL i18n). Run them together for the full quality pass.
If the component touches data, hand off to
```
experience-lds-best-practices-apply
```
for cache/consistency and referential-integrity checks.
Apply every accepted finding. Keep the PRD as the source of truth — do not add scope under the guise of optimization.

Phase 4 — Lint, format, compile-check

Condition: only run steps whose tooling is configured in the project.

Detect project tooling — invoke the bundled detection script from the project root and read its
```
<tool>=yes|no
```
lines. Do NOT eyeball
```
package.json
```
/ dotfiles in prose:
bash
```
"<skill_dir>/scripts/detect-project-tools.sh" <projectRoot>
```
Sample output:
text
```
eslint=yes
prettier=yes
cursor-rules=no
lwc-compiler=yes
```
Run the substeps below only for tools reported
```
yes
```
; skip the rest.
ESLint (if
```
eslint=yes
```
) — run and fix all violations.
Prettier (if
```
prettier=yes
```
) — run for consistent formatting.
Cursor rules (if
```
cursor-rules=yes
```
) — apply every rule the project ships.
LWC compiler (if
```
lwc-compiler=yes
```
) — run via local dev server or SFDX; resolve every syntax/template error before moving on.

Deliverable: clean, validated component code.

Phase 5 — Create tests

Hand off to

experience-lwc-accessibility-jest-run

for automated accessibility Jest coverage; add general-purpose Jest coverage in the same pass following the

experience-lwc-generate

test guidance, plus UTAM page object generation if the team requires it.

Deliverable: the LWC bundle with a passing test suite at or above the project's coverage threshold.

Definition of Done

A new component built from this workflow is "done" only when every item below is true. Treat this as the canonical readiness checklist — copy it into the PR description so reviewers can confirm each line.

Code completion — no implementation gaps:

Every PRD requirement is either implemented or explicitly annotated with a
```
TODO:
```
and a linked tracking item. No silent gaps.

TODO

FIXME

, or

console.log

console.table

alert()

left in production paths.

No commented-out code blocks, no empty function bodies, no placeholder values, no dummy data, no unreferenced imports.
No
```
lwc:dom="manual"
```
regions or third-party-library escape hatches without a comment explaining why a native LWC pattern wasn't used.

Compliance and quality:

.js-meta.xml

AI metadata passes the audit in

experience-lwc-generate

(component-wide

<ai><description>

set, plus an

<ai><property name="…" aiDescription="…"/></ai>

entry for every

@api

member exposed through

<targetConfig>

; no marketing language).

SLDS styling passes
```
design-systems-slds-apply
```
verification — no raw hex / px values, only styling hooks and SLDS utility classes.
Accessibility pass complete:
```
experience-lwc-accessibility-validate
```
for source review +
```
experience-lwc-accessibility-jest-run
```
for automated tests, both green.

Security + RTL pass complete:

experience-lwc-security-validate

experience-lwc-rtl-validate

, both green.

Data + tests:

Data layer verified against the referenced LDS adapters (every wire / imperative call is documented in the PRD's data section and matches one of the adapters from
```
experience-lds-best-practices-apply
```
or
```
experience-lds-data-requirements-generate
```
).
Jest tests green at the required coverage level for the project. New tests cover every
```
@api
```
surface, every dispatched event, and every error path (failed wire, failed apex, validation rejection).
UTAM page objects produced for any UI flow that needs cross-component browser-level testing (skip if not needed).

Cross-References

Skills chained by this workflow (in phase order):
- ```
experience-lds-data-requirements-generate
```
  — Phase 1.4 data spec (and Phase 1.5 adapter exploration alongside
```
experience-lds-best-practices-apply
```
  ).
- ```
design-systems-slds-apply
```
  ,
```
experience-lwc-base-components-integrate
```
  — Phase 2 styling decisions.
- ```
experience-lwc-generate
```
  — Phase 2 authoring baseline + Phase 3 best-practices review + Phase 5 AI-metadata audit.
- ```
experience-lds-best-practices-apply
```
  — Phase 2/3 data-layer adapter selection and consistency review.
- ```
experience-lwc-accessibility-validate
```
  ,
```
experience-lwc-security-validate
```
  ,
```
experience-lwc-rtl-validate
```
  — Phase 3 a11y/security/RTL review.
- ```
experience-lwc-accessibility-jest-run
```
  — Phase 5 automated a11y test generation.
- Optional: add o11y instrumentation as a separate pass once the component stabilizes.
- ```
experience-lwc-typescript-migrate
```
  — optional once JS is green.
- When the new component ships behind a flag, gate it with a feature flag during rollout.
- ```
experience-lwc-api-docs-generate
```
  — once the public API surface is stable.
Org-aware inputs used by this workflow:
- Figma URL + screenshot (and, if available, the developer's Dev Mode metadata export) — Phase 1.2 Figma input.
- ```
experience-lds-data-requirements-generate
```
  owns the org-schema introspection and data-spec validation used in Phase 1 when the component needs org-backed data — hand off to that skill rather than duplicating its work here.

Examples

Phase 1 PRD skeleton (fill from the Figma/PRD/Aura input)

text

Component: productCard (<product-card>)
Purpose: Render a compact summary of a product with quick actions.

Content requirements
- Hero image (Product.HeroImage__c)
- Title (Product.Name)
- Subtitle (Product.Tagline__c)
- Primary CTA button ("Add to cart")
- Secondary CTA icon button ("Favorite")

Data requirements
- Input: @api recordId (Product Id)
- Adapter: getRecord (UIAPI) with fields Name, Tagline__c, HeroImage__c
- Events out: addtocart{detail.recordId}, favorite{detail.recordId, detail.value}

States
- Loading (data not yet resolved)
- Error (adapter error)
- Empty (no record found)
- Default

Accessibility
- Title uses <h3>
- Icon-only button carries aria-label="Favorite"
- Card is a labelled region (role="group", aria-labelledby)

Responsiveness
- Full width < 480px
- Side-by-side image + text >= 480px

Styling
- Uses lightning-card wrapper
- Surface color: --slds-g-color-surface-container-1
- Shadow: --slds-g-shadow-1

Phase 2 skeleton

javascript

import { LightningElement, api, wire } from 'lwc';
import { getRecord } from 'lightning/uiRecordApi';
import NAME from '@salesforce/schema/Product__c.Name';
import TAGLINE from '@salesforce/schema/Product__c.Tagline__c';
import HERO from '@salesforce/schema/Product__c.HeroImage__c';

const FIELDS = [NAME, TAGLINE, HERO];

export default class ProductCard extends LightningElement {
    @api recordId;

    @wire(getRecord, { recordId: '$recordId', fields: FIELDS })
    record;

    get hasRecord() { return this.record?.data != null; }
    get isLoading() { return !this.record; }
    get hasError()  { return !!this.record?.error; }
    get name()      { return this.record?.data?.fields?.Name?.value ?? ''; }
    get tagline()   { return this.record?.data?.fields?.Tagline__c?.value ?? ''; }
    get heroUrl()   { return this.record?.data?.fields?.HeroImage__c?.value ?? ''; }

    handleAddToCart() {
        this.dispatchEvent(new CustomEvent('addtocart', { detail: { recordId: this.recordId }, bubbles: true, composed: true }));
    }
    handleFavorite(event) {
        this.dispatchEvent(new CustomEvent('favorite', { detail: { recordId: this.recordId, value: event.detail.value }, bubbles: true, composed: true }));
    }
}

Verification

Every PRD section is traceable to at least one block of code or an explicit TODO.
Phases 1–5 were executed in order; no step was skipped.
Accessibility, SLDS, data-layer, and AI metadata reviews all pass.
Coverage meets or exceeds the project's threshold.
The component renders correctly in
```
experience-lwc-runtime-observe
```
across the responsive breakpoints enumerated in the PRD.

experience-lwc-design-generate

NPX Install

Tags

SKILL.md Content