Anthropic Claudeその他⭐ リポ 0品質スコア 50/100

flutter-dart-code-review

Name: flutter-dart-code-review
Author: affaan-m

FlutterおよびDartのコードレビューを包括的にサポートするスキルで、Widgetのベストプラクティス、状態管理パターン（BLoC、Riverpod、Provider、GetX、MobX、Signals）、Dartのイディオム、パフォーマンス、アクセシビリティ、セキュリティ、クリーンアーキテクチャを網羅します。特定ライブラリに依存しない汎用的なチェックリストとして機能し、コード品質の向上や設計上の問題点の早期発見に役立ちます。

description の原文を見る

库无关的Flutter/Dart代码审查清单，涵盖Widget最佳实践、状态管理模式（BLoC、Riverpod、Provider、GetX、MobX、Signals）、Dart惯用法、性能、可访问性、安全性和整洁架构。

SKILL.md 本文

Flutter/Dart コードレビューのベストプラクティス

Flutter/Dart アプリケーションをレビューするための包括的でライブラリに依存しないチェックリスト。どの状態管理ソリューション、ルーティングライブラリ、または依存性注入フレームワークを使用していても、これらの原則は適用されます。

1. 一般的なプロジェクトの健全性

[ ] プロジェクトは一貫したフォルダ構造に従っている（フィーチャーファーストまたはレイヤーファースト）
[ ] 関心の分離が適切である：UI、ビジネスロジック、データレイヤー
[ ] Widget にはビジネスロジックがない；Widget は純粋にプレゼンテーション用
[ ] pubspec.yaml が整理されている —— 未使用の依存関係なし、バージョンが適切に固定されている
[ ] analysis_options.yaml に厳格な lint ルールセットが含まれており、厳格なアナライザー設定が有効化されている
[ ] 本番コードに print() ステートメントがない —— dart:developer の log() またはログパッケージを使用
[ ] 生成ファイル (.g.dart, .freezed.dart, .gr.dart) が最新の状態か .gitignore に含まれている
[ ] プラットフォーム固有のコードは抽象化で隔離されている

2. Dart 言語の落とし穴

[ ] 暗黙的な動的型：型注釈の欠落が dynamic につながっている —— strict-casts、strict-inference、strict-raw-types を有効化
[ ] null-safety の誤用：適切な null チェックや Dart 3 パターンマッチング (if (value case var v?)) の代わりに !（null assert 演算子）を過度に使用している
[ ] 型の絞り込み失敗：ローカル変数の型の絞り込みが可能な場所で this.field を使用している
[ ] スコープが広すぎる catch：on 句がない catch (e)；常に例外型を指定すべき
[ ] Error をキャッチしている：Error のサブタイプはプログラムエラーであり、キャッチすべきではない
[ ] 不要な async：async とマークされているが決して await されない関数 —— 不要なオーバーヘッド
[ ] late の過度な使用：nullable 型またはコンストラクタ初期化がより安全な場所で late を使用；エラーを実行時まで延期
[ ] ループ内の文字列連結：反復的な文字列構築では StringBuffer を使用 + ではなく
[ ] const コンテキスト内の可変状態：const コンストラクタを持つクラスのフィールドは可変であってはならない
[ ] Future 戻り値の無視：await するか、意図を示すために明示的に unawaited() を呼び出す
[ ] final が可能なときに var を使用：ローカル変数には final を優先、コンパイル時定数には const を優先
[ ] 相対インポート：一貫性のために package: インポートを使用
[ ] 可変コレクションの公開：公開 API は原始の List/Map ではなく変更不可能なビューを返すべき
[ ] Dart 3 パターンマッチングの欠落：冗長な is チェックと手動型キャストの代わりに switch 式と if-case を優先
[ ] 複数の戻り値に一時クラスを使用：一時 DTO の代わりに Dart 3 レコード (String, int) を使用
[ ] 本番コードの print()：dart:developer の log() またはプロジェクトのログパッケージを使用；print() はログレベルがなくフィルタリング不可

3. Widget のベストプラクティス

Widget の分解：

[ ] 単一の Widget の build() メソッドが約 80～100 行を超えていない
[ ] Widget はカプセル化の方法と変化の方法（再構築境界）に基づいて分割されている
[ ] Widget を返す私的な _build*() ヘルパーメソッドは別の Widget クラスに抽出される（エレメント再利用、const の伝播、フレームワーク最適化をサポート）
[ ] 可変なローカル状態が不要な場所では StatelessWidget よりも StatefulWidget を優先
[ ] 抽出された Widget は再利用可能な場合、別のファイルに配置される

const の使用：

[ ] const コンストラクタをできるだけ使用 —— 不要な再構築を防止
[ ] 不変なコレクションには const リテラル (const []、const {}) を使用
[ ] すべてのフィールドが final の場合、コンストラクタを const として宣言

Key の使用：

[ ] リスト/グリッドで ValueKey を使用して再順序化時に状態を保持
[ ] GlobalKey は慎重に使用 —— 本当に必要な場合のみ、ツリー間でのアクセスが必要な場合
[ ] build() で UniqueKey を避ける —— 毎フレーム再構築を強制
[ ] ID が単一値ではなくデータオブジェクトに基づく場合、ObjectKey を使用

テーマとデザインシステム：

[ ] 色は Theme.of(context).colorScheme から取得 —— ハードコードされた Colors.red または 16 進値なし
[ ] テキストスタイルは Theme.of(context).textTheme から取得 —— インラインの TextStyle と原始フォントサイズなし
[ ] ダークモード互換性を検証済み —— 浅色背景を仮定していない
[ ] 間隔とサイズは一貫したデザイントークンまたは定数を使用、マジックナンバーではなく

build メソッドの複雑度：

[ ] build() 内にネットワーク呼び出し、ファイル I/O、または重い計算なし
[ ] build() 内に Future.then() または async 作業なし
[ ] build() 内にサブスクリプション作成 (.listen()) なし
[ ] setState() をできるだけ小さなサブツリーに局所化

4. 状態管理（ライブラリに依存しない）

これらの原則はすべての Flutter 状態管理ソリューション（BLoC、Riverpod、Provider、GetX、MobX、Signals、ValueNotifier など）に適用されます。

アーキテクチャ：

[ ] ビジネスロジックは Widget レイヤーの外に位置 —— 状態管理コンポーネント内（BLoC、Notifier、Controller、Store、ViewModel など）
[ ] 状態管理器は依存関係を内部で構築するのではなく、依存性注入経由で受け取る
[ ] サービスまたはリポジトリレイヤーがデータソースを抽象化 —— Widget と状態管理器は API またはデータベースを直接呼び出さない
[ ] 状態管理器は単一の責任を持つ —— 無関連の責任を処理する「神」管理器なし
[ ] クロスコンポーネント依存関係はソリューションの慣例に従う：
- Riverpod の場合：プロバイダーが ref.watch 経由で他のプロバイダーに依存することは予期されている —— 循環参照または過度に複雑なチェーンのみをマーク
- BLoC の場合：bloc は他の bloc に直接依存すべきではない —— 共有リポジトリまたはプレゼンテーション層協調を優先
- その他のソリューション：コンポーネント間通信に関するドキュメントの慣例に従う

不変性と値の等価性（不変状態ソリューション用：BLoC、Riverpod、Redux）：

[ ] 状態オブジェクトは不変 —— copyWith() またはコンストラクタ経由で新しいインスタンスを作成、決して就地変更しない
[ ] 状態クラスは == と hashCode を正しく実装（比較にすべてのフィールドを含める）
[ ] メカニズムはプロジェクト全体で一貫性がある —— 手動オーバーライド、Equatable、freezed、Dart レコード、または他の手段
[ ] 状態オブジェクト内のコレクションは原始の可変 List/Map として公開されていない

リアクティブな規律（リアクティブな変更ソリューション用：MobX、GetX、Signals）：

[ ] 状態はソリューションのリアクティブ API 経由でのみ変更（MobX の @action、Signal 上の .value、GetX の .obs）—— 直接フィールド変更は変更追跡をバイパス
[ ] 派生値はソリューションの計算機制を使用、冗長なストレージではなく
[ ] 反応とクリーンアップは正しくクリーンアップされる（MobX の ReactionDisposer、Signal のエフェクトクリーンアップ）

状態の形状設計：

[ ] 相互排他的な状態は sealed 型、union バリアント、またはソリューション内蔵の非同期状態型（例：Riverpod の AsyncValue）を使用 —— boolean フラグ (isLoading、isError、hasData) ではなく
[ ] 各非同期操作は loading、success、error を異なる状態としてモデル化
[ ] UI で詳細にすべての状態バリアントを処理 —— サイレント無視なし
[ ] エラー状態は表示用のエラーメッセージを含む；loading 状態は古いデータを含まない
[ ] nullable データは loading インジケーターとして使用されない —— 状態は明示的

// BAD — boolean flag soup allows impossible states
class UserState {
  bool isLoading = false;
  bool hasError = false; // isLoading && hasError is representable!
  User? user;
}

// GOOD (immutable approach) — sealed types make impossible states unrepresentable
sealed class UserState {}
class UserInitial extends UserState {}
class UserLoading extends UserState {}
class UserLoaded extends UserState {
  final User user;
  const UserLoaded(this.user);
}
class UserError extends UserState {
  final String message;
  const UserError(this.message);
}

// GOOD (reactive approach) — observable enum + data, mutations via reactivity API
// enum UserStatus { initial, loading, loaded, error }
// Use your solution's observable/signal to wrap status and data separately

再構築最適化：

[ ] 状態コンシューマー Widget（Builder、Consumer、Observer、Obx、Watch など）のスコープはできるだけ狭い
[ ] セレクターを使用して特定フィールド変化時のみ再構築 —— 状態発行のたびではなく
[ ] const Widget を使用してツリーを通じた再構築の伝播を防止
[ ] 計算/派生状態はリアクティブ計算、冗長なストレージではない

サブスクリプションとクリーンアップ：

[ ] すべての手動サブスクリプション (.listen()) は dispose() / close() でキャンセルされる
[ ] ストリームコントローラーは不要になったときクローズ
[ ] タイマーはクリーンアップライフサイクルでキャンセル
[ ] 手動サブスクリプションより、フレームワーク管理のライフサイクルを優先（宣言的ビルダーが .listen() より良い）
[ ] 非同期コールバックで setState の前に mounted をチェック
[ ] await 後の BuildContext の使用には context.mounted をチェック（Flutter 3.7+）—— 古いコンテキストはクラッシュを引き起こす
[ ] 非同期間隔の後、Widget が依然マウントされていることを検証せずにナビゲート、ダイアログを表示、またはスカフォールドメッセージなし
[ ] BuildContext はシングルトン、状態管理器、または静的フィールドに格納されない

ローカル状態と global 状態：

[ ] 一時的な UI 状態（チェックボックス、スライダー、アニメーション）はローカル状態を使用 (setState, ValueNotifier)
[ ] 共有状態はのみ必要な高さまで上昇 —— 過度にグローバル化しない
[ ] フィーチャースコープの状態はフィーチャーがアクティブでなくなったときに正しくクリーンアップされる

5. パフォーマンス

不要な再構築：

[ ] ルート Widget レベルで setState() を呼び出さない —— 状態変更をローカライズ
[ ] const Widget を使用して再構築の伝播を防止
[ ] 複雑な独立再描画サブツリーの周りに RepaintBoundary を使用
[ ] アニメーション以外のサブツリーに AnimatedBuilder の child パラメータを使用

build() 内の高コスト操作：

[ ] 大規模なコレクションのソート、フィルタリング、または mapping を build() で行わない —— 状態管理層で計算
[ ] 正規表現のコンパイルを build() で行わない
[ ] MediaQuery.of(context) の使用は具体的（例：MediaQuery.sizeOf(context)）

画像の最適化：

[ ] ネットワーク画像はキャッシュを使用（プロジェクトのキャッシングソリューション）
[ ] ターゲットデバイスに適切な画像解像度を使用（サムネイル用に 4K 画像を読み込まない）
[ ] cacheWidth/cacheHeight を伴う Image.asset を使用して表示サイズにデコード
[ ] ネットワーク画像にプレースホルダーとエラー Widget を提供

遅延読み込み：

[ ] 大規模または動的リストには ListView(children: [...]) の代わりに ListView.builder / GridView.builder を使用（小規模で静的なリストについては具体的なコンストラクタは OK）
[ ] 大規模データセットのペジネーション実装
[ ] Web ビルドで重量級ライブラリに遅延読み込みを使用 (deferred as)

その他：

[ ] アニメーションで Opacity Widget の使用を避ける —— AnimatedOpacity または FadeTransition を使用
[ ] アニメーションでクリップを避ける —— 画像をプリクリップ
[ ] Widget で operator == をオーバーライドしない —— const コンストラクタの代わりに使用
[ ] Intrinsic サイズ Widget (IntrinsicHeight、IntrinsicWidth) は慎重に使用（追加レイアウトパス）

6. テスト

テストタイプと期待：

[ ] ユニットテスト：すべてのビジネスロジック（状態管理器、リポジトリ、ユーティリティ関数）をカバー
[ ] Widget テスト：単一 Widget の動作、インタラクション、ビジュアル出力をカバー
[ ] 統合テスト：重要なユーザーフローのエンドツーエンドカバレッジ
[ ] Golden テスト：デザイン上重要な UI コンポーネントのピクセルレベルの精密比較

カバレッジ目標：

[ ] ビジネスロジックは 80% 以上のラインカバレッジを目標
[ ] すべての状態遷移にテストがある（loading → success、loading → error、retry など）
[ ] エッジケースをテスト：空状態、エラー状態、loading 状態、境界値

テストの分離：

[ ] 外部依存関係（API クライアント、データベース、サービス）はモック化またはフェイク化
[ ] 各テストファイルは単一クラス/ユニットのみをテスト
[ ] テストは実装詳細ではなく動作を検証
[ ] スタブは各テストに必要な動作のみを定義（スタブを最小化）
[ ] テストケース間で共有可変状態なし

Widget テスト品質：

[ ] pumpWidget と pump は非同期操作で正しく使用
[ ] find.byType、find.text、find.byKey を適切に使用
[ ] タイミングに依存する不安定なテストなし —— pumpAndSettle または明示的な pump(Duration) を使用
[ ] テストは CI で実行、失敗は merge をブロック

7. アクセシビリティ

Semantics Widget：

[ ] 自動ラベリングが不十分な場合、Semantics Widget はスクリーンリーダーラベルを提供
[ ] 純粋に装飾的な要素には ExcludeSemantics を使用
[ ] 関連 Widget を単一アクセス可能要素に結合するには MergeSemantics を使用
[ ] 画像に semanticLabel プロパティが設定されている

スクリーンリーダー対応：

[ ] すべてのインタラクティブ要素がフォーカス可能で有意な説明を持つ
[ ] フォーカス順序が論理的（視覚的読み順に従う）

ビジュアルアクセシビリティ：

[ ] テキストと背景のコントラスト比 >= 4.5:1
[ ] クリック可能なターゲットは少なくとも 48x48 ピクセル
[ ] 色が状態の唯一の指標ではない（アイコン/テキストも使用）
[ ] テキストはシステムフォントサイズ設定でスケール

インタラクションアクセシビリティ：

[ ] onPressed コールバックで何もしない —— すべてのボタンにアクションがあるか無効状態
[ ] エラーフィールドは修正を提案
[ ] ユーザーが入力データを入力している場合、コンテキストが予期せず変わらない

8. プラットフォーム固有の考慮

iOS/Android の差異：

[ ] 適切な場所でプラットフォーム適応 Widget を使用
[ ] 戻るナビゲーションが正しく処理される（Android 戻るボタン、iOS スワイプバック）
[ ] SafeArea Widget 経由でステータスバーと安全地域を処理
[ ] プラットフォーム固有の権限を AndroidManifest.xml と Info.plist で宣言

レスポンシブデザイン：

[ ] LayoutBuilder または MediaQuery を使用してレスポンシブレイアウト実装
[ ] 一貫したブレークポイント定義（モバイル、タブレット、デスクトップ）
[ ] 小さい画面でテキストがオーバーフロー —— Flexible、Expanded、FittedBox を使用
[ ] 横方向をテストするか明示的にロック
[ ] Web 固有：マウス/キーボードインタラクションサポート、ホバー状態存在

9. セキュリティ

セキュアストレージ：

[ ] 機密データ（トークン、認証情報）はプラットフォームセキュアストレージを使用（iOS の Keychain、Android の EncryptedSharedPreferences）
[ ] 機密情報をプレーンテキストで格納しない
[ ] 機密操作は生体認証認証ゲートの背後にあることを検討

API キー処理：

[ ] API キーは Dart ソースコードにハードコードされていない —— --dart-define、.env ファイル（VCS から除外）、またはコンパイル時設定を使用
[ ] 機密情報が git にコミットされていない —— .gitignore をチェック
[ ] 本当のシークレットキーにバックエンドプロキシを使用（クライアントはサーバーシークレットを保持すべきではない）

入力検証：

[ ] すべてのユーザー入力を API に送信前に検証
[ ] フォーム検証は適切な検証パターンを使用
[ ] ユーザー入力の生 SQL または文字列補間なし
[ ] ディープリンク URL はナビゲーション前に検証・清潔化

ネットワークセキュリティ：

[ ] すべての API 呼び出しは HTTPS を強制
[ ] 高セキュリティアプリケーションについて証明書ピニングを検討
[ ] 認証トークンは正しく更新・失効
[ ] 機密データのログまたはプリント出力なし

10. パッケージ/依存関係のレビュー

pub.dev パッケージの評価：

[ ] pub スコアをチェック（目標 130+/160）
[ ] 点数と人気度をコミュニティシグナルとしてチェック
[ ] pub.dev で発行者が検証済みことを確認
[ ] 最後の発行日をチェック —— 古いパッケージ（>1 年）はリスク
[ ] メンテナーの未解決の問題と応答時間をレビュー
[ ] ライセンスをプロジェクトと互換性をチェック
[ ] プラットフォーム対応がターゲットをカバーすることを確認

バージョン制約：

[ ] 依存関係に caret 構文を使用 (^1.2.3) —— 互換性更新を許可
[ ] 正確なバージョンを固定するのは絶対に必要な場合のみ
[ ] flutter pub outdated を定期的に実行して古い依存関係を追跡
[ ] 本番 pubspec.yaml に依存関係のオーバーライドなし —— コメント/issue リンク付き一時修正のみ
[ ] 推移的依存関係の数を最小化 —— 各依存関係は攻撃面

Monorepo 固有（melos/workspace）：

[ ] 内部パッケージは公開 API からのみインポート —— package:other/src/internal.dart なし（Dart パッケージカプセル化を破損）
[ ] 内部パッケージ依存関係は workspace resolution を使用、ハードコード path: ../../ 相対パスではなく
[ ] すべてのサブパッケージはルート analysis_options.yaml を共有または継承

11. ナビゲーションとルーティング

一般原則（任意のルーティングソリューション）：

[ ] 1 つのルーティング方法を一貫して使用 —— 命令型 Navigator.push と宣言型ルーターを混合しない
[ ] ルートパラメータは型付け —— Map<String, dynamic> または Object? キャストなし
[ ] ルートパスは定数、enum、または生成されたものとして定義 —— コードに散在する魔法文字列なし
[ ] 認証ガード/リダイレクトは集中化 —— 各画面で繰り返さない
[ ] Android と iOS にディープリンク設定
[ ] ディープリンク URL はナビゲーション前に検証・清潔化
[ ] ナビゲーション状態はテスト可能 —— テストでルート変更を検証可能
[ ] すべてのプラットフォームで戻る動作が正しい

12. エラーハンドリング

フレームワークエラーハンドリング：

[ ] FlutterError.onError をオーバーライドしてフレームワークエラー（build、layout、paint）をキャッチ
[ ] Flutter uncaught async エラーを処理するため PlatformDispatcher.instance.onError を設定
[ ] リリースモード向けに ErrorWidget.builder をカスタマイズ（赤画面ではなくユーザーフレンドリー）
[ ] runApp 周りでグローバルエラーキャッチラッパー（例：runZonedGuarded、Sentry/Crashlytics ラッパー）を使用

エラーレポート：

[ ] エラーレポートサービス統合（Firebase Crashlytics、Sentry または同等）
[ ] スタックトレース付き非致命的エラーを報告
[ ] 状態管理エラーオブザーバーをエラーレポートに接続（例：BlocObserver、ProviderObserver または適用可能なソリューション同等）
[ ] デバッグ用にユーザー識別情報（ユーザー ID）をエラーレポートに添付

グレースフルデグラデーション：

[ ] API エラーはクラッシュではなく、ユーザーフレンドリーなエラー UI になる
[ ] 瞬時的なネットワーク故障のリトライ機制
[ ] オフラインステータス優雅に処理
[ ] 状態管理内のエラー状態は表示用のエラーメッセージを含む
[ ] 原始例外（ネットワーク、解析）は UI に到達する前にユーザーフレンドリーなローカライズメッセージに mapping —— 原始例外文字列をユーザーに表示しない

13. 国際化（l10n）

セットアップ：

[ ] ローカライゼーションソリューション設定（Flutter 内蔵 ARB/l10n、easy_localization または同等）
[ ] サポートされるロケールをアプリ設定で宣言

コンテンツ：

[ ] すべてのユーザー可視文字列はローカライゼーションシステムを使用 —— Widget 内のハードコード文字列なし
[ ] テンプレートファイルに翻訳者向けの説明/コンテキスト含む
[ ] 複数形、性別、選択に ICU メッセージ構文を使用
[ ] 型定義プレースホルダーを使用
[ ] ロケール間でキーの欠落なし

コードレビュー：

[ ] ローカライゼーションアクセッサーの一貫性がプロジェクト全体
[ ] 日付、時刻、数字、通貨フォーマットはロケール対応
[ ] ターゲット言語がアラビア語、ヘブライ語など場合、文本方向性（RTL）をサポート
[ ] ローカライズテキストに文字列連結なし —— パラメータ化メッセージを使用

14. 依存性注入

原則（任意の DI 方法）：

[ ] クラスはレイヤー境界で抽象化（インターフェース）に依存、具体実装ではなく
[ ] 依存関係は外部から提供（コンストラクタ、DI フレームワーク、またはプロバイダーグラフ）—— 内部作成ではなく
[ ] 登録はライフサイクルを区別：シングルトン vs ファクトリー vs lazy シングルトン
[ ] 環境特定バインディング（dev/staging/production）は構成で使用、実行時 if チェックではなく
[ ] DI グラフに循環依存なし
[ ] サービスロケーター呼び出し（使用場合）はビジネスロジック全体に散在していない

15. 静的分析

設定：

[ ] analysis_options.yaml が存在し、厳格な設定が有効
[ ] 厳格なアナライザー設定：strict-casts: true、strict-inference: true、strict-raw-types: true
[ ] 包括的な lint ルールセット（very_good_analysis、flutter_lints、またはカスタム厳格ルール）
[ ] monorepo のすべてのサブパッケージはルート分析オプションを継承または共有

実行：

[ ] コミットされたコードに未解決のアナライザー警告なし
[ ] lint 抑制（// ignore:）に理由をコメント
[ ] CI で flutter analyze 実行、失敗は merge をブロック

lint パッケージに関わらず検証する重要ルール：

[ ] prefer_const_constructors —— Widget ツリーでのパフォーマンス
[ ] avoid_print —— 適切なログ記録を使用
[ ] unawaited_futures —— fire-and-forget async エラーを防止
[ ] prefer_final_locals —— 変数レベルの不可変性
[ ] always_declare_return_types —— 明確な契約
[ ] avoid_catches_without_on_clauses —— 具体的なエラーハンドリング
[ ] always_use_package_imports —— 一貫したインポートスタイル

状態管理クイックリファレンス

下の表は一般原則を人気ソリューション内の実装に map します。この表を使用してプロジェクトが使用するあらゆるソリューションに審査ルールを調整します。

原則	BLoC/Cubit	Riverpod	Provider	GetX	MobX	Signals	内蔵
状態コンテナ	`Bloc`/`Cubit`	`Notifier`/`AsyncNotifier`	`ChangeNotifier`	`GetxController`	`Store`	`signal()`	`StatefulWidget`
UI コンシューマー	`BlocBuilder`	`ConsumerWidget`	`Consumer`	`Obx`/`GetBuilder`	`Observer`	`Watch`	`setState`
セレクター	`BlocSelector`/`buildWhen`	`ref.watch(p.select(...))`	`Selector`	N/A	computed	`computed()`	N/A
副作用	`BlocListener`	`ref.listen`	`Consumer` コールバック	`ever()`/`once()`	`reaction`	`effect()`	コールバック
Disposal	`BlocProvider` 経由自動	`.autoDispose`	`Provider` 経由自動	`onClose()`	`ReactionDisposer`	手動	`dispose()`
テスト	`blocTest()`	`ProviderContainer`	直接 `ChangeNotifier`	テスト内 `Get.put`	直接 store テスト	直接 signal テスト	Widget テスト

出典

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者: affaan-m
リポジトリ: affaan-m/everything-claude-code
ライセンス: MIT
最終更新: 不明

GitHubで原本を見る →フィードバックを送る

Source: https://github.com/affaan-m/everything-claude-code / ライセンス: MIT