mcpField
M
mobile-platform-offline-validate

mobile-platform-offline-validate

github.com/forcedotcomテスト・品質1.1k4.7k 回インストール1 日前に更新
リポジトリ

mobile-platform-offline-validate について

モバイルオフライン対応の Salesforce LWC を監査するエージェント向けスキルです。Komaci のテンプレートと JavaScript の規則を確認し、コード修正案付きの指摘をまとめます。

主な機能

  1. 01lwc:if の条件レンダリングを確認
  2. 02@wire 内のインライン GraphQL を確認
  3. 03Komaci ESLint 分析を実行
  4. 04規則と位置ごとに指摘を報告

活用シーン

  1. 01オフライン公開前の LWC 監査
  2. 02オフラインプライミング失敗の調査
  3. 03互換性のあるテンプレート条件への書き換え
  4. 04分析結果に基づくコンポーネント修正

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/forcedotcom/sf-skills --skill mobile-platform-offline-validate

インストール後、Claude Code で/mobile-platform-offline-validateを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
grounding.md
inline-graphql.md
komaci-eslint.md
lwc-if.md
scripts/
komaci.config.mjs
package.json
run-komaci.sh

詳細

LWC モバイルオフラインのレビュー

Lightning Web Component に対して、構造化されたオフラインプライミング適合性チェックを実行し、見つかった問題と、Salesforce Mobile App Plus および Field Service Mobile App の Komaci 静的解析要件にコンポーネントを適合させるためのコードレベルの修正をレポートにまとめます。

使用するタイミング

  • 特定の LWC について、「モバイルオフラインレビュー」「Komaci チェック」「オフラインプライミング監査」を依頼された場合。
  • Salesforce Mobile App Plus または Field Service Mobile App のオフラインモードでリリースするコンポーネントを準備する場合。
  • オフラインアナライザーが報告したプライミングの失敗を調査する場合。

次の用途にはこのスキルを使用しないでください。

  • ネイティブモバイル機能(バーコードスキャナー、生体認証、位置情報など)を使用する LWC の構築 — mobile-platform-native-capabilities-integrate を使用してください。
  • 一般的な LWC コードレビュー — 該当するドメインスキル(reviewing-lws-security、reviewing-lwc-rtl、accessibility-code-review)を使用してください。

前提条件

  • コンポーネントのパス(modules/… 配下の LWC バンドル)。
  • コンポーネントの JS/TS と HTML テンプレートへのアクセス。
  • ローカルの Node と npm、および @salesforce/eslint-plugin-lwc-graph-analyzer プラグインを使って npx eslint を実行できること。

ナレッジベース

モバイルオフラインの基礎知識では、違反の 3 つのカテゴリと、それぞれがオフラインプライミングを妨げる理由を説明しています。判断を下す前に読んでください。各レビュアーの参考資料は、ルールと修正方法の正式な情報源です。

ワークフロー

ステップ 1 — レビュー対象の範囲を確認する

コンポーネントバンドルを特定します:.html、.js/.ts。CSS とメタファイルはオフラインプライミングの対象外です。バンドルに複数の HTML テンプレートがある場合は、すべてレビューします。

ステップ 2 — 基礎知識と各レビュアーの参考資料を読む

判断を下す前に、モバイルオフラインの基礎知識と、各レビュアーの 3 つの参考資料を最後まで読んでください。レポートの監査可能性を確保するため、指摘ごとに該当するレビュアーを明記してください。

ステップ 3 — lwc:if/lwc:elseif/lwc:else(HTML)

バンドル内のすべての .html ファイルを調べ、lwc:if レビュアーのルールを適用します。lwc:if={…}、lwc:elseif={…}、lwc:else が出現するたびに、lwc:elseif と lwc:else のセマンティクスを維持するために必要なネストも含め、正確な if:true/if:false への書き換えを指摘事項として記載します。

ステップ 4 — @wire 内のインライン GraphQL(JS)

バンドル内のすべての .js/.ts ファイルを調べ、インライン GraphQL レビュアーのルールを適用します。gql テンプレートリテラルを直接(またはトップレベル定数を介して)参照する @wire ごとに、具体的な getter を示し、書き換え後の @wire 設定を記載した指摘事項を作成します。

ステップ 5 — Komaci ESLint チェック(JS)

同梱スクリプトを使用して、バンドルの JS ファイルに対して Komaci ESLint アナライザーを実行します。このスクリプトは、bundleAnalyzer プロセッサを有効にして、@salesforce/eslint-plugin-lwc-graph-analyzer の推奨ルールセットを適用します。

scripts/run-komaci.sh path/to/component.js

このスクリプトを実行するには、作業ディレクトリから @salesforce/eslint-plugin-lwc-graph-analyzer を解決できる必要があります。また、コンポーネントに付随する HTML テンプレートは JS ファイルと同じ場所に置いてください(プラグインの bundleAnalyzer プロセッサは、これらを使ってオフラインデータグラフを解決します)。出力は stdout の ESLint --format json です。

出力の各 messages[*] エントリを ruleId ごとにグループ化し、Komaci ESLint レビュアーでルールごとの修正方法を確認します。各(ルール、行)の組み合わせについて、参考資料に記載された修正内容をそのまま使って指摘事項を作成してください。新たな助言を考案してはいけません。実行環境でスクリプトを利用できない場合に備え、npx eslint ... を手動で実行する方法については参考資料を確認してください。

Step 6 — レポートを作成する

次の形式でレポートを出力します。

## Mobile Offline (Komaci priming)
- <reviewer> — <file>:<startLine>:<startColumn>-<endLine>:<endColumn> — <type>
  Description: <verbatim from the reviewer reference>
  Intent analysis: <verbatim from the reviewer reference>
  Suggested action: <verbatim from the reviewer reference>
  Code: |
    <source snippet from startLine through endLine, optional but
     recommended when the violation spans multiple lines>
  Applied: yes/no

## Summary
- <n> issues found; <m> fixed; <k> deferred (with reason)

Komaci ESLint の指摘では、ESLint メッセージの line/column/endLine/endColumn から startLine/startColumn/endLine/endColumn を取得します。 Inline GraphQL と lwc:if の指摘では、ソースで確認した行/列の範囲を指定します。指摘に endLine/endColumn がない場合は、<file>:<startLine> にフォールバックし、末尾の範囲を省略します。

すべての指摘に、レビュー担当者(Inline GraphQL/lwc:if/Komaci ESLint のルール ID)を記載します。

Step 7 — 修正を適用する

ユーザーが修正を依頼した場合は、修正を直接適用します。修正内容がオフライン以外でのコンポーネントの動作と競合する場合(たとえば、開発者が読みやすさのために lwc:elseif を使用していて、ユーザーがまだモバイルオフライン向けにリリースしていない場合)は、黙って書き換えるのではなく、保留リストにその競合を記載します。

検証チェックリスト

  • lwc:if/lwc:elseif/lwc:else をすべて確認し、指摘の有無を記載している。
  • gql を参照する @wire をすべて確認し、インラインクエリをゲッターに抽出している。
  • Komaci ESLint アナライザーを実際に実行し、実在するルール ID を指摘に記載している。架空のルール ID は使用していない。
  • 各指摘に、該当するレビュー担当者またはルール ID を記載している。
  • 上記の3つのカテゴリ以外の修正を行っていない(ほかの懸念事項は別のスキルで扱う)。

トラブルシューティング

  • npx eslint でプラグインが見つからない — ワークスペースに @salesforce/eslint-plugin-lwc-graph-analyzer をインストールするか、固定したローカルインストールパスを使用します。このプラグインは、Komaci ルールの正規の提供元です。
  • bundleAnalyzer 関連のエラー — 推奨設定ではバンドルプロセッサーが使用されます。これを削除しないでください。プロセッサーが同階層の HTML ファイルを検出できることを前提としています。簡略化した JS ファイルに対して実行する場合は、一致する HTML ファイルを一時ディレクトリに用意してください。
  • 失敗すると予想されるコンポーネントで指摘がない — 推奨ルールセットが適用されていることを確認してください(ルールが空の bundleAnalyzer だけではありません)。HTML を JS と同じ場所に用意する必要があるルールもあります。
  • 専用レビュー担当者の lwc:if に関する指摘と重複している — Komaci プラグインはテンプレートをチェックしません。lwc:if のチェックは HTML のみを対象とし、Step 3 で実施します。Step 5 の指摘は JS のみを対象とします。

コメント