Experience Lwc Design Generate

<!-- 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 — 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.

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

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-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.
2. 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).
3. Re-confirm the authoring baseline by walking the experience-lwc-generate checklist before proceeding.
4. Translate every PRD data requirement to either a wire adapter (UIAPI / GraphQL) or an explicit TODO.
5. 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.

1. 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.
2. Hand off to experience-lwc-generate for the LWC best-practices review pass (anti-patterns, reactivity, composition).
3. Hand off to the compliance suite for the pre-ship review — experience-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.
4. If the component touches data, hand off to experience-lds-best-practices-apply for cache/consistency and referential-integrity checks.
5. 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.

1. 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:

   "<skill_dir>/scripts/detect-project-tools.sh" <projectRoot>

   Sample output:

   eslint=yes
   prettier=yes
   cursor-rules=no
   lwc-compiler=yes

   Run the substeps below only for tools reported yes; skip the rest.

2. ESLint (if eslint=yes) — run and fix all violations.

3. Prettier (if prettier=yes) — run for consistent formatting.

4. Cursor rules (if cursor-rules=yes) — apply every rule the project ships.

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