flows-design-review

Flows のデザインレビュー

これは、Flows アプリの認定フローのステップ 3です。

flows-app-brief  →  build  →  flows-code-review  →  flows-design-review (this skill)  →  flows-external-app-submit

これは、docs.cognite.com/cdf/flows/guides/quality-guidelines で説明されている手動によるデザイン品質評価です。 リリース可能な状態にするには、全体平均を3.8 以上にする必要があります。

運用ルール

• まず自動化し、次に質問します。 質問 Q1～Q10 のそれぞれについて、以下に記載されたプローブを実行し、リポジトリから確かな根拠を集め、ユーザーに尋ねる前に、根拠を添えて採点案（1～5）を提示します。ユーザーの役割は、ゼロから採点することではなく、採点案を承認または変更することです。これにより、手作業の負担を大幅に軽減できます。
• **タスクのウォークスルー（ステップ 2）**だけは省略できません。画面を移動する際にユーザーが「迷う」かどうかは、自動化では判断できません。手動で記録し、実体験が自動算出されたスコアと異なる場合は、それに基づいてスコアを変更します。
• すべての採点にAskQuestionを使い、回答を構造化します。各質問では、次の 3 つの選択肢を提示します：（a）採点案を承認する、（b）具体的なスコアに変更する、（c）スコアを変更し、メモを追加する。
• App-Brief.mdのフロントマターがある場合は、そこからユーザー、タスク、ペルソナのコンテキストを事前入力します。

ステップ 0 — 質問する前の事前スキャン

ユーザーに何かを尋ねる前に、必ず事前スキャンを行います。 次の情報源をユーザーに知らせずに読み取り、見つかった内容を根拠として提示します。スコアとして提示したり、自動保存したりしてはいけません。

情報源	用途
App-Brief.mdのフロントマター	主なユーザー（userRole）、タスク（oneSentenceStory）、成功基準を事前入力する
package.json	@cognite/auraがインストールされていることを確認し、そのバージョンを提示する（Q1 の判断材料）
最新のreviews/code-review/feedback-round-<N>/code-review-report.md	デザインに関連する指摘（アクセシビリティ、エラー処理、UX 文言）を抽出し、Q4/Q10 の根拠として提示する
src/**/*.{ts,tsx,css}	Q1 のプローブ — Aura トークン以外でハードコードされた hex/rgb カラーや生のpx/rem値を検索する
src/**/*.{ts,tsx}	Q5 のプローブ — role/tabIndexのないボタン以外の要素にあるonClickを検索する
src/**/*.{ts,tsx}	Q10 のプローブ — aria-labelのないアイコンボタン、altのない<img>、フォーカススタイルの欠如を検索する

採点を始める前に、冒頭のメッセージで事前スキャンの結果をユーザーに提示します。これらは出発点であり、最終判断ではありません。手動のタスクウォークスルー（ステップ 2）と、ユーザーが割り当てたスコアを最終判断として扱います。

ステップ 0b — フィードバックラウンドを選択する

reviews/design-review/を確認します。存在しない場合はラウンド 1 です。それ以外の場合は、次に欠番となっているfeedback-round-<N>/ディレクトリを選択します。

ステップ 1 — ユーザーとタスクを確認する

ドキュメントにあるとおり、「品質評価の有用性は、その前提となるユーザーとタスクがどれだけ明確かにかかっています」。

App-Brief.mdが存在する場合は、そのフロントマターからuserRole、oneSentenceStory、successCriteriaを読み取り、主なユーザーとタスクの案として提示します。確認または補足をユーザーに求めます。

AskQuestionを使って、次の内容を確認します。

• 主なユーザー — 具体的な役割と状況（例：「海上プラットフォームの保全エンジニア」）。
• 重要なタスク 2～3 件 — このユーザーが完了する必要のあるワークフロー（例：「ポンプの振動アラートを確認する」、「保守作業を予定する」）。
• コンテキスト — 経験レベル、時間的制約、デバイス、成功基準。

ステップ 2 — 各タスクを最初から最後まで実行する（手動）

ユーザーに次の手順を依頼します。

1. 代表的なテストデータを用意し、クリーンなブラウザーセッションで、そのユーザーの立場からアプリを開く。
2. 近道を使わずに、各タスクを最初から最後まで完了する。
3. つまずいた場所、混乱した場所、ミスをした箇所など、問題点を記録する。

各タスクについて、ユーザーに次の内容を返信してもらいます。何が起きたか、どこでつまずいたか、スクリーンショットやメモがあればそれも含めます。これらをtaskWalkthroughs[]としてレポートに記録します。

ユーザーがすべてのタスクをウォークスルーしたことを確認するまで、採点に進んではいけません。ユーザーが拒否した場合は、「task walkthrough skipped」と記録した仮レポートを作成して終了します。採点してはいけません。

ステップ 3 — 10 個の質問に採点する（調査 → 提案 → 確認）

Q1～Q10 の各質問について、同じ流れに従います。

1. 指定された調査を実行します。 リポジトリから確かな証拠を得るための、具体的なシェル／grep／lint／build コマンドです。
2. 調査結果と評価基準に基づいて、仮のスコア（1～5）を提案します。 根拠を示します。どの調査結果がどのスコアにつながったかを説明してください。
3. ステップ 2 のユーザーのタスクウォークスルーのメモと照合します（特にナビゲーション、クリック可能かどうか、エラー防止について）。
4. AskQuestion でユーザーに質問します。 選択肢は 3 つです。 (a) 提案されたスコア N を受け入れる、(b) 特定のスコアに変更する、(c) スコアを変更してメモを追加する。
5. 最終スコア、1 行の根拠、改善メモを記録します。

調査結果を仮スコアに反映するためのヒューリスティック

以下のしきい値は出発点です。具体的な証拠と評価基準の文言に応じて調整してください。最終判断は常にユーザーが行います。

シグナル	目安
アンチパターンの該当 0 件、関連ルールの lint エラーなし	5
小さな該当が 3 件以下で、ほぼ 1 ファイルに集中	4
複数ファイルにわたる該当が 5～15 件、またはシステム上の問題が 1 件	3
該当が 15 件以上、またはアンチパターンが広範に存在	2
アンチパターンが標準のスタイル	1

質問ごとの自動調査

各質問の調査リストは、その質問についてユーザーに何かを尋ねる前に、エージェントが最初に実行すべきものです。実行した調査とその結果を必ず伝えてください。

10 個の質問と評価基準

Q1 — Aura デザインシステムとの一貫性。 Aura のトークン、レイアウト、コンポーネント、パターンを正しく使用していますか？

調査（自動化可能）：

• grep -c '@cognite/aura' package.json — Aura が依存関係に含まれていることを確認
• grep -rlE "from '@cognite/aura'" --include='*.ts' --include='*.tsx' src | wc -l — Aura をインポートしているファイル数をカウント
• grep -rlE '#[0-9a-fA-F]{3,8}' --include='*.css' --include='*.tsx' --include='*.ts' src — ハードコードされた 16 進カラーを含むファイル
• grep -rlE '\b(rgb|rgba|hsl|hsla)\(' --include='*.tsx' --include='*.css' src — 生の rgb/hsl 値を含むファイル
• npx eslint . --ext .ts,.tsx --rule '{"aura/no-overriding-styles":"error"}' --no-eslintrc --quiet 2>&1 | tail -5、または既存の lint 出力から aura/no-overriding-styles の警告数を確認

仮スコアへの換算： ハードコードされたカラーが 0 件で、aura/no-overriding-styles の警告が 0 件なら 5。警告が少数（1～5 件）なら 4。警告が多数（15 件超）、または Aura のインポートがなければ 2～3。

• 5 非常に良い： Aura トークンをすべて正しく適用し、ハードコードされた値はありません。適切なレスポンシブサイズとページレイアウトを使用しています。Aura コンポーネントはスタイルを上書きせずに使用しています。ベストプラクティスに従っています。
• 4 良い： ほとんどの場合 Aura のトークンとコンポーネントを使用し、例外は 1～2 件の軽微なものに限られます。レイアウトの間隔はおおむね一貫しています。スタイルの上書きは最小限です。
• 3 平均的： Aura とカスタム要素が混在しています。適切な間隔を設定している箇所もあれば、値が不統一な箇所もあります。複数箇所でスタイルを上書きしています。
• 2 平均以下： Aura トークンの代わりに、カスタムカラー、タイポグラフィ、間隔を頻繁に使用しています。パターンを崩すような大幅なカスタマイズが行われています。
• 1 不十分： Aura をまったく使用していません。全体を通してカスタムカラー、フォント、間隔を使用しています。

Q2 — ナビゲーション、レイアウト、階層。 ユーザーは現在の場所を把握し、簡単に移動できますか？

調査（部分的に自動化可能 — ステップ 2 のウォークスルーに依存）：

• grep -rcE '<Route\b' --include='*.tsx' src — ルート数をカウント（ナビゲーション範囲の把握に役立ちます）
• grep -rlE 'Breadcrumb' --include='*.tsx' src — パンくずリストのコンポーネントを使用しているファイル（現在位置を示す手がかり）
• grep -rlE 'NavLink|Link to=|useLocation' --include='*.tsx' src — 使用されているナビゲーションの基本要素
• grep -rlE '<Topbar|<Sidebar|<Header' --include='*.tsx' src — ページ全体に共通するナビゲーション要素
• ルートツリー（src/routes/）を確認し、次の点を検討します。各主要ページには独自のタイトルと、前のページに戻る手段がありますか？

仮スコアへの換算： ナビゲーションの使い勝手は静的に測定しにくいため、ウォークスルーの所見を基本とします。調査結果はリスクの特定に使用します（例：パンくずリストのないルート）。

• 5: 現在地が常に明確です。前後への移動が簡単です。メニューに一貫性があります。視覚的な階層が明確です。コンテンツは論理的に流れます（F/Z パターン）。
• 4: ほとんどの場合、明確です。ナビゲーションにはおおむね一貫性があります。例外はわずかです。
• 3: わかりにくいことがあります。ナビゲーションは機能しますが、常に直感的とは限りません。階層はありますが、常に明確とは限りません。
• 2: 迷ったり、混乱したりすることがよくあります。ページ間でナビゲーションが変わります。階層が不明瞭です。
• 1: 現在地を示すものがありません。明確なナビゲーションがありません。構造に一貫性がありません。

Q3 — 明確なラベルと言葉づかい。 ボタン、入力欄、アクションには明確なラベルが付いていますか？

確認項目（自動化可能）：

• grep -rcE ">(Submit|OK|Click here|Go|Yes|No)<" --include='*.tsx' src — 曖昧なボタンラベルの数を確認します
• grep -rcE '<Button[^>]*>[[:space:]]*</Button>' --include='*.tsx' src — 空のボタン（ラベルのないアイコンのみのボタンには aria-label が必要です。Q10 で扱います）
• grep -rlE '<Label\b' --include='*.tsx' src と grep -rlE '<input\b' --include='*.tsx' src — 入力要素とラベルの数を比較します。不一致がある場合、ラベルのない入力欄がある可能性があります
• grep -rcE 'placeholder=' --include='*.tsx' src — プレースホルダーをラベルとして使うのはアンチパターンです。対応する <Label> がないのに数が多い場合は、問題の兆候です

暫定スコアへの換算： 曖昧なラベルがなく、すべての入力欄に対応するラベルがある → 5。プレースホルダーのみの入力欄が少数 → 4。複数箇所に曖昧なラベルがある → 3。

• 5: すべての要素に、明確で具体的なラベルがあります。平易で、アクションを示す言葉づかいです（「変更を保存」「項目を削除」）。
• 4: ほとんどのラベルは明確です。曖昧さはわずかです。
• 3: ラベルはありますが、曖昧な場合があります（「送信」「OK」）。不要な専門用語も一部あります。
• 2: 多くのラベルが不明瞭です。説明のない専門用語が多用されています。
• 1: ラベルがない、わかりにくい、または専門用語だらけです。

Q4 — システムのフィードバックと入力検証。 ユーザーは処理状況を把握できますか？ フォームは使いやすいですか？

確認項目（自動化可能）：

• grep -rlE 'isLoading|isPending|<Skeleton|<Loader|<Spinner' --include='*.tsx' src — 読み込み中の表示があるファイルを確認します
• grep -rlE 'isError|onError|<Alert|toast\.' --include='*.tsx' src — エラーまたは成功を知らせる表示があるファイルを確認します
• grep -rlE 'useMutation' --include='*.tsx' src — ミューテーション箇所を確認し、それぞれに onSuccess／onError ハンドラーがあるか照合します
• grep -rlE 'ErrorBoundary' --include='*.tsx' src — エラーバウンダリーを確認します（コードレビューでも照合します）
• 各ルート／機能フォルダーについて、（読み込み中の表示があるファイル＋エラー表示があるファイル）÷（データを取得するファイル）の比率は、およそ 1 であるべきです

暫定スコアへの換算： すべての取得／ミューテーションに読み込み中およびエラーの状態表示がある → 5。明示的なエラー処理のないミューテーションが少数ある → 4。対応状況にばらつきがある → 3。

• 5: 即座にフィードバックがあります。読み込み中の状態が明確です。成功／エラーメッセージが役立ちます。すべてのフィールドにラベルがあり、必須フィールドが示され、具体的なメッセージによるリアルタイムの入力検証があります。
• 4: ほとんどのアクションでフィードバックがあります。読み込み中の状態が表示されます。入力検証はおおむね役立ちます。
• 3: フィードバックはありますが、一貫していません。読み込み中の状態が表示されないことがあります。エラーメッセージは一般的です。
• 2: フィードバックは最小限です。アクションが成功したかどうか、ユーザーにわからないことがよくあります。入力検証は送信時のみです。
• 1: フィードバックがありません。失敗しても通知されません。技術的なエラーコードが表示されます。

Q5 — クリック可能な要素とインタラクション。 どこをクリックできるか、わかりやすいですか？

確認項目（自動化可能）：

• grep -rcE '<div[^>]*onClick' --include='*.tsx' src — <div> に対する onClick（セマンティックでなく、キーボード操作への対応が欠けていることがよくあります）
• grep -rcE '<span[^>]*onClick' --include='*.tsx' src — <span> についても同様に確認します
• grep -rcE 'role="button"' --include='*.tsx' src — 明示的なロールの割り当てを確認します（<div onClick> が避けられない場合は有効です）
• grep -rcE 'hover:|focus:' --include='*.tsx' src — Tailwind の hover／focus ユーティリティの使用状況を確認します（多いほど良好です）
• grep -rcE 'cursor-pointer' --include='*.tsx' src — ポインターカーソルが明示的に指定されているか確認します

暫定スコアへの換算： role のない <div onClick> がなく、hover／focus ユーティリティが多い → 5。違反が 1〜3 件 → 4。ボタン以外の要素に onClick が多数ある → 2〜3。

• 5: クリック可能な項目はすべて、クリックできることが見た目でわかります。インタラクティブな要素にはホバー効果があります。カーソルも適切に変化します。
• 4: ほとんどのインタラクティブな要素は明確です。ホバー効果もほぼ実装されています。
• 3: ホバー状態に一貫性がありません。何がインタラクティブなのか、ときどきわかりにくくなります。
• 2: クリック可能な見た目になっていないインタラクティブな要素が多く、ホバー効果もほとんどありません。
• 1: 何がクリック可能なのかわかりません。視覚的なフィードバックもありません。

Q6 — エラーの防止と回復。 ユーザーは破壊的な操作を取り消したり、キャンセルしたりできますか？

調査項目（一部は自動化可能）：

• grep -rilE 'delete|remove|archive|reset' --include='*.tsx' src | head -20 — 破壊的な操作が含まれている可能性のあるファイル
• grep -rlE 'AlertDialog|ConfirmDialog|window\.confirm' --include='*.tsx' src — 確認ダイアログの使用箇所
• grep -rcE 'variant="destructive"|destructive' --include='*.tsx' src — 破壊的なボタンのスタイル
• 破壊的な動詞を含む各ファイルについて、同じファイルまたはインポート先で対応する AlertDialog／ConfirmDialog が呼び出されているか確認します

該当なしの場合の指針： 読み取り専用のビューアーアプリ（Flows のデモでよくあるケース）には破壊的な操作がないため、「破壊的な操作なし」という根拠を添えて、デフォルトで5点とします。確認が不要なアプリに、確認機能がないことを理由に減点しないでください。

• 5: 破壊的な操作の前に確認ダイアログが表示されます。自動保存によってデータの損失を防げます。明確な取り消しまたはキャンセルの選択肢があります。または破壊的な操作がありません。
• 4: ほとんどの破壊的な操作に警告があります。自動保存または取り消し機能も一部あります。
• 3: 重要な操作には警告がありますが、取り消し／キャンセル機能は限られています。
• 2: 警告がほとんどありません。取り消し機能もなく、作業内容が失われやすい状態です。
• 1: 警告がありません。取り消し機能もなく、誤操作によるデータ損失が頻繁に発生します。

Q7 — レスポンシブデザインと複数デバイスへの対応。 画面サイズが異なっても正しく動作しますか？

調査項目（自動化可能）：

• grep -rcE '\b(sm|md|lg|xl|2xl):' --include='*.tsx' src — Tailwind のレスポンシブユーティリティの使用状況（多いほど良好）
• grep -E '<meta name="viewport"' index.html — viewport メタタグの有無
• grep -rcE 'overflow-x-auto|overflow-x-scroll' --include='*.tsx' src — 横スクロール用コンテナー（問題の兆候であることが多い）
• grep -rcE '\bw-\[[0-9]+px\]|\bh-\[[0-9]+px\]' --include='*.tsx' src — 固定ピクセルサイズの使用状況（小さな画面で表示が崩れることが多い）
• App-Brief.md の userRole を確認します。「control room でのデスクトップまたはノートパソコン」と記載されている場合、意図的にデスクトップ専用としている可能性があります。これは評価基準の「モバイルを想定していない場合、モバイルでは表示を隠す、または制限する」に沿った対応です。

草案スコアへの変換： App-Brief に基づき、アプリが設計上デスクトップ専用で、ノートパソコンの13インチまで問題なく表示される場合 → 5。レスポンシブユーティリティの使用状況が混在している場合 → 4。固定ピクセルサイズが多い場合 → 3。

• 5: デスクトップ、タブレット、モバイルのいずれでもシームレスに動作します。タッチターゲットは40px以上です。テキストが読みやすく、横スクロールもありません。タッチ操作を考慮したホバー状態になっています。または brief に基づき意図的にデスクトップ専用としており、対応する画面サイズで問題なく表示されます。
• 4: ほとんどのデバイスで問題なく動作し、軽微な問題があります。
• 3: 複数のデバイスで動作しますが、最適化されていません。小さな画面ではレイアウトに問題がいくつかあります。
• 2: モバイル／タブレットでの操作性が低く、レイアウトが崩れます。
• 1: デスクトップ専用で、モバイル／タブレットでは表示が崩れます。

Q8 — 空の状態と初回利用時の体験。 データがない場合、次に何をすればよいか明確ですか？

調査項目（自動化可能）：

• grep -rilE 'empty|no\s+(data|results|items|files|matches)' --include='*.tsx' src — 空の状態に表示する文言を含むファイル
• grep -rlE '<EmptyState|EmptyPlaceholder' --include='*.tsx' src — 空の状態を示す専用コンポーネント
• 各パネル／リストモジュール（.list( または .items.map( を含むもの）について、ユーザーに表示される文言を伴う items.length === 0 の分岐が少なくとも1つあるか確認します。あるパネルとないパネルを列挙します。
• grep -rcE 'items\.length === 0|items\.length > 0' --include='*.tsx' src — 明示的な空の状態のチェック

草案スコアへの変換： データを取得するすべてのパネルに、文言を含む空の状態の分岐がある場合 → 5。1～2か所に欠落がある場合 → 4。欠落しているパネルが多い場合 → 2～3。

• 5: すべての空状態に役立つメッセージと明確な次の手順が表示されます。初めて使うユーザーも、何をすればよいか正確にわかります。
• 4: ほとんどの空状態が役立ちます。わずかな不足があります。
• 3: 一部の空状態について説明があります。初めて使うユーザーも使い方を把握できます。
• 2: 案内のない空白ページが多数あります。
• 1: どこも空白ページです。案内はありません。

Q9 — パフォーマンスと効率性。 アプリはすばやく読み込まれますか？

確認項目（自動化可能）：

まず、最近のビルドがすでに存在するか確認します。dist/ が新しい場合に、時間のかかる再ビルドを避けられます。

find dist -maxdepth 1 -newer package.json -name '*.js' 2>/dev/null | wc -l
du -sh dist/ 2>/dev/null

件数が0の場合（最近のビルドがない場合）は、次の方法に切り替えます。

npm run build 2>&1 | tail -20

次に、残りの指標を収集します。

• grep -rcE 'React\.lazy|lazy\(' --include='*.tsx' src — ルートのコード分割（良好）
• grep -rcE 'useMemo|useCallback' --include='*.tsx' src — メモ化の使用状況（レンダリング効率の判断材料）
• grep -rlE 'useVirtual|react-window|react-virtual' --include='*.tsx' src — リストの仮想化（大きなリストに有効）
• grep -rlE '\.list\([^)]*\)' --include='*.ts' --include='*.tsx' src | xargs -I{} grep -l 'limit:' {} 2>/dev/null | wc -l とリスト呼び出し箇所の合計を比較 — ページネーションの適用範囲
• 最新の code-review-report.md にある基準 2.3（制限とページ）のスコアと照合します

下書きスコアへの換算： gzip 圧縮後のビルドが 1 MB 未満で、すべてのリストに制限があり、react-query を使用している → 5。バンドルが 1～2 MB、または一部のリストに制限がない → 4。バンドルが 2 MB 超、または上限のないフェッチが常態化している → 2～3。

• 5: 段階的にコンテンツを表示し、すばやく読み込まれます。一括操作やキーボードショートカットがあり、一般的なタスクを最小限のクリック数で実行できます。
• 4: 読み込み速度は妥当です。ほとんどのタスクが効率化されています。
• 3: パフォーマンスは許容範囲です。タスクにはある程度の手間がかかります。ショートカットはほとんどありません。
• 2: 読み込みが遅く、タスクの実行に多くの手順が必要です。
• 1: 非常に遅い、または応答しません。

Q10 — アクセシビリティ（WCAG AA 2.1）。 支援技術を使って操作できますか？

確認項目（自動化可能）：

• <img> タグの数と、alt 属性を持つ <img> タグの数を別々に数え、代替テキストの不足を特定します。

  grep -rcE '<img\b' --include='*.tsx' src
  grep -rcE '<img[^>]*\balt=' --include='*.tsx' src
  

  数に差があれば、alt がない画像があります。
• grep -rcE '<button[^>]*>[[:space:]]*<(svg|Icon)' --include='*.tsx' src — アイコンのみのボタン（aria-label が必要）
• grep -rcE 'aria-label=' --include='*.tsx' src — ARIA ラベルの使用状況
• grep -rcE 'focus-visible:|focus:' --include='*.tsx' src — フォーカススタイル
• grep -rcE 'tabIndex=\{-1\}|tabIndex="?-1' --include='*.tsx' src — タブ順序から除外されている要素（意図的な場合も、バグの場合もあります）
• eslint-plugin-jsx-a11y がインストールされている場合：npx eslint . --ext .ts,.tsx --no-eslintrc --rule '{"jsx-a11y/alt-text":"error","jsx-a11y/anchor-is-valid":"error","jsx-a11y/click-events-have-key-events":"error"}' 2>&1 | tail -10
• axe-core が利用できる場合：実行中のアプリで axe スキャンを実行し、結果を貼り付けるようユーザーに提案します。自動化で問題の候補を特定することはできますが、コントラストを検証することはできません。

下書きスコアへの換算： alt の不足が 0 件で、aria-label のないアイコンのみのボタンが 0 件、すべての箇所にフォーカススタイルがある → 5。違反が少数 → 4。全般的な不足がある → 2～3。

• 5: すべての操作をキーボードで実行できます。テキストのコントラストは WCAG AA を満たしています。フォーカスインジケーターが明確で、適切な ARIA ラベルがあり、画像に代替テキストが設定されています。タッチターゲットは 40px 以上、マウスターゲットは 20px 以上です。フォームのエラーはスクリーンリーダーに通知されます。
• 4: 要件のほとんどを満たしています。わずかな例外があります。
• 3: 基本的なキーボード操作には対応していますが、一部の機能では使えません。コントラストはおおむね許容範囲です。フォーカスインジケーターはありますが、常に明確とは限りません。
• 2: キーボード操作への対応が限られています。コントラストの問題が複数あります。フォーカスインジケーターが不明瞭です。
• 1: キーボードで操作できません。コントラストが不十分で、フォーカスインジケーターもありません。支援技術では使用できません。

ステップ 4 — 平均スコアと品質レベルを算出する

平均スコア = 10 項目のスコアの合計 ÷ 10。

ドキュメントの品質レベル表に照らし合わせます。

平均スコア	品質レベル	推奨事項
4.5 – 5.0	優秀 — リリース可能	時間をかけて軽微な改善を行う
3.8 – 4.4	良好 — 軽微な修正を行ってリリース	スコアの低い項目に対処する
3.0 – 3.7	平均的 — 改善が必要	リリース前に重大な問題を修正する
3.0 未満	大幅な作業が必要	大幅な改善が必要

flows-external-app-submit のゲート条件は 平均スコア ≥ 3.8 です。

ステップ 5 — レポートを作成する

次の構成で reviews/design-review/feedback-round-<N>/design-review-report.md を作成します。

# Design Review — <appName> — round <N>

## User and tasks

- **Primary user:** ...
- **Tasks evaluated:**
  1. ...
  2. ...
  3. ...
- **Context:** ...

## Task walkthrough findings

- **Task 1 — ...** ...
- **Task 2 — ...** ...
- **Task 3 — ...** ...

## Scores

| Question | Score | Rationale | Improvement note |
| --- | --- | --- | --- |
| Q1 Aura consistency | n | ... | ... |
| Q2 Navigation & hierarchy | n | ... | ... |
| Q3 Labels & language | n | ... | ... |
| Q4 Feedback & validation | n | ... | ... |
| Q5 Clickability | n | ... | ... |
| Q6 Error prevention | n | ... | ... |
| Q7 Responsive | n | ... | ... |
| Q8 Empty states | n | ... | ... |
| Q9 Performance | n | ... | ... |
| Q10 Accessibility | n | ... | ... |

## Summary

- Average score: <X.X>
- Quality level: <Excellent | Good | Average | Needs significant work>

## Must Fix (any score < 3)

- ...

## Should Fix (any score 3 – 3.7)

- ...

## Nice to Fix (any score 3.8 – 4.4)

- ...

Average score: の行は、必ず指定された形式のまま機械可読にしてください。flows-external-app-submit がこの行を解析します。

ステップ 6 — ゲートのステータスを表示する

書き込み後、ターミナルに次の内容を表示します。

• 平均スコア
• 品質レベル
• 結果が flows-external-app-submit のゲート条件（≥ 3.8）を満たしているかどうか
• 3.8 未満の場合は、Must Fix と Should Fix の項目を修正し、新しいフィードバックラウンドでこのスキルを再実行するようユーザーに指示する