experience-lwc-widget-assess について
Lightning Web Component を宣言型ウィジェットで表現できるか評価するスキルです。現行動作の移植性と候補ウィジェットが目的を満たすかを別々に判定し、コードやデータの根拠を基に判定 JSON とレビュー報告を作成します。メタデータは生成しません。
主な機能
- 01LWC コードと子コンポーネントの確認
- 02描画・操作・データソースの評価
- 03コンポーネント発見結果に基づく適合性判定
- 04根拠を添えた阻害要因の記録
- 05判定 JSON と Markdown 報告の生成
活用シーン
- 01LWC のウィジェット移行可否の評価
- 02直接移植と再構築の区別
- 03データ契約や操作上の阻害要因の特定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ forcedotcom/ sf-skills --skill experience-lwc-widget-assessインストール後、Claude Code で/experience-lwc-widget-assessを入力して読み込まれたか確認します。
詳細
LWC とウィジェットの適合性を評価する
各 LWC について、次の 2 つの質問に答えてください。現在の動作を再現できますか? できない場合、実現可能なウィジェットでもユーザーの目的を達成できますか? 評価のみを行い、メタデータは作成しないでください。ウィジェットは Lightning Type とは別個の宣言型アーティファクトです。ウィジェットの本体は、検出されたタイル、バインディング、数式、サポート対象のアクションを使って、提供されたデータをレンダリングします。任意の LWC コードを実行したり、レンダリング後にデータを取得したり、リアクティブなクライアント状態を保持したりすることはできません。
根拠と判断
- コンポーネントの JS/TS、テンプレート、メタデータ、および関連する子コンポーネントを読みます。ユーザーの目標を 1 文で述べます。表示される各値の取得元をたどり、その目標に不可欠なインタラクションを特定します。
@apiプロパティは外部入力の証拠にはなりますが、呼び出し可能なアクションがその値を返す証拠にはなりません。アクションの出力に関するユーザーの明示的な説明は、実現可能性の評価における証拠となります。機能する移行が可能だと主張する前に、実際のアクション契約と Lightning Type/レンダラーの接続を確認します。 - レンダリングされる各要素とアクションの役割を、移行先のサーフェスに対応付けます。
platform-widget-generateは検出手順を示します。利用できるブロックと属性を確定するのは、実際のdiscoverUiComponentsの応答とgetUiComponentSchemasの結果です。変換が重要な場合に限り、そのreferences/widget-formulas.mdを読みます。固定のチャネルやタイル数を仮定せず、根拠に基づいて移行先チャネルを記録します。検出を行っていない場合、文書化されたパターンは暫定候補の根拠になりますが、例に記載がないことだけではブロックが利用できないとは判断できません。不確実性によって判定が左右される場合はreviewを使い、タイル、アクション、入力送信の仕組み、数式を決して捏造しないでください。 - 不適合が見つかった後も、すべての観点を確認します。レンダリングの語彙、保持される状態、命令型の副作用とアクション、データの出所、変換です。範囲を限定したスナップショットや整形済みコレクションは、呼び出し可能なアクションの出力に移せる場合があります。そのように主張する前に、アクションの実装を確認します。数式でスカラーの
MIN/MAX、日付、正規表現がサポートされていても、コレクションの並べ替えや集計ができるとは限りません。入力フォームには、現在のタイルで値を収集し、さらにその値をアクションに渡せるという両方の根拠が必要です。sendMessageだけでは、それを証明できません。 - 現在の LWC と提案するウィジェットは別々に評価します。エージェントが必要なコンテキストを使って実際に依頼された作業を行えるなら、リンクや
sendMessageで元のインタラクションを維持せずに意図を保てる場合があります。カルーセルは商品リストに置き換えられる場合がありますが、数量の選択が目的の注文作成機能では置き換えられない可能性があります。そのような変更は再構築として扱います。ウィジェット候補については、rendersAsWidgetの判定時に明示した提案用 IA 契約を考慮し、契約の変更内容を明記します。実現可能性または目的が未解決のままなら、無理に二択の判定をせずreviewを使います。
次の判定結果を使います。
| 判定結果 | 意味 |
|---|---|
asIsVerdict: port-declarative | 現在の表示動作とデータ契約を表現できます。 |
asIsVerdict: needs-IA-contract-change | 必要なのは、範囲を限定した出力変更または整形のみです。 |
asIsVerdict: not-portable | 現在の動作または表示要素に、検証済みの同等機能がありません。 |
asIsVerdict: review | 現在の適合性を根拠から確定できません。 |
asDisplayWidget.verdict: viable | 明示した契約変更または再構築の後も含め、検証済みの候補、または明確に特定された候補が目標を満たします。 |
asDisplayWidget.verdict: pointless | 表示はできますが、ユーザーの目標を損ないます。 |
asDisplayWidget.verdict: blocked | 提案する表示/アクションを表現できません。 |
asDisplayWidget.verdict: review | 機能、データの由来、または目的が未解決です。 |
レポートでは、ゲートと根拠を示してすべての重要な阻害要因を列挙し、ソースの場所または具体的な動作を引用します。ゲート名は role、rendering vocabulary、behavior/interactivity、data source、transformation です。最初に失敗した観点で確認を終えないでください。contractChange.shapeToAdd には、アクションが返すことを現実的に想定できるフィールドまたは整形済みの値だけを記載し、ペイロードを捏造しないでください。現在の LWC が not-portable でも、実現可能な適応に契約変更が必要な場合があります。提案するウィジェットで UX が変わる場合は、isRebuild: true を設定し、失われるインタラクションをレポートに記載します。不確実な結論は信頼度を低くし、解決に必要な情報を説明します。
出力
2 つの成果物を作成します。出力先が指定されている場合は、verdict.json と report.md として書き込みます。
判定 — experience-lwc-widget-migrate が判断のゲートとして使用する、機械可読な判定です。コンポーネントごとに JSON オブジェクトを 1 つ、フォルダーの場合は配列を作成します。次のフィールドだけを使用します。
{
"component": "caseDetailsPanel",
"role": "renderer",
"asIsVerdict": "port-declarative",
"contractChange": {"suggested": false, "shapeToAdd": []},
"asDisplayWidget": {"verdict": "viable", "rendersAsWidget": true, "stillServesPurpose": true, "isRebuild": false},
"needsHumanReview": false
}
role は renderer、input、interactive のいずれかです。stillServesPurpose はブール値または "unknown"、rendersAsWidget はブール値、または機能が未解決の場合は null です。viable の場合は、両方とも true です。pointless の場合は、描画が true、目的が false です。blocked の場合は、描画が false、目的が "unknown" です。review の場合は、未解決のフィールドを unknown/null のままにします。review 判定の場合、または目的が不明な場合は、needsHumanReview: true に設定します。ウィジェットに表示される値がアクションの出力にすでに含まれていない場合(たとえば、描画後に取得される場合)に限り、コントラクトの変更を提案します。ペイロードにすでに含まれるデータについては、LWC が not-portable である場合や、ウィジェットが再構築されたものである場合でも、コントラクトを変更する必要はありません。コントラクトの変更を提案する場合は、空でない shapeToAdd が必要です。needs-IA-contract-change には、そのような提案が必要です。port-declarative ではコントラクトの変更はありません。
レポート — 人によるレビュー用のドキュメントです。フォルダーの場合は、コンポーネントごとに 1 つのセクションを設けます。次の構成を使用します。
# <component>: <one-line conclusion>
**Verdict:** <asIsVerdict> → <asDisplayWidget.verdict> (rebuild or not) · **Confidence:** high | low · **Needs human review:** yes | no
## Why
The user's goal, what maps cleanly, and what decides the verdict.
## Blockers
Each material blocker: gate, signal, evidence. "None" for `port-declarative`.
## Suggested contract change
Each field to add and why it must move into the action output. Omit when none is suggested.
## What the widget keeps / drops
Kept actions and dropped or replaced interactions.
## Open questions
What would resolve any low-confidence conclusion.