critique

Critique Skill · 5 次元の専門家レビュー

あらゆる成果物を5つの次元で評価し、実行可能な修正案を提示する、単一ファイルの HTML「デザインレビュー報告書」を作成します。huashu-design の専門家による批評フローに着想を得ています。

使用するタイミング

• エージェント（またはユーザー）が成果物（スライドデッキ／プロトタイプ／ランディングページ）を生成した後、ユーザーが「何が問題ですか？」や「レビューしてください」と尋ねたとき
• 出力を提示する前に、エージェントが自らの出力を確認するためのセルフチェックループとして
• 同じデザインの2つのバリエーションを比較するとき

作成するもの

次の内容を含む、自己完結型の単一の <artifact type="text/html"> レビューレポートを作成します。

1. ヘッダー — レビューした成果物、日付、レビュアー（「OD · Critique skill」）、1行の評価
2. レーダーチャート（インライン SVG、ライブラリ不要）— 5つのスコアを表示
3. 5つの次元カード。それぞれに以下を含めます。
   • 0～10のスコア（評価区分：0～4 破綻 · 5～6 実用的 · 7～8 優れている · 9～10 卓越）
   • 1段落の根拠（具体的な要素／ファイル／行を示す）
   • Keep／Fix／Quick-win のいずれか1つの箇条書き
4. 最後にまとめたアクションリスト：
   • Keep — うまく機能しているもの。変更しないでください
   • Fix — 視覚的な影響が大きい P0／P1 の問題
   • Quick wins — 5～15分ででき、効果が大きい調整

5つの次元

各次元は独立しています。スライドデッキの「革新性」が9/10でも、「階層」が4/10ということはあり得ます。レポートでは、それを率直に伝えてください。興味深い問題を平均化して見えなくしてはいけません。

1. 哲学の一貫性 · 哲学一致性

成果物は明確な方向性を選び、細部のあらゆる判断（クローム／キッカー／余白／アクセント）でその方向性を貫いていますか？

確認する根拠：

• 宣言されたデザインの方向性（例：Monocle／WIRED／Kinfolk）は1つですか。それとも、3つのスタイルを無理に1つにまとめていますか？
• クローム／キッカーの語彙は一貫したトーンを保っていますか。それとも、3ページ目には「Vol.04 · Spring」とあるのに、7ページ目には「BUT WAIT 🔥」と書かれていますか？
• アクセント／セリフ体／等幅フォントは、全体を通して同じルールで使われていますか？

0～4 3つのスタイルが互いにぶつかり合っています。5～6 方向性は1つですが、要素の半分がそこから逸れています。7～8 一貫していますが、端のページで時折ぶれています。9～10 すべての要素が同じ主張を支えています。

2. 視覚的階層 · 视觉层级

初めて見る人でも、指示されずに、何を最初に、次に、3番目に読むべきか判断できますか？

確認する根拠：

• 各ページで、最も大きな文字が最も重要な内容を明確に示していますか？
• 等幅／セリフ体／サンセリフ体の役割は、情報の役割（メタ情報／本文／見出し）に合っていますか？
• 大きく目立つ要素が競い合っていませんか？ それとも、明確な第1・第2・第3の階層がありますか？

0～4 すべてが声高に主張しています。5～6 ヒーローページでは階層が機能していますが、本文ページでは崩れています。7～8 階層は明確ですが、時折要素がぶつかります。9～10 視線がまったく引っかかることなく流れます。

3. 細部の仕上がり · 细节执行

90/10の細部です。配置、行送り、大きな文字サイズでのカーニング、画像のフレーミング、フッター／クロームの仕上げ、端のケースでの余白などです。

確認する根拠：

• 大きな数値を見せるページでは、数値はベースラインに沿っていますか。それとも浮いていますか？
• grid-2-7-5 の左右のカラムは、上端が揃っていますか？
• frame-img とキャプションの比率は、ページ間で一貫していますか？
• 等幅フォントのラベルは、文字間隔と大文字のルールが統一されていますか？
• 1文字だけの行を生む、孤立した <br> はありませんか？

0～4 継ぎ当てが目立ち、ちぐはぐです。5～6 ほとんどのページはきれいですが、1～2か所に乱れがあります。7～8 よく仕上がっていますが、専門家の目には2～3か所の見落としが見つかります。9～10 雑誌品質です。手作業で印刷するタイポグラファーが思わずうなずくような細部の仕上がりです。

4. 機能性 · 功能性

成果物は意図した用途で 機能 しますか？ クリック対象、ナビゲーション、 プレゼンテーション時の視認距離での読みやすさ、コード ブロックのコピー＆ペーストのしやすさ、該当する場合はモバイル表示への対応。

確認するポイント：

• スライドデッキ：キーボード／ホイール／タッチでのナビゲーションはすべて機能するか？ iframe のスクロール時の フォールバックはあるか？
• ランディングページ：CTA はファーストビュー内にあるか？ モバイルで電話番号をタップできるか？
• ランブック：コードブロックはコピー可能か、等幅フォントを使用しているか、スマートクォートが使われていないか？
• 重要な情報は4m離れた場所からでも読めるか（大画面でのプレゼンテーション時）？

0–4 見た目は問題ありませんが、目的を果たしていません。 5–6 中核となるフローは機能しますが、エッジケースに問題があります。 7–8 通常の使用では堅牢に機能します。 9–10 防御的に設計されています — iframe／全画面表示／貼り付け／印刷にも確実に対応します。

5. 革新性 · 创新性

平均的な水準を超えていますか？ 人々を思わず引き込む要素がひとつでもありますか？

確認するポイント：

• 必須ではなかった 意外性のある レイアウト／動き／タイポグラフィ上の工夫があるか？
• あるいは、どこまでも無難で、どの制作会社が作っても同じようなスライドデッキ／ランディングページになっていないか？
• 革新性に 必然性 があるか（方向性に合っているか）、それとも後付けか（Kinfolk のスローライフをテーマにしたスライドデッキに、脈絡なく WebGL を追加するなど）？

0–4 ありきたりな AI の粗製品レベルです。 5–6 そつはありませんが、記憶に残りません。 7–8 印象に残る瞬間がひとつあり、ほかの部分もしっかりしています。 9–10 真似したくなる工夫が複数あり、そのすべてに明確な意図があります。

採点の原則（採点前に読むこと）

• 必ず根拠を示してください — 「ヒーローページの同じ行で Playfair Display と Inter Sans を混在させているため4点」と書くほうが、「一貫性がないように感じる」より適切です。根拠のない点数は認められません。
• 平均点を引き上げないでください — ページ3の問題により階層構造が5点なら、ページ1と2に問題がないからといって7点に引き上げないでください。点数は、継続して見られる最も低い水準で決めます。
• 甘く採点しないでください — 7点は 優れている という意味であり、「許容できる」ではありません。すべての項目が7点以上なら、批判的にレビューできていません。
• 革新性が低くても問題ありません — 制作物が本番用途なら、5／10でも問題ありません。適切な 保守性を理由に減点しないでください。

ワークフロー

ステップ1 — 成果物を入手する

3つの方法があります。

1. プロジェクトファイル — ユーザーが「今作った index.html をレビューして」と言った場合： プロジェクトフォルダーから開きます。
2. 貼り付けられた HTML — ユーザーがチャットにコードを貼り付けた場合： メッセージから読み取ります。
3. このターンで生成したもの — このターンで上に成果物を出力し、自己評価したい場合： 自分の <artifact> を読み直します。

HTML ファイルが複数ある場合は、どれをレビューするか尋ねてください（すべてをレビューしないでください）。

ステップ2 — 採点に必要な範囲を読む

<style> 全体に目を通してから、代表的なコンテンツブロックを6～8個読みます。frontmatter だけを見て採点してはいけません。 点数は、宣言された意図ではなく、実際に適用された デザインに基づきます。

ステップ3 — 根拠を示して採点する

5つの評価項目それぞれについて、点数と、具体的な要素を挙げた30～80語の根拠段落を書きます。行番号、クラス名、ページ番号を使ってください。

例：

Dimension: Detail execution
Score: 6 / 10
Evidence: Stat-cards on page 3 align cleanly (grid-6, 3×2), but on
page 8 the right column foot sits 2vh higher than the left because
.callout has 3vh top margin while the figure doesn't. Image captions
use mono on page 5 but sans on page 7 — pick one.

ステップ4 — アクションリストを作成する

5つの根拠段落をまとめて、以下を作成します。

• 維持する点（箇条書き3～5項目）— 次のイテレーションで壊してはいけない、具体的に機能している点。クラス／ページ／要素を挙げます。
• 修正する点（箇条書き3～6項目）— 必須の修正事項を、作業時間あたりに削減できる見た目の問題の大きさ順に並べます。各項目は1文以内にします。
• すぐできる改善（箇条書き3～5項目）— それぞれ5～15分ででき、効果が高くノイズが少ない改善（例：「ページ4の display:flex を grid に置き換えて、列のずれを修正する」）。

ステップ5 — レポート HTML を出力する

単一ファイルを作成します。

• ヘッダー：成果物名 + レビュー担当者のクレジット + 日付
• 大きなレーダーチャート（SVG）
• 5つの評価項目カードを1列または2列のグリッドで配置
• 下部にチェックボックス付きの3つのアクションリスト

有効な DESIGN.md のデザイントークンがある場合は使用し、ない場合はニュートラルなライトテーマ（オフホワイトの背景、ほぼ黒のテキスト、レーダーチャートの塗りにアクセントカラーを1色）をデフォルトとして使います。

出力仕様

<artifact identifier="critique-<artifact-slug>" type="text/html" title="Critique · <Artifact Title>">
<!doctype html>
<html>...</html>
</artifact>

成果物の前に1文（「5つの評価項目にわたって X をレビューしました。以下のレポートをご覧ください。」）を添え、</artifact> の後は 出力しないでください — チャット内でレポートの内容を言い換えないでください。ユーザーは成果物を読みます。

厳守ルール

• 毎回、5つのスコアを付けること — 一部の評価項目だけを記載したレポート（例：3項目のみ）は認められません。
• 各スコアに根拠を示すこと — 「なんとなく違和感がある」「改善が必要」といった評価は不可です。具体的な要素を挙げられない場合、そのスコアは正当化できません。
• 評価を甘くしないこと — 全体の平均が8を超えている場合は、不自然な可能性があります。もう一度確認してください。
• 同じターンで自分の成果物を評価しないこと — まずユーザーに成果物を見せる必要があります。明示的に依頼された場合（「今作ったものを批評して」など）に限り、自己批評してください。
• 単一ファイルのHTMLのみ — 外部CSS／JSは使用しないでください。すべてインラインで記述してください。
• レーダーチャートは必須 — レポートにひと目でわかる特徴的な形を与え、ユーザーが弱い軸をすぐに把握できるようにします。