review-design

レビューデザイン（内部）

review-change／product-audit が会話内で作成します。どのエージェントでも、ルーティングされたステップとしてこのファイルの内容に従ってください。指摘事項のみ。編集やリファクタリングは一切行いません。

スコープ

呼び出し元が渡した差分またはパス／glob。指定がない場合は、現在の変更をデフォルトブランチと比較します。返す表の先頭にスコープを明記してください。

チェックリスト（すべての項目を評価してください。省略不可。該当なしの場合は明記してください）

✓ まずプロジェクトのデザインドキュメントを読む（例：docs/frontend/DESIGN.md）。指摘事項ごとに該当するルールを引用する
✓ 変更したコンポーネントではデザインシステムを再利用する（既存のトークンやコンポーネントと重複する独自のスタイル／色／余白を使わない）
✓ すべての新規／変更ビューがすべての状態（読み込み中、空、エラー、成功）に対応している（それぞれを引用する）
✓ プロジェクトのブレークポイントにおけるレスポンシブ動作が明記され、遵守されている（プラットフォームにブレークポイントがない場合は該当なし）
✓ プロジェクトで i18n が定められている場合、ユーザー向け文字列をハードコードしていない（i18n ドキュメントを引用する）
✓ 視覚的な階層：主要なアクションが判別でき、各ビューの主要なアクションは1つ
✓ 兄弟画面との一貫性（同じ操作には同じパターンを使用する。異なる兄弟画面を引用する）
✓ 破壊的な操作には確認が必要で、視覚的にも区別されている
✓ すべてのユーザー操作（送信、保存、失敗）にフィードバックがある（無言で処理しない）

重要性の基準

適切な能力を持つユーザーの結果が変わる場合、またはプロジェクトが明示的に定めるルールに違反している場合に限り、行を報告してください。違反するルールを、根拠と併せて記載してください。指摘事項に含めないもの：コメント／句読点の誤り、書式のみの差異、引用できるルールのないスタイル上の好み、SPEC で指定されたシナリオを超える仮定上の堅牢性。適切な変更では、Decision: PASS の空の表が期待される結果です。表を埋めるためだけの指摘は追加しないでください。

次の内容をそのまま返す

REVIEW DESIGN — scope: <scope>

| # | Finding | Sev | Evidence | Suggested fix |
|---|---------|-----|----------|---------------|
| 1 | <what>  | critical|major|minor | <file:line> | <smallest action> |

Checklist: <n> evaluated, <n> pass, <n> findings, <n> n/a (<which + why>)
Summary: <1-2 sentences>
Decision: PASS | FAIL

重大または主要な指摘が未解決の場合は FAIL、それ以外は PASS とします。軽微な指摘はブロック要因になりません。呼び出し元のトリアージステップに回してください。

完了条件

• すべてのチェックリスト項目が、根拠（ファイル名と行番号、またはコマンド出力）を示して評価されているか、理由とともに該当なしと明記されている。
• 上記の固定形式ブロックのみを、余計な内容を加えずに返し、コードを変更していない。