experience-lwc-design-generate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Creating LWC Components from Design

从设计创建LWC组件

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.

编排从设计输入（Figma、PRD、Aura源码或用户描述）到全新Lightning Web Component创建的端到端流程。这是顶层工作流技能——它会按顺序调用负责每个阶段的专业子技能。与组织相关的数据（LDS架构自省、设计框架检查）会通过转交至

experience-lds-data-requirements-generate

或用户提供的设计工具URL来解析。

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

从Figma框架、PRD或书面规范构建全新LWC。
将Aura组件迁移为全新构建的LWC（Aura→LWC原地移植不在此技能范围内）。
创建需求仍部分隐含、需要先提炼为PRD再编码的组件。

请勿在以下场景使用此技能：

重构现有LWC（请使用
```
experience-lwc-generate
```
）。
Aura→LWC原地迁移（不在此技能范围内）。
纯样式或数据层工作（直接使用专业技能）。

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.

至少一个设计输入：Figma URL、PRD markdown、Aura组件源码或文本规范。
新LWC的目标路径（模块文件夹）。
对于数据支持的组件：需能访问组织，以便
```
experience-lds-data-requirements-generate
```
和
```
experience-lds-best-practices-apply
```
解析架构和适配器形态。

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.

references/prd-analysis-template.md — PRD章节框架（生成PRD时直接复制使用）。
references/figma-to-prd-blueprint.md — 将Figma框架转换为PRD章节的专属指南（包含componentName/tagName、内容需求、数据需求、交互、组件通信、状态、可访问性/响应式/样式/本地化/安全）。当输入为Figma设计时，在第1.2阶段前阅读此指南。

Workflow (mandatory five phases)

工作流（强制五阶段）

Phase 1 — Gather PRD & requirements

阶段1 — 收集PRD与需求

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

**目标：**生成一份供后续所有阶段使用的整合版PRD。

获取原始需求 — 收集PRD、设计规范、Figma URL、Aura源码或用户文本。
Figma → PRD（如适用）：遵循references/figma-to-prd-blueprint.md完成完整的Figma框架分析和PRD章节编写。需要用户提供的信息：Figma URL、目标框架截图，以及（若开启Dev Mode）节点的元数据导出。使用指南中的逐章节说明，将内容转换为references/prd-analysis-template.md中的PRD框架。
Aura → PRD（如迁移）：列举Aura组件必须保留的功能——标记、控制器/助手动作、事件、属性和绑定数据，并将这些清单作为明确需求纳入PRD。（原地Aura→LWC移植不在此范围内；此步骤仅为全新构建捕获行为。）
数据需求（如组件需读写数据）：转交至
```
experience-lds-data-requirements-generate
```
。该技能会生成经过验证的数据规范（对象/字段API名称、推荐的LDS API、实现方案）。将其输出直接粘贴到PRD中。
适配器探索：转交至
```
experience-lds-best-practices-apply
```
获取适配器选择规则（UI API vs GraphQL vs Apex）及所选方案的推荐绑定方式。
命名规则：
```
componentName
```
必须采用驼峰式命名（如
```
productCard
```
），
```
tagName
```
必须为其短横线分隔形式（如
```
product-card
```
）。使用捆绑脚本验证，请勿手动检查：
bash
```
"<skill_dir>/scripts/check-component-name.sh" <componentName> <tagName>
```
若名称格式错误，或
```
componentName
```
的短横线形式与
```
tagName
```
不匹配，脚本会返回非零值（并输出可操作的stderr信息）。

**交付物：**一份涵盖用途、内容、数据、交互、状态、可访问性、响应式、样式方向、本地化和安全性的全面PRD。将其存入工作区（如

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

）。

Phase 2 — Generate component code

阶段2 — 生成组件代码

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.

**目标：**生成严格遵循PRD的初始

.html

、

.js

、

.css

、

.js-meta.xml

文件。

将PRD内容作为规范转交至
```
experience-lwc-generate
```
。该技能负责PRD→代码的转换（事件、getter、
```
@api
```
、
```
.js-meta.xml
```
、AI元数据），是代码创作的权威来源。
使用
```
design-systems-slds-apply
```
中的SLDS决策层级：
1. 优先使用匹配的Lightning基础组件（
```
experience-lwc-base-components-integrate
```
  ）。
2. 否则选择SLDS蓝图或工具类（遵循
```
design-systems-slds-apply
```
  ）。
3. 否则使用SLDS样式钩子编写自定义CSS（同样在
```
design-systems-slds-apply
```
  中覆盖）。
在继续之前，通过
```
experience-lwc-generate
```
的检查清单确认创作基线。
将PRD中的每个数据需求转换为绑定适配器（UIAPI / GraphQL）或明确的TODO。
严格遵循PRD：
- 仅包含PRD描述的功能和行为。
- 对不确定区域标记
```
// TODO:
```
  注释，并引用PRD中引发歧义的内容。
- 添加详细的代码注释说明意图。
- 不要将组件拆分为超出PRD隐含范围的更多子组件。

**交付物：**目标路径中的第一版LWC包。

Phase 3 — Optimize component

阶段3 — 优化组件

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.

**目标：**应用性能、可维护性和最佳实践修复。

在任何其他审查前，完成以下优化检查清单：
- 单一职责、封装性、可复用性。
- 最小化DOM操作；通过属性批量更新。
- 审核事件处理器和生命周期钩子的使用（
```
renderedCallback
```
  防护）。
- 考虑对重型子组件进行懒加载。
转交至
```
experience-lwc-generate
```
进行LWC最佳实践审查（反模式、响应式、组合）。
转交至合规套件进行预发布审查——
```
experience-lwc-accessibility-validate
```
（可访问性）、
```
experience-lwc-security-validate
```
（LWS + 产品安全）和
```
experience-lwc-rtl-validate
```
（RTL国际化）。同时运行这三项以完成全面质量检查。
若组件涉及数据，转交至
```
experience-lds-best-practices-apply
```
进行缓存/一致性和引用完整性检查。
应用所有被接受的整改建议。以PRD为权威来源——请勿以优化为借口增加范围。

Phase 4 — Lint, format, compile-check

阶段4 — 代码检查、格式化、编译验证

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.

前提：仅运行项目中已配置工具对应的步骤。

检测项目工具 — 从项目根目录调用捆绑的检测脚本，读取其
```
<tool>=yes|no
```
输出行。请勿手动查看
```
package.json
```
/点文件：
bash
```
"<skill_dir>/scripts/detect-project-tools.sh" <projectRoot>
```
示例输出：
text
```
eslint=yes
prettier=yes
cursor-rules=no
lwc-compiler=yes
```
仅对输出为
```
yes
```
的工具执行以下子步骤；跳过其他工具。
ESLint（若
```
eslint=yes
```
）——运行并修复所有违规项。
Prettier（若
```
prettier=yes
```
）——运行为代码提供一致的格式。
Cursor规则（若
```
cursor-rules=yes
```
）——应用项目提供的所有规则。
LWC编译器（若
```
lwc-compiler=yes
```
）——通过本地开发服务器或SFDX运行；解决所有语法/模板错误后再继续。

**交付物：**经过清理和验证的组件代码。

Phase 5 — Create tests

阶段5 — 创建测试

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.

转交至

experience-lwc-accessibility-jest-run

生成自动化可访问性Jest覆盖率；同时遵循

experience-lwc-generate

的测试指南添加通用Jest覆盖率，若团队要求则生成UTAM页面对象。

**交付物：**带有通过测试套件的LWC包，测试覆盖率达到或超过项目阈值。

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

只有当以下每一项都满足时，通过此工作流构建的新组件才视为“完成”。将此作为标准就绪检查清单——复制到PR描述中，以便评审人员确认每一项。

代码完成 — 无实现缺口：

每个PRD需求要么已实现，要么明确标注
```
TODO:
```
并关联跟踪项。无隐性缺口。

生产代码路径中无

TODO

、

FIXME

或

console.log

console.table

alert()

。

无注释掉的代码块、无空函数体、无占位值、无模拟数据、无未引用的导入。
若无注释说明为何未使用原生LWC模式，则不得存在
```
lwc:dom="manual"
```
区域或第三方库逃逸舱口。

合规性与质量：

```
.js-meta.xml
```
中的AI元数据通过
```
experience-lwc-generate
```
的审核（设置了组件级
```
<ai><description>
```
，且每个通过
```
<targetConfig>
```
暴露的
```
@api
```
成员都有
```
<ai><property name="…" aiDescription="…"/></ai>
```
条目；无营销语言）。
SLDS样式通过
```
design-systems-slds-apply
```
验证——无原始十六进制/像素值，仅使用样式钩子和SLDS工具类。
完成可访问性检查：
```
experience-lwc-accessibility-validate
```
源码审查 +
```
experience-lwc-accessibility-jest-run
```
自动化测试，两者均通过。

完成安全+RTL检查：

experience-lwc-security-validate

experience-lwc-rtl-validate

，两者均通过。

数据 + 测试：

数据层已参照LDS适配器验证（每个绑定/命令式调用都在PRD的数据部分记录，并与
```
experience-lds-best-practices-apply
```
或
```
experience-lds-data-requirements-generate
```
提供的适配器之一匹配）。
Jest测试通过，达到项目要求的覆盖率水平。新测试覆盖所有
```
@api
```
接口、所有派发的事件以及所有错误路径（绑定失败、Apex失败、验证拒绝）。
为任何需要跨组件浏览器级测试的UI流程生成UTAM页面对象（无需则跳过）。

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.

此工作流调用的技能（按阶段顺序）：
- ```
experience-lds-data-requirements-generate
```
  — 阶段1.4数据规范（以及与
```
experience-lds-best-practices-apply
```
  协作的阶段1.5适配器探索）。
- ```
design-systems-slds-apply
```
  、
```
experience-lwc-base-components-integrate
```
  — 阶段2样式决策。
- ```
experience-lwc-generate
```
  — 阶段2创作基线 + 阶段3最佳实践审查 + 阶段5AI元数据审核。
- ```
experience-lds-best-practices-apply
```
  — 阶段2/3数据层适配器选择和一致性审查。
- ```
experience-lwc-accessibility-validate
```
  、
```
experience-lwc-security-validate
```
  、
```
experience-lwc-rtl-validate
```
  — 阶段3可访问性/安全/RTL审查。
- ```
experience-lwc-accessibility-jest-run
```
  — 阶段5自动化可访问性测试生成。
- 可选：组件稳定后单独添加可观测性 instrumentation。
- ```
experience-lwc-typescript-migrate
```
  — JS代码通过后可选执行。
- 当新组件通过功能旗标发布时，在推出过程中使用功能旗标管控。
- ```
experience-lwc-api-docs-generate
```
  — 公共API接口稳定后执行。
此工作流使用的组织相关输入：
- Figma URL + 截图（以及若可用，开发者的Dev Mode元数据导出） — 阶段1.2 Figma输入。
- ```
experience-lds-data-requirements-generate
```
  负责阶段1中组件需要组织支持数据时的组织架构自省和数据规范验证——转交至该技能，而非在此重复其工作。

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 }));
    }
}

阶段1 PRD框架（从Figma/PRD/Aura输入填充）

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

阶段2框架

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.

每个PRD章节都可追溯到至少一段代码或明确的TODO。
已按顺序执行阶段1–5；无步骤被跳过。
可访问性、SLDS、数据层和AI元数据审查均通过。
覆盖率达到或超过项目阈值。
组件在
```
experience-lwc-runtime-observe
```
中按PRD枚举的响应式断点正确渲染。