Migrate an LWC to a widget
Use the LWC to recover the
user's goal and data contract, then build the closest useful widget. A widget is its own declarative artifact.
authors it; a Lightning Type renderer may need separate wiring to make it reachable. This skill owns the comparison, handoff, integration check, and honest final status.
1. Decide whether to proceed
Read and apply
experience-lwc-widget-assess
to the component, its action output, and any existing Lightning Type/renderer. Preserve its verdict and the key findings from its report (blockers, contract change, lost interactions) in your report; do not write the assessment's own
or
files. Stop on
,
,
, or
. Proceed on
only when the intended change is explicit:
- For , preserve the current visible fields and actions.
- For , identify the exact bounded output fields or pre-shaped values required. A widget against a proposed contract is a draft until the action returns that contract; do not call it working.
- For with a viable adaptation, describe the replacement UX and each lost interaction. Call it a rebuild, not a faithful port.
2. Derive the generator handoff
Trace each value the proposed widget displays to the actual or proposed action output. Before authoring, verify the action contract rather than relying only on an assessment prompt's description. Pass
an ordered field shape (
,
,
), nested/list item fields, the intended tile role of each visible element, and supported terminal actions. Preserve render order and field paths. Use its discovery results for tile definitions and attributes, its documented formula catalog for expressions, and its instructions for schema types and bundle layout; do not maintain a second catalog here. A formula can cover supported scalar/date/regex operations, while collection restructuring may require pre-shaped output.
If an LWC fixture or action example contains sample data, it can help infer the shape; sample data is optional and is
not a documented generator input or a substitute for the action contract. Do not invent sample fields. For an action such as
, verify that the required context reaches the agent and that the agent has a way to perform the requested work. Do not assume a widget input form can submit collected values without a discovered, validated mechanism.
3. Generate and connect
Load
and follow its mandatory live
and
calls. If the
MCP or discovery is unavailable, stop before authoring a bundle; report the completed assessment and proposed field shape. The generator owns its three widget files and self-validation. Do not copy its UEM syntax or validation checklist into this skill.
For an Agentforce renderer migration, also establish the Lightning Type that receives the action output. A bundle alone is not connected to the action:
- Existing compatible Lightning Type: inspect its schema and current . After generation, read
platform-custom-lightning-type-generate/references/widget-rendition.md
platform-lightning-type-widget-coordinate
- No compatible Lightning Type: resolve the action's output class and a Lightning Type name from the project or the user's request. For the coordinator's supported Apex-backed route, use
platform-lightning-type-widget-coordinate
If the user requested a bundle only, report it explicitly as an unconnected bundle. Otherwise, completion requires both the bundle and renderer wiring.
4. Check the result
Use the generator's bundle self-validation. Then compare the result to the assessed candidate: every retained visible field has a binding to the real/proposed payload; list item paths and supported actions match; omitted behavior and contract changes are stated; and, for a renderer migration, the Lightning Type points to this widget with matching attributes. Static checks establish structure and mapping, not deployed runtime behavior. Report assessment, created paths, validation results, and one of:
,
,
draft pending IA contract
, or
, with the reason.