アプリの全画面をライト・ダーク両方で巡回させ、ID付きの改善リストとBefore/Afterを出させるプロンプト
コードは一切変えさせず、全画面・全状態のスクショを撮らせて、実物のスクショで裏を取った指摘だけを影響度順にまとめさせる。翌朝1件ずつレビューできる形で納品させる。
どんな問題を解決するか / いつ使うか
「なんとなく見た目が粗い」アプリを、抜け漏れなく点検したいとき。夜にエージェントへ任せて、朝に改善点を1つずつ判断する使い方に向く。
プロンプトの骨子(要約・自分の言葉で再構成)
- 実機またはエミュレーター([端末・テスト用アカウント・テスト環境])で、すべてのメニューと画面をライトモードとダークモードの両方で巡回する。サブページ、シート、空の状態、エラーの状態、作成フローの各ステップも含める。
- 画面ごとにスクショを撮り、見せ方を改善できる点をメモする。
- コードは変更しない。 指摘はすべて実際のスクショと照合してから載せる。モックの中身をでっち上げず、アプリの実データを使う。
- 事前に frontend-design、文章のガイドライン、モバイルUXレビュー系のスキル(プロジェクトにある同等のもの)を読み込み、デザインシステム([パス])に従う。
- 納品物:
- 全指摘の一覧。ID(U-1、U-2…)、画面、問題、提案、手間(S/M)を付け、影響度(高・中・低)順に並べる
- 重要な画面は左右のBefore/After(左=実機スクショ、右=デザインシステムのトークンを使った提案)
- 「既知の問題」と「未確認の範囲」の欄
- プライバシーや挙動に関わるものは明示的に印を付ける
- テスト用アカウントへの副作用(設定変更や同意の操作)を最後に記録する
注意点
- 端末操作には、エミュレーターやブラウザを動かせる環境(MCPやスクショ取得の仕組み)が必要。
- 「スクショと照合してから載せる」の一文が、もっともらしいが実在しない指摘を減らす要になる。
- テスト用アカウントを使い、本番データや本人のアカウントでは回さない。
関連
出典
- @_Thars_ post