afv-library/skills/experience-lds-data-requirements-generate/SKILL.md

name	description	metadata
experience-lds-data-requirements-generate	Use when a Lightning Web Component data need is described in ambiguous natural language — turn "get contact info" or "show account data" into a clear, PRD-ready data-requirements spec. TRIGGER when the user says "define data requirements for this LWC", "turn this PRD data section into validated object/field names", "recommend GraphQL vs UIAPI for this data need", "validate these Salesforce API names", or "spec out the LDS adapter for this component", or references LWC bundle files (`.js`, `.js-meta.xml`) whose data layer is not yet specified. DO NOT TRIGGER when the data layer is already fully specified, when authoring the actual query or adapter code from a known spec, or when implementing an LWC end-to-end (use experience-lwc-generate).	version relatedSkills 1.0 experience-lwc-generate

Generating LDS Data Requirements

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.

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

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

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.

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)

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

Open every conversation with:

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

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

1. Operation type — Is it read, create, update, or delete? Ambiguous verbs trigger an immediate clarifying question. Confirm with: "I've identified this as a operation. Is this correct?"
2. 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).
3. Field specification — Map generic references (phone, address, name, status) to specific API names. If multiple candidates exist, enumerate them and ask.
4. Scope and context — One record vs. many; user-triggered vs. auto; expected volume; real-time vs. on-demand.

End-of-step gate. Consolidate into:

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

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

Step 2 — Validate Salesforce API names (Precision Mode)

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 →