experience-lds-data-requirements-generate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Generating LDS Data Requirements

生成LDS数据需求

Run a three-stage analyst workflow — requirements clarification, API name validation, API recommendation — so a downstream developer can implement a Lightning Data Service (LDS) solution without guessing.

执行三阶段分析师工作流——需求澄清、API名称验证、API推荐，让下游开发者无需猜测即可实现Lightning Data Service（LDS）解决方案。

When to Use

使用场景

A PRD, Figma comment, or user ask mentions Salesforce data but objects/fields/operations are vague ("show customer info", "update the record", "list upcoming gigs").
Before writing any
```
@wire
```
/Apex code for a new data need, or before handing the recommendation to a downstream implementation workflow.
You inherited TODOs like
```
// TODO: fetch related records
```
and need to turn them into precise specs.

Do NOT use this skill when:

The data need is already fully specified (object API name, field API names, operation type, scope).
The component does not touch Salesforce data at all (UI-only, external REST, local state).

PRD、Figma评论或用户需求提到Salesforce数据，但对象/字段/操作模糊（如“展示客户信息”、“更新记录”、“列出即将到来的活动”）。
为新的数据需求编写任何
```
@wire
```
/Apex代码之前，或在将推荐方案交给下游实现工作流之前。
接手了类似
```
// TODO: 获取关联记录
```
的待办事项，需要将其转化为精确规范。

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

数据需求已完全明确（包含对象API名称、字段API名称、操作类型、范围）。
组件完全不涉及Salesforce数据（仅UI、外部REST接口、本地状态）。

Prerequisites

前置条件

The natural-language requirement (PRD snippet, user ask, or TODO comment).
Access to the target org's Setup → Object Manager for confirming custom object/field API names.
Awareness of the current GraphQL / UI API / Apex priority order (top-of-funnel is GraphQL when it can serve the read).

自然语言描述的需求（PRD片段、用户需求或待办注释）。
有权访问目标组织的Setup → Object Manager，用于确认自定义对象/字段的API名称。
了解当前GraphQL / UI API / Apex的优先级顺序（当GraphQL可满足读取需求时，优先选择）。

Knowledge Bases

知识库

references/requirements-analysis.md — Requirements Analysis Mode framework.
references/api-name-validation.md — Precision Mode for object/field API names.
references/api-recommendation.md — GraphQL → UI API → Apex decision framework.
references/lds-expert.md — overall LDS patterns and pitfalls.
references/lds-data-consistency.md — cache and consistency guarantees.
references/lds-referential-integrity.md — parent/child and related-record rules.

references/requirements-analysis.md — 需求分析模式框架。
references/api-name-validation.md — 对象/字段API名称的精确验证模式。
references/api-recommendation.md — GraphQL → UI API → Apex决策框架。
references/lds-expert.md — LDS整体模式与常见陷阱。
references/lds-data-consistency.md — 缓存与一致性保障。
references/lds-referential-integrity.md — 父/子记录及关联记录规则。

Workflow

工作流

Run the three steps strictly in order. Do not skip a step unless the caller has already confirmed its output.

严格按顺序执行三个步骤。除非调用者已确认某一步的输出，否则请勿跳过。

Step 1 — Parse data requirement (Requirements Analysis Mode)

步骤1 — 解析数据需求（需求分析模式）

Goal: extract everything you know and surface every uncertainty before moving on.

Open every conversation with:

"I've analyzed your data requirement: '<REQ>'. Here's what I understand and what I need clarification on…"

Apply the four actions from references/requirements-analysis.md:

Operation type — Is it read, create, update, or delete? Ambiguous verbs trigger an immediate clarifying question. Confirm with: "I've identified this as a <OP> operation. Is this correct?"
Data entity identification — Standard object (high confidence, proceed), suspected custom object (ask: "Is this a custom object
<Term>__c
? What's the exact API name?"), or unknown (ask for the API name from Object Manager).
Field specification — Map generic references (
```
phone
```
,
```
address
```
,
```
name
```
,
```
status
```
) to specific API names. If multiple candidates exist, enumerate them and ask.
Scope and context — One record vs. many; user-triggered vs. auto; expected volume; real-time vs. on-demand.

End-of-step gate. Consolidate into:

text

Clear Requirements: [confirmed facts]
Need Clarification: [numbered questions from 1.1–1.4]

Proceed only when every question is answered with ≥90% confidence.

目标： 在推进前提取所有已知信息，并列出所有不确定点。

每次对话以以下内容开头：

“我已分析你的数据需求：'<REQ>'。以下是我的理解以及需要澄清的内容……”

应用references/requirements-analysis.md中的四个操作：

操作类型 — 是读取、创建、更新还是删除？模糊动词需立即提出澄清问题。确认话术：*“我判断这是**<OP>*操作。是否正确？”
数据实体识别 — 标准对象（高可信度，继续推进）、疑似自定义对象（询问：“这是自定义对象
<Term>__c
吗？确切的API名称是什么？”），或未知对象（要求从Object Manager获取API名称）。
字段规范 — 将通用引用（
```
phone
```
、
```
address
```
、
```
name
```
、
```
status
```
）映射到具体API名称。如果存在多个候选选项，列出所有选项并询问。
范围与上下文 — 单条记录还是多条；用户触发还是自动触发；预期数据量；实时还是按需获取。

步骤结束 gate。整理为：

text

明确需求：[已确认事实]
待澄清内容：[1.1–1.4的编号问题]

仅当所有问题都得到≥90%可信度的回答后，才可继续推进。

Step 2 — Validate Salesforce API names (Precision Mode)

步骤2 — 验证Salesforce API名称（精确模式）

Goal: 100% accuracy on every object and field API name before code is written.

Apply the validation framework from references/api-name-validation.md:

Standard objects —

Account

Contact

Lead

Opportunity

Case

User

Task

Event

Product2

Pricebook2

Order

OrderItem

Asset

Contract

Campaign

pass immediately. Anything else triggers verification.

Custom objects — Never assume
```
__c
```
suffixes. Ask: "Is this
<Term>__c
or a different custom object API name?" Point users to Setup → Object Manager → <Object> → Details → API Name.
Standard fields — Map ambiguous references using the tables in the reference file.
Custom fields — Require
```
__c
```
suffix confirmation; case-sensitive.

Confirmation template:

text

Object API Name: <OBJECT>
Field API Names: <FIELD_LIST>
Confidence Level: 100% validated

If any uncertainty remains, stop. Emit the outstanding verification requests and the Setup navigation instructions. Do not advance to Step 3 or generate code.

Skip this step only when the caller has explicitly stated that API names are already validated upstream, or the requirement does not involve records at all. Record the skip reason in the Step 4 output.

目标： 在编写代码前，确保每个对象和字段的API名称100%准确。

应用references/api-name-validation.md中的验证框架：

标准对象 —
```
Account
```
、
```
Contact
```
、
```
Lead
```
、
```
Opportunity
```
、
```
Case
```
、
```
User
```
、
```
Task
```
、
```
Event
```
、
```
Product2
```
、
```
Pricebook2
```
、
```
Order
```
、
```
OrderItem
```
、
```
Asset
```
、
```
Contract
```
、
```
Campaign
```
可直接通过验证。其他对象需触发验证。
自定义对象 — 切勿默认假设
```
__c
```
后缀。询问：*“这是
```
<Term>__c
```
还是其他自定义对象API名称？”*引导用户前往Setup → Object Manager → <对象> → Details → API Name查看。
标准字段 — 使用参考文件中的表格映射模糊引用。
自定义字段 — 要求确认
```
__c
```
后缀；区分大小写。

确认模板：

text

对象API名称：<OBJECT>
字段API名称：<FIELD_LIST>
可信度：100%已验证

如果仍存在任何不确定性，停止推进。列出待验证的内容以及Setup导航指引。请勿进入步骤3或生成代码。

仅当调用者明确说明API名称已在上游完成验证，或需求完全不涉及记录时，才可跳过此步骤。在步骤4的输出中记录跳过原因。

Step 3 — Recommend the API (Solution Architecture Mode)

步骤3 — 推荐API（解决方案架构模式）

Goal: pick the right data access API using the decision framework in references/api-recommendation.md.

Priority order (non-negotiable):

GraphQL wire adapter (
```
lightning/graphql
```
) — top choice for reads it can serve.
UI API / LDS — CRUD writes, metadata, layouts, picklists, simple reads.
Apex — fallback only.

Walk the six decision sub-steps:

Operation type (read / write / mixed).
Object & field support in UI API.
Relationship complexity (single vs. multi-object, parent/child).
Query complexity (filtering, sorting, pagination, aggregation).
Performance & scalability (round trips, payload size).
Specialized needs (metadata, atomic transactions, business logic, elevated permissions).

Recommendation rules:

GraphQL when read-only on supported objects; multi-object joins; pagination/sort/filter; aggregation; minimizing round trips.
UI API when CRUD writes, metadata (picklists, layouts, object info),
```
getRecordCreateDefaults
```
+
```
createRecord
```
, list views.
Apex when UI API doesn't support the object/field; multi-record atomic transactions; custom business logic; system-context permissions.

Present with the "Show Your Work" template — explicitly explain why not GraphQL / why not UI API / why not Apex.

Hand-off:

GraphQL recommended → document the query shape (root object, requested fields, filters) in the Step 4 output; downstream authoring of the actual
```
lightning/graphql
```
wire adapter is the caller's next step.
UI API recommended → document the specific UI API adapter (
```
getRecord
```
,
```
getRelatedListRecords
```
,
```
createRecord
```
,
```
updateRecord
```
,
```
getRecordCreateDefaults
```
, etc.) and any layout/picklist prerequisites.
Apex recommended → document the reason in the Step 4 output and hand off to the project's Apex workflow of record.

目标： 使用references/api-recommendation.md中的决策框架选择合适的数据访问API。

优先级顺序（不可协商）：

GraphQL wire适配器（
```
lightning/graphql
```
）—— 可满足读取需求时的首选。
UI API / LDS — CRUD写入、元数据、布局、选择列表、简单读取。
Apex — 仅作为备选方案。

执行六个决策子步骤：

操作类型（读取/写入/混合）。
UI API对对象和字段的支持情况。
关系复杂度（单对象 vs 多对象、父/子关系）。
查询复杂度（过滤、排序、分页、聚合）。
性能与可扩展性（请求往返次数、负载大小）。
特殊需求（元数据、原子事务、业务逻辑、提升权限）。

推荐规则：

GraphQL：仅读取操作、支持的对象、多对象关联、分页/排序/过滤、聚合、减少请求往返次数时使用。
UI API：CRUD写入、元数据（选择列表、布局、对象信息）、
```
getRecordCreateDefaults
```
+
```
createRecord
```
、列表视图时使用。
Apex：UI API不支持该对象/字段、多记录原子事务、自定义业务逻辑、系统上下文权限时使用。

使用“展示决策过程”模板呈现结果——明确解释为何不选GraphQL / 为何不选UI API / 为何不选Apex。

交接：

推荐GraphQL → 在步骤4的输出中记录查询结构（根对象、请求字段、过滤器）；调用者的下一步是编写实际的
```
lightning/graphql
```
wire适配器。
推荐UI API → 在步骤4的输出中记录具体的UI API适配器（
```
getRecord
```
、
```
getRelatedListRecords
```
、
```
createRecord
```
、
```
updateRecord
```
、
```
getRecordCreateDefaults
```
等）以及任何布局/选择列表前置条件。
推荐Apex → 在步骤4的输出中记录原因，并移交至项目的Apex工作流。

Step 4 — Emit the PRD-ready specification

步骤4 — 生成可直接用于PRD的规范

Produce a single block the caller can paste into a PRD or component file header:

text

undefined

生成一个可直接粘贴到PRD或组件文件头部的区块：

text

undefined

Data Requirement: <CLEAR_TITLE>

数据需求：<清晰标题>

Technical Specification

技术规范

Primary Object: <OBJECT_API_NAME>
Required Fields: <FIELD_API_NAMES>
Relationships: <RELATED_OBJECTS_OR_LOOKUPS_OR_NONE>
Data Scope: <SINGLE_RECORD | MULTIPLE_RECORDS | QUERY_BASED>
Access Pattern: <READ_ONLY | READ_WRITE | WRITE_ONLY>
Trigger: <USER_ACTION | AUTO_ON_LOAD | REACTIVE>

主对象：<OBJECT_API_NAME>
必填字段：<FIELD_API_NAMES>
关联关系：<关联对象/查找关系/无>
数据范围：<单条记录 | 多条记录 | 基于查询>
访问模式：<仅读取 | 读写 | 仅写入>
触发方式：<用户操作 | 加载时自动触发 | 响应式>

Implementation Details

实现细节

Recommended LDS API: <GRAPHQL | UI_API | APEX>
Implementation Pattern: <WIRE | IMPERATIVE>
Rationale: <WHY THIS API, NOT THE OTHERS>
Next step: <author the GraphQL wire adapter | author the UI API adapter call | project's Apex workflow>

undefined

推荐LDS API：<GRAPHQL | UI_API | APEX>
实现模式：<WIRE | 命令式>
理由：<为何选择该API而非其他>
下一步：<编写GraphQL wire适配器 | 编写UI API适配器调用 | 项目Apex工作流>

undefined

Few-Shot Patterns

示例模式

Vague ask	Clarifying question
"get contact info"	"Which `Contact` fields specifically? ( `Email` , `Phone` , `MailingAddress` , `Department` , …)"
"show account data"	"Which `Account` fields do you need? And are we showing one record or a list?"
"custom gym records"	"Is this a custom object `Gym__c` ? What specific fields are you looking for?"
"update the record"	"Which object? Which fields? Which record (ID at runtime)?"
"all customer information"	" `Account` or `Contact` ? Which fields? Single record or query?"

模糊需求	澄清问题
"获取联系人信息"	"具体需要 `Contact` 的哪些字段？（ `Email` 、 `Phone` 、 `MailingAddress` 、 `Department` ……）"
"展示客户数据"	"你需要 `Account` 的哪些字段？是展示单条记录还是列表？"
"自定义健身房记录"	"这是自定义对象 `Gym__c` 吗？你需要哪些具体字段？"
"更新记录"	"哪个对象？哪些字段？哪条记录（运行时ID）？"
"所有客户信息"	"是 `Account` 还是 `Contact` ？哪些字段？单条记录还是查询？"

Verification Checklist

验证清单

Every ambiguous term from the original requirement resolved to a confirmed API name.
Operation type confirmed (R / C / U / D).
Scope (single vs. many) and trigger (user vs. auto) documented.
API recommendation justified against all three options (GraphQL / UI API / Apex).
Concrete next action named — either the specific downstream adapter to wire (
```
lightning/graphql
```
,
```
getRecord
```
,
```
createRecord
```
, etc.) or the project's Apex workflow of record.
If Step 2 was skipped, the reason is recorded in the output.
Specification block copy-pasteable into the PRD.

原始需求中的每个模糊术语都已解析为已确认的API名称。
操作类型已确认（读取/创建/更新/删除）。
范围（单条 vs 多条）和触发方式（用户 vs 自动）已记录。
API推荐已针对三个选项（GraphQL / UI API / Apex）给出理由。
已明确具体的下一步操作——要么是具体的下游适配器编写（
```
lightning/graphql
```
、
```
getRecord
```
、
```
createRecord
```
等），要么是项目的Apex工作流。
如果跳过了步骤2，输出中已记录原因。
规范区块可直接复制粘贴到PRD中。

Cross-References

交叉引用

Skills:
- Output is consumed by
```
experience-lwc-generate
```
  when wiring
```
@wire
```
  adapters into a component.
Downstream authoring steps (not skill-bound today):
- GraphQL path — the caller writes the
```
lightning/graphql
```
  wire adapter using the schema pulled from the target org.
- UI API path — the caller wires the recommended UI API adapter (
```
getRecord
```
  ,
```
createRecord
```
  , etc.).

技能：
- 输出内容会被
```
experience-lwc-generate
```
  用于将
```
@wire
```
  适配器集成到组件中。
下游编写步骤（当前不属于技能范畴）：
- GraphQL路径——调用者使用从目标组织获取的schema编写
```
lightning/graphql
```
  wire适配器。
- UI API路径——调用者集成推荐的UI API适配器（
```
getRecord
```
  、
```
createRecord
```
  等）。