/experience-lwc-design-generate

name: experience-lwc-design-generate
description: "Use when you need to create a brand new Lightning Web Component from a Figma design, a Product Requirements Document, or another design artifact — orchestrating the five-phase workflow (gather requirements → generate code → optimize → lint/format/compile → test) and stitching together the specialized skills for SLDS, LDS, base components, optimization, and testing. Use this skill whenever the user mentions building a new LWC from Figma, building an LWC from a PRD, generating an LWC from a design or screenshot, or migrating an Aura component as a fresh LWC build. DO NOT TRIGGER when refactoring an existing LWC (use experience-lwc-generate), for Aura → LWC in-place migration (out of scope for this skill), for standalone SLDS token or styling work (use design-systems-slds-apply), or for standalone data-layer work (use experience-lds-best-practices-apply or experience-lds-data-requirements-generate)."
metadata:
  version: "1.0"
  domains: ["Experience", "Design Systems"]
  cliTools:
    - tool: ["eslint"]
      semver: ">=8.0"
    - tool: ["prettier"]
      semver: ">=2.0"
    - tool: ["python3"]
      semver: ">=3.8"
  relatedSkills:
    - design-systems-slds-apply
    - experience-lds-best-practices-apply
    - experience-lds-data-requirements-generate
    - experience-lwc-accessibility-jest-run
    - experience-accessibility-validate
    - experience-lwc-base-components-integrate
    - experience-lwc-generate
    - experience-lwc-rtl-validate
    - experience-lwc-runtime-observe
    - experience-lwc-security-validate
    - experience-lwc-typescript-migrate

<!-- adk-managed-skill -->

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](references/prd-analysis-template.md) — PRD section skeleton (copy it verbatim when producing a PRD).
• [references/figma-to-prd-blueprint.md](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.

1. **Obtain raw requirements** — collect the PRD, design spec, Figma URL, Aura source, or user text. 2. **Figma → PRD** (if applicable): follow [references/figma-to-prd-blueprint.md](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](references/prd-analysis-template.md) using the section-by-section guidance in the blueprint. 3. **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.) 4. **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. 5. **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. 6. **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:

   "<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.

1. Hand off to `experience-lwc-genera