sf-lwc
Lightning Web ComponentsをPICKLESメソドロジーと165点満点のスコアリングに基づいて作成・レビューします。LWCコンポーネントの作成・編集時、`lwc/**/*.js`・`.html`・`.css`・`.js-meta.xml`ファイルへの変更時、またはwireサービス・SLDS・Jest LWCテストに関する質問時にトリガーされます。ApexクラスはSF-Apexスキル、AuraコンポーネントやVisualforceには適用されません。
description の原文を見る
> Lightning Web Components with PICKLES methodology and 165-point scoring. TRIGGER when: user creates/edits LWC components, touches lwc/**/*.js, .html, .css, .js-meta.xml files, or asks about wire service, SLDS, or Jest LWC tests. DO NOT TRIGGER when: Apex classes (use sf-apex), Aura components, or Visualforce.
SKILL.md 本文
sf-lwc: Lightning Web Components開発
ユーザーがLightning Web Componentsを必要とする場合、このスキルを使用します: LWCバンドル、wireパターン、Apex/GraphQL統合、SLDS 2スタイリング、アクセシビリティ、パフォーマンス作業、またはJestユニットテスト。
このスキルがタスクを所有する場合
以下の作業に関連する場合、sf-lwcを使用します:
lwc/**/*.js、.html、.css、.js-meta.xml- コンポーネントのスキャフォルディングとバンドル設計
- wireサービス、Apex統合、GraphQL統合
- SLDS 2、ダークモード、アクセシビリティ作業
- LWCのJestユニットテスト
以下の場合は他へ委譲します:
- Apexコントローラまたはビジネスロジックを最初に記述している →
sf-apex - LWC画面コンポーネントではなくFlow XMLを構築している →
sf-flow - メタデータをデプロイしている →
sf-deploy
最初に収集すべき必須コンテキスト
以下を質問するか推測します:
- コンポーネントの目的とターゲットサーフェス
- データソース: LDS、Apex、GraphQL、LMS、またはApex経由の外部システム
- ユーザーがテストを必要とするかどうか
- コンポーネントがFlow、App Builder、Experience Cloud、またはダッシュボードコンテキストで実行される必要があるかどうか
- アクセシビリティとスタイリングの期待
推奨ワークフロー
1. 適切なアーキテクチャを選択する
PICKLESマインドセットを使用します:
- プロトタイプ (prototype)
- 適切なデータソースを統合 (integrate the right data source)
- コンポーネント境界を構成 (compose component boundaries)
- インタラクションモデルを定義 (define interaction model)
- プラットフォームライブラリを使用 (use platform libraries)
- 実行を最適化 (optimize execution)
- セキュリティを強制 (enforce security)
2. 適切なデータアクセスパターンを選択する
| 必要性 | デフォルトパターン |
|---|---|
| 単一レコードUI | LDS / getRecord |
| シンプルなCRUDフォーム | ベースレコードフォームコンポーネント |
| 複雑なサーバークエリ | Apex @AuraEnabled(cacheable=true) |
| 関連グラフデータ | GraphQL wireアダプタ |
| DOM間通信 | Lightning Message Service |
3. 有用な場合はアセットから開始する
以下の目的でアセットを提供:
- 基本的なコンポーネントバンドル
- データテーブル
- モーダルパターン
- Flow画面コンポーネント
- GraphQLコンポーネント
- LMSメッセージチャネル
- Jestテスト
- TypeScript対応コンポーネント
4. フロントエンド品質を検証する
確認項目:
- アクセシビリティ
- SLDS 2 / ダークモード対応
- イベントコントラクト
- パフォーマンス / 再レンダリングセーフティ
- 必要な場合のJestカバレッジ
5. サポートするバックエンドまたはデプロイ作業を引き継ぐ
以下を使用:
sf-apexコントローラ / サービスの場合sf-deployデプロイメントの場合sf-testingApexサイドテストループのみ、Jestではありません
高シグナルルール
- コントロールを再発明するよりもプラットフォームベースコンポーネントを優先する
- リードオンリーユースケースには
@wireを使用し、明示的なアクションとDMLパスには命令型呼び出しを使用する - アクセス不可能なカスタムUIを導入しない
- ハードコードされた色を避ける; SLDS 2互換のスタイリングフック / 変数を使用する
renderedCallback()での再レンダリングループを回避する- コンポーネント通信パターンを明示的で最小限に保つ
出力形式
完了時に、この順序で報告します:
- 作成または更新されたコンポーネント
- 選択されたデータアクセスパターン
- 変更されたファイル
- アクセシビリティ / スタイリング / テストノート
- 次の実装またはデプロイステップ
提案形式:
LWC work: <概要>
Pattern: <wire / apex / graphql / lms / flow-screen>
Files: <パス>
Quality: <a11y, SLDS2, dark mode, Jest>
Next step: <deploy, add controller, or run tests>
ローカル開発サーバー
デプロイメント不要で、ホットリロード付きでLWCコンポーネントをローカルでプレビューします:
# LWCコンポーネントを単独でプレビュー
sf lightning dev component --target-org <alias>
# Lightning Experienceアプリをローカルでプレビュー
sf lightning dev app --target-org <alias>
# Experience Cloudサイトをローカルでプレビュー
sf lightning dev site --target-org <alias>
現在のSF CLIリリースでは、これらのLocal Devコマンドは初回実行時にジャストインタイムでインストールされます。これらは長時間実行されるプロセスで、ライブプレビュー付きでブラウザを開きます。.js、.html、.cssファイルへの変更は即座に自動リロードされます。データとApex呼び出しのためのアクティブなorg接続が必要です。
クロススキル統合
| 必要性 | 委譲先 | 理由 |
|---|---|---|
| Apexコントローラまたはサービス | sf-apex | バックエンドロジック |
| Flow画面に埋め込み | sf-flow | 宣言型オーケストレーション |
| コンポーネントバンドルをデプロイ | sf-deploy | org展開 |
| メッセージチャネルのようなメタデータを作成 | sf-metadata | サポートメタデータ |
リファレンスマップ
ここから開始
references/component-patterns.mdreferences/slds-design-guide.mdreferences/lwc-best-practices.mdreferences/scoring-and-testing.mdreferences/jest-testing.md
アクセシビリティ / パフォーマンス / 状態
references/accessibility-guide.mdreferences/performance-guide.mdreferences/state-management.mdreferences/template-anti-patterns.md
統合 / 高度な機能
references/lms-guide.mdreferences/flow-integration-guide.mdreferences/advanced-features.mdreferences/async-notification-patterns.mdreferences/triangle-pattern.mdassets/
スコアガイド
| スコア | 意味 |
|---|---|
| 150+ | 本番対応LWCバンドル |
| 125–149 | 若干のポーリッシュが残る強力なコンポーネント |
| 100–124 | 機能的だがレビュー推奨 |
| < 100 | 大幅な改善が必要 |
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- jaganpro
- リポジトリ
- jaganpro/sf-skills
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/jaganpro/sf-skills / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。