メニュー
Flutterプロジェクトの画面定義書（screen specification）を作成・管理するスキル。 「画面定義書を作成したい」「〇〇画面の定義書を作って」などの発言で発動し、 プロジェクト構造を解析してテンプレートをセットアップし、個別の画面定義書を生成します。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Figma のワイヤーフレーム URL から仕様書一式を docs/ 配下に Markdown で抽出するスキル。ページ構成・ユースケース・アクター・データモデル・コンポーネントを 15 ステップで段階的に生成し、整合性／データモデル／コンポーネントの 3 レビューを作成する。**既存リポジトリの機能拡張モード** では既存モデル・ルーティング・ビューを再利用優先。**レビュー反復反映ステップ** では質問ループで方針を確定しドキュメントに反映する。Figma URL が提供されたとき、Figma デザインから実装用仕様書を作りたいとき、または既存仕様書の精度向上を求められたときに使用する。
Claude Codeセッションの効率を分析・スコアリングするWebツール。セッションログ（JSONL）を解析し、7観点100点満点で「無駄の有無」を評価。npx session-evaluatorで起動し、ブラウザUIでセッション選択→分析→改善提案まで実行可能。
PRの変更内容をトリアージし、変更カテゴリ分類・表層チェック・必要リファレンス判定を行います。結果を`.pr-triage.json`に出力し、後続のコードレビューフェーズで活用します。CI環境でのコスト最適化に使用してください。
PRやコード変更の汎用コードレビューを実施します。コードの品質、セキュリティ、設計を共通基準で評価し、approve/rejectを判断します。「このPRをレビュー」「コードレビューして」「マージ前チェック」などの依頼や、gh pr viewコマンドの実行時に使用してください。
テスト仕様書（Excel/Notion）からFlutter integration_testコードを自動生成するスキル。 Page Objectパターン + Key規約に基づき、仕様ステップとコードの対応を示すマッピングレポートも生成する。 「E2Eテストを生成」「テスト仕様からテストコードを作って」「integration_testを生成」などの発言で発動。
CLAUDE.mdを分割ルールファイル(.claude/rules/)で管理するスキル。学習トライアドの書き込み先を分割ファイルにリダイレクトし、自動マージでCLAUDE.mdを生成。/rules-init, /rules-merge, /rules-add, /rules-status コマンドを提供。CLAUDE.mdが肥大化している場合や、学習トライアドの蓄積を分割管理したい場合に使用。
| name | screen-spec-generator |
| description | Flutterプロジェクトの画面定義書（screen specification）を作成・管理するスキル。 「画面定義書を作成したい」「〇〇画面の定義書を作って」などの発言で発動し、 プロジェクト構造を解析してテンプレートをセットアップし、個別の画面定義書を生成します。 |
このスキルは、Flutterプロジェクトにおける画面定義書の作成環境をセットアップし、個別の画面定義書を生成・更新する機能を提供します。
以下のような発言で発動します：
このスキルは以下を行います：
各ステップで必ずユーザーの回答を待ってから次のステップに進むこと。
これにより、ユーザーが混乱せず、段階的に設定を進められます。
このスキルには3つの動作モードがあります：
プロジェクトに docs/screen_specs/template.md が存在しない場合、セットアップモードで動作します。
プロジェクトに docs/screen_specs/template.md が存在し、対象画面の定義書が存在しない場合、新規生成モードで動作します。
対象画面の定義書が既に存在する場合、更新モードで動作します。コードを再解析し、差分を検出してユーザーに提示します。
まず、プロジェクトの構造を解析します。
CLAUDE.md を読み込み、以下の情報を取得：
具体的なパス構造を自動解析：
lib/ui/, lib/presentation/ など）解析結果を簡潔に確認：
「CLAUDE.mdを確認しました。Flutter + Riverpod + auto_route のプロジェクトですね。
プロジェクト構造を解析したところ、以下のようになっています：
- UI層: lib/ui/{module}/widgets/
- ViewModel: lib/ui/{module}/view_models/
- ルーター: lib/routing/routes/app_router.dart
この認識で合っていますか？」
ここでユーザーの回答を待つ。次のステップに進まない。
pubspec.yaml を読み込み、以下を検出：
ディレクトリ構造を解析：
検出結果をすべてユーザーに確認：
「画面定義書の作成をお手伝いします。
プロジェクトの構造を解析しました。
pubspec.yaml から以下を検出しました：
- フレームワーク: Flutter
- 状態管理: flutter_riverpod
- ルーティング: auto_route
ディレクトリ構造から以下を推測しました：
- UI層: lib/ui/{module}/widgets/
- ViewModel: lib/ui/{module}/view_models/
- ルーター: lib/routing/routes/app_router.dart
この認識で合っていますか？修正点があれば教えてください。」
ここでユーザーの回答を待つ。次のステップに進まない。
ステップ1でユーザーが「はい」「OK」などと回答したら、このステップに進む。
画面定義書に含めるセクションを会話で選択します。
「では、画面定義書に含めるセクションを選びましょう。
デフォルトは以下の通りです：
1. ✅ 基本情報（必須）- 画面ID、画面名、ファイルパス、最終更新日
2. ✅ スクリーンショット - 画面キャプチャの配置領域
3. ✅ 表示項目 - 静的な表示要素の一覧
4. ✅ イベント項目 - ユーザー操作によるイベント
5. ⬜ 本画面遷移時イベント - 画面表示時の自動イベント
6. ⬜ 処理フロー - API通信等の詳細フロー
7. ✅ 備考 - 特記事項
変更したい項目はありますか？」
ここでユーザーの回答を待つ。次のステップに進まない。
ステップ2でユーザーが回答したら、このステップに進む。
「他に追加したいセクションや、テーブルの列をカスタマイズしたい点はありますか？
例：
- イベント項目に analytics 列を追加
- 表示項目にデザイントークン列を追加
- 独自のセクションを追加
」
ここでユーザーの回答を待つ。次のステップに進まない。
ステップ3でユーザーが回答したら、このステップに進む。
確認が完了したら、以下のファイルを生成します：
.claude/commands/screen-spec.md - カスタムコマンドdocs/screen_specs/template.md - テンプレートdocs/screen_specs/README.md - 使い方ガイド「以下のファイルを生成しました：
- .claude/commands/screen-spec.md
- docs/screen_specs/template.md
- docs/screen_specs/README.md
これで `/screen-spec lib/ui/xxx/widgets/xxx_page.dart` で
画面定義書を生成できるようになりました。
是非、実際に1つ画面定義書を作成してみてください。
作成後、修正点があったら教えてください。」
docs/screen_specs/template.md が存在すること.claude/commands/screen-spec.md が存在することユーザーが以下のように発言した場合：
docs/screen_specs/template.md を読み込み.claude/commands/screen-spec.md の手順に従って生成ユーザーが以下のように発言した場合：
/screen-spec lib/ui/xxx/widgets/xxx_page.dart（既存ファイルに対して）既存の定義書を無視して新規作成したい場合：
/screen-spec lib/ui/xxx/widgets/xxx_page.dart --new
セクション別テンプレートは以下を参照：
templates/base_template.mdtemplates/screen_spec_command.mdtemplates/sections/display_items.mdtemplates/sections/event_items.mdtemplates/sections/navigation_events.mdtemplates/sections/process_flow.md