インストール
https://docs.flutter.dev/ai/get-started誰向けか
Flutter アプリを作っていて、汎用のコーディング習慣を Dart/Flutter に無理に当てるのではなく、Flutter 向けのスキル、MCP 設定、ルールを持った AI 助手に動かしたいなら、このプラグイン一式が合う。スキル、MCP サーバー設定、ルールをまとめ、順調な Flutter 開発の流れと説明を提供する。
要になるのは Agent Skills だ。単純なファイルディレクトリで、MCP の補完として書かれている。MCP は助手に専用ツールを渡し、Skill は特定タスクでそのツールを「どう使うか」を教える。純粋な Dart 作業は別セットを使う。
https://github.com/dart-lang/skills
このリポジトリを Dart 言語スキルの代わりにしてはいけない。すでに Flutter プロジェクトがあり、公式ドキュメントどおり「いま使っているその Agent」にプラグインを入れることを受け入れる必要がある。
3分で最初の試行を完える
公式のインストール経路は手元のパッケージ管理コマンド1本ではなく、ドキュメントページ「Get started developing with AI」である。
https://docs.flutter.dev/ai/get-started
そのページに沿い、使いたい Agent 向けにプラグインを入れる。そのページの外で、書いていないインストーラを組み立てない。ドキュメントを開く前に確認する：書き込みたい Agent 環境であること、ページの手順どおりにプラグイン／スキル設定を変えてよいこと。これは助手環境を変える操作であり、読み取り専用の確認ではない。
導入後は低リスクの照合から：助手に、Flutter Driver でアプリとどうやり取りするか説明させるか、MCP だけで既存 UI を探らせ、テストファイルはまだ書かせない。成功の合図：話しているのが Flutter ワークフロー（スキル + MCP + ルール）であり、「ツールで探る」と「動作を永久の統合テストにする」を区別できること。pubspec を変え始めたりテストファイルを生成し始めたら、まず止め、変えようとするパスを復唱させる。
使用例
例1：通常の Flutter 開発を進める。このプラグイン一式の目的は、AI 助手の Flutter 開発能力を広げ、合わせたワークフローを出すことだ。作業例：プラグイン済みの助手に、同梱のスキルとルールで小さな UI や工程の変更を完了させる。入手できるページ本文にはスキルフォルダ名も具体的な MCP ツール名もない。だから一度も出ていない短名を指名できない。できるのは「この Flutter プラグイン一式のワークフローに従う」こと。ファイルを直す前にパスは確認する。
例2：統合テストを足す、または先に UI を探る。能力のひとつは、アプリとやり取りできるよう Flutter Driver を設定し、MCP の動作を永久の統合テストにすること。使う場面：プロジェクトに統合テストを足す、MCP で UI コンポーネントを探る、integration_test パッケージでユーザー操作を自動化する。最初は「UI を探る / どんなテストを生成するかを説明する」を優先し、確認してから MCP 動作を永久テストにしてよい。入手できるページ本文にスキル短名はない。呼び出すためのコマンド名を自作しない。
利用上の境界
インストールは
https://docs.flutter.dev/ai/get-started
に従い、使いたい Agent 向けに行う。このリポジトリはそれに並べる二本目のインストールコマンドを書いていない。Dart 作業は
https://github.com/dart-lang/skills
へ移す。現在 pull request は受け付けないが、フィードバックは歓迎する。ページにフィードバック経路の具体フォームはなく、アンインストール手順もない。
「Flutter Driver を設定し、MCP 動作をテストとして書く」を、複製できるスキル短名がすでに出た、と読んではいけない。最初はドキュメントを読む、インストールする、読み取り専用の UI 探索で止める。integration_test への書き込み、ドライバ設定の変更、リポジトリへのパッチ提出は、先に助手に変更予定ファイルを出させ、あなたが確認してから続ける。