mcpField
F
flutter-runtime-debugging

flutter-runtime-debugging

github.com/thienqo開発1370 回インストール今日更新
リポジトリ

flutter-runtime-debugging について

Flutter の実行時障害を再現し、最初の誤った状態や境界を追跡して、対象を絞った修正を検証するスキルです。Dart と Flutter MCP が利用できない場合は DevTools とコマンドライン出力を使います。

主な機能

  1. 01再現可能な障害条件の記録
  2. 02状態と境界の遷移追跡
  3. 03実行時ログと診断の活用
  4. 04元の手順で修正を検証
  5. 05対象を絞った回帰テストの追加

活用シーン

  1. 01Flutter のクラッシュや実行時エラーの調査
  2. 02ライフサイクルやプラグイン障害の追跡
  3. 03修正による問題解消の確認

MCP 対応

利用可能な場合は Dart と Flutter MCP の機能でウィジェットツリー、構造化ログ、実行時診断を調べます。それ以外では DevTools とコマンドライン出力を使います。

インストール

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

$npx skills add https://github.com/thienqo/flutter-skills --skill flutter-runtime-debugging

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

同梱ファイル

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

evals/
cases.json
references/
devtools-diagnosis.md
reproduction-and-attachment.md

詳細

Flutter ランタイムデバッグ

報告された症状を再現可能な障害に変え、最初に誤った状態または失敗した境界を特定し、サポートされる最小限の修正を適用して、同じフローを繰り返し、根拠を確認します。

ランタイムを把握する

SDK の制約、フレーバー、エントリーポイント、定義、対象プラットフォーム、最近の変更、既存のログやクラッシュ関連ファイルを確認します。別のコピーを起動する前に、利用可能なデバイスと実行中のアプリケーションを調べます。障害に関係する場合は、ユーザーが選択したターゲットと環境を維持します。

最後のスタックフレーム、スクリーンショット、下流のアサーションだけから根本原因を推測しないでください。正確なトリガー、期待される結果、実際の結果、ビルドモード、プラットフォーム、再起動後も障害が続くかどうかを記録します。

環境で利用できる場合は、ウィジェットツリーの調査、構造化ログ、ランタイム診断に Dart と Flutter の MCP 機能を使用します。利用できない場合は、同じ根拠を得るために DevTools と CLI の出力を使用します。

必要に応じてリファレンスを読む

  • ターゲットの選択、既存プロセスへの接続、起動時またはライフサイクルの障害への対処、あるいは不安定な症状の切り分けを行う場合は、再現とアタッチを読みます。
  • 具体的な仮説の検証にインスペクター、デバッガー、ログ、ネットワーク、メモリ、CPU、フレームビューを使用する場合は、DevTools による診断を読みます。

原因を絞り込む

フレームワークのエラー詳細、因果関係を示すスタック、構造化ログ、ブレークポイント、ウォッチ、制御された状態変更を使用します。ウィジェット、状態、アイソレート、トランスポート、プラグイン、ネイティブの各境界におけるデータと所有関係を、根拠が示す範囲内で追跡します。

修正を選ぶ前に、関係する各境界で最初に誤った遷移を確認します。権限またはライフサイクルの障害では、ネイティブコールバック、プラグインまたはチャネルの結果とエラーマッピング、アプリケーションの状態所有者、再開後または破棄後に処理を行うコンシューマーを明示的に追跡します。考えられる原因を列挙するだけで止めたり、防御的な null チェックを早まって決めたりしないでください。

一度に変更する関連変数は 1 つにします。一時的な計測は範囲を限定し、機密情報をマスキングし、完了前に削除するか、適切な恒久的な診断機能に置き換えます。

ホットリロードは状態を保持するため、起動、登録、初期化、生成コード、ネイティブ設定が正しいことの証明にはなりません。プラグインまたはネイティブ登録を変更した場合は、最初の Dart 呼び出しより前に、影響を受けるすべてのサポート対象ターゲットで完全に再ビルドし、クリーンなプロセスで起動します。起動ログと登録ログにエラーがないか確認し、サポート対象外のターゲットでは、偶発的なプラグイン欠落経路ではなく、パッケージで文書化された動作に従って失敗することを検証します。古いネイティブアーティファクトやインストール状態が再ビルド後も残る可能性がある場合は、再インストールします。

境界

  • 診断が作業の目的ではなく、具体的なデバイスで指定された受け入れフローを実行する場合は、flutter-device-testing が担当します。
  • プロファイルモードのトレースと変更前後のパフォーマンスに関する主張は、flutter-performance が担当します。ランタイムデバッグは、機能上の障害または原因候補の切り分けにのみ使用します。
  • 恒久的な自動テスト戦略は、flutter-testing が担当します。ランタイムの原因を理解した後に、回帰テストを追加します。
  • 本番テレメトリーの設計とバックエンドへの取り込みは、flutter-observability が担当します。ただし、その根拠をローカルでの再現に活用できます。
  • チャネル、FFI、プラグイン、プラットフォームビュー、ネイティブのライフサイクル内の修正は、その境界が関係すると判明した後、flutter-platform-integration が担当します。

検証

同等の条件で元の失敗フローを繰り返し、その後、最も近いエラー経路とライフサイクル経路を確認します。欠陥を担当するレイヤーに、最小限の恒久的な回帰テストを追加します。対象、ビルドモード、使用したコマンドまたはツール、確認した根拠、再現または検証できなかった項目を明記します。

参考資料

コメント