screenshot-critique

スクリーンショットの批評

ビジュアル成果物を承認する前に、先入観のないサブエージェントにセカンドオピニオンを求めます。 これはピクセル単位の計測ではなく、視覚的な不具合を対象とします。数値も必要な場合は compare-screenshots と組み合わせてください。比較対象がない単独のスクリーンショットでも、 シーンの指標によって、フレームにコンテンツが含まれているかどうかを確認できます。

ワークフロー

1. 確認対象となる正確な PNG/GIF フレームを撮影するか、見つけます。
2. ネイティブサイズの証拠を残し、重要な要素ごとに補助的な 2x～4x の切り抜きを作成します。全体のスクリーンショットも含めてください。端点とフェードをすべて含め、形状を変更した後は切り抜き範囲を再確認します。選択中のユニット、都市／町のスタック、旗／ポール、影、選択リング、ラベル／アイコン、道路、地形の特徴、水域、アーティファクトが発生しやすい領域を切り抜きます。「薄すぎる」「順序が違う」「遠近感がない」という指摘の場合は、切り抜きが必須です。
3. fork_context: false で新しいエクスプローラーを 1 つ起動し、全体画像、切り抜き、短く中立的なタスクだけを渡します。忠実度を評価する場合は、承認済みの参照画像とユーザー要件も含めます。履歴、実装の詳細、過去の評価、期待する回答は渡しません。
4. 確信度を添えて、目に見える具体的な不具合を指摘するよう依頼します。想定されるリスクのカテゴリとして、ユニット／プロップの奥行き順、レイヤリング、影、選択マーカーのコントラスト、地面の遠近感、旗／ポールの取り付け、ラベルのスタイルとアイコンの視認性、ぼやけ、スケール、ライティング、アーティファクト、モデルの欠落、地形の特徴の視認性、道路、水域、全体的な視認性を挙げます。
5. 返された批評を scripts/receipts.mjs で検証します。そこで検出された数値は、批評が根拠を示せない主張です。検出されたファイルは、批評で名前が挙がったものの作成されていないファイルです。いずれかを判断材料にする前に、その主張を削除するか、自分で再計測します。
6. サブエージェントの批評を自分の確認結果と照らし合わせます。重複する指摘は、優先度の高い証拠として扱います。新たに挙がった確信度の高い指摘は、好みの問題として退けず、不具合の可能性として調査します。
7. スクリーンショットを承認したと主張する前に、対応可能な指摘を仕様書、ビジュアルレポート、または次のタスク計画に記録します。

サブエージェントへのプロンプト

以下の形式を使い、角括弧内の対象を置き換えてローカル画像を添付します。

Fresh visual critique task. You have no project backstory and should only
inspect the supplied screenshots and crops. First inspect the full screenshot
for context, then inspect each crop at zoomed scale. Look for concrete
visual/layout defects in [surface], especially unit/prop depth ordering,
layering, shadows, selection-marker contrast, ground-plane perspective,
flag/pole attachment, label style/icons, blur, scale, lighting, artifacts,
missing models, terrain feature readability, roads, water, and scan
readability. Do not assume these are correct. Return a concise list of issues
you can see, with confidence and whether the issue is visible in the full image,
the crop, or both.

Describe what you see in words. You are looking at these images, not measuring
them, so state no pixel value, luminance, percentage, ratio, count, or offset
unless you ran a command that produced it and you quote that command and its
output beside the number. "The hem reads clearly darker than the floor beside
it" is a finding; "44.0 versus 33.6" without a receipt is a fabrication. The
same goes for files: name no artifact you did not create with a tool you
actually have.

起動設定：

• agent_type: explorer
• fork_context: false
• スクリーンショットは local_image 項目として添付します
• ユーザーが明示的に指定しない限り、モデルのオーバーライドは省略します
• 数値を求める場合は計測ツールを付与してください。Receipts を参照してください

根拠

批評に書かれた数値は、根拠のある数値か推測値のどちらかですが、いったん書き記されると両者は見分けがつきません。画像を渡され、不具合を尋ねられたエージェントは、質問の形式に合わせて回答します。裾がどれくらい暗いか尋ねれば、輝度の平均値を返します。回答がそのような形になっているからであり、何かを測定したからではありません。推定が近いこともあれば、所見が逆になることもありますが、レポートからはどちらなのか分かりません。しかも数値であるがゆえに、まさに最も強い証拠のように読めてしまいます。同じ反射で、作成したと主張する切り抜き画像の名前を挙げたり、その内容を書き出したりします。

• ツールの機能を出力の要件に合わせます。 起動する前に、自分のプロンプトを読み返し、要求した各主張をどのツールが生成するのか確認してください。画像を見せられてもシェルを使えない評価者が報告できるのは、見えていることだけです。測定値が必要なら、測定できるツールを使えるようにし、プロンプトでその使用を明示してください。そうでなければ、測定値を求めるのはやめてください。
• コマンドを伴わない数値は所見ではありません。 すべての数値には、その数値を生成したコマンドと、そのコマンドの出力を添え、並べて読めるようにする必要があります。これを満たさない所見は、割り引くのではなく削除してください。
• 検証者の目を信じず、検証してください。 所見を読む前に、返されたレポートに対して scripts/receipts.mjs を実行します。node scripts/receipts.mjs <report.md> のように実行してください。根拠のない数値が先に説得力を持ってしまうのを防げます。終了コードが 0 以外になり、裏付けのない数値と、レポートに記載されているのに作成されていない各ファイルが出力されます。scripts/receipts.eval.mjs は独立した評価スクリプトで、評価内で作成された、正解が構成上既知のレポートを対象に、両方向のケースを固定して検証します。チェッカーを変更したら実行してください。また、失敗するケースを通すために、根拠として認める条件を決して広げないでください。
• どちらが証明なのかを理解してください。 ファイルのチェックは証明になります。ディスク上でパスを解決し、記載された sha256 を再計算するため、捏造された切り抜き画像はここで検出されます。一方、数値のチェックは実行の証明ではなく、出典の確認です。数値とともにコマンドの実行が示され、その出力にその数値が含まれているかを確認するため、実行記録全体が捏造されたレポートも通過します。静的なテキストを読むだけでは、捏造された実行記録と本物の実行記録を区別できません。チェックに問題がなくても、それが意味するのは主張の出典をたどれ、ファイルが実在するということだけで、何かが実行されたということではありません。数値に重みを持たせる必要があるなら、成果物とハッシュを求めてください。
• 序数を表す言葉も所見ですが、数値はそうではありません。「明らかに暗い」「パネルのおよそ 3 分の 1」「左端が切れている」は、目で見て正直に報告できる内容です。計算をもっと慎重にさせようとするのではなく、批評をこの表現に寄せてください。
• 測定を伴うパスは別途実行します。 言葉で数値を示す根拠が整っているなら、compare-screenshots を使って自分で測定するか、同じ根拠のルールを適用して、シェルを使える状態で批評者を再実行してください。レポートの作成者に自分の数値を再確認させて、レポートを修正してはいけません。

ルール

• 「修正済み」とする前に必須： ユーザーから報告された視覚的な不具合を、自分で確認しただけで修正済みと判断しないでください。修正直後は、目が修正内容に引きずられます。候補画像を先入観のない状態で批評してから判断してください。見過ごしたくなる「軽微な残存」は、まさにその批評で検出するものです。（失敗例：「修正済み」の空が、先入観のないエージェントには地形メッシュの裏面で空全体が埋まっていると指摘されました。）
• 報告者の視点を再現してください。 ユーザーがスクリーンショットを提供した場合、批評にはその視点でのキャプチャ（同じカメラ／ズーム／位置、または再現可能な範囲でできるだけ近いもの）を含めてください。ユーザーの視点でだけ見える不具合は、自分の視点では見えないことがあります。選んだ検証用の視点は補足であり、代わりにはなりません。
• 批評の前に、変更が実際に反映されたことを証明してください。 まず候補画像と変更前のベースラインをバイト単位／ピクセル単位で比較してください。変化のない画像を批評しても、何も変更されていないことを「検証」するだけです。（失敗例：パレットの処理が本番レンダリング経路に反映されず、変更前後がバイト単位で同一であることを差分だけが検出しました。）
• 選別せず、キャプチャ一式をすべて引き渡してください。 キャプチャしたすべての状態、すべてのビューポート、デスクトップとモバイルを含めてください。どの画像を見せるか選ぶことは、先入観のない確認で取り除こうとしているのと同じ偏りを生みます。問題ないとすでに思っている画像を選び、状態の悪い画像を除外してしまいます。手動では到達しにくい状態も、省略せず、決定論的に再現してキャプチャしてください。
• サブエージェントが使えない場合は、自分で反対の立場から検討してください。 評価対象の各機能について、スクリーンショットに見える情報だけを根拠に、問題があるという最も強い主張を一文で書いてから判断してください。先に主張を書くことで、敵対的な検討になります。先に判断して後から正当化するのは、このスキルで置き換えようとしている先入観のある確認です。検証可能な推論となるよう、これらの文をレポートに含めてください。
• サブエージェントには、見つけてほしい不具合を事前に伝えないでください。
• 古いレポートやベースライン画像ではなく、現在の候補スクリーンショットを使ってください。
• 小さな視覚的特徴の確認に、ページ全体のレポート画像の縮尺を頼りにしないでください。プレイヤーが読み取る正確な箇所（選択中の軍／都市、ラベル／アイコンのまとまり、旗、影、リングの縁、道路の交差点、地形の特徴を含む領域、水域のラベル、不審なデバッグ表示／アーティファクトの領域）を切り抜いて添付してください。
• サブエージェントが、全体画像では見えにくい、または見えない問題を切り抜き画像で指摘した場合、ゲーム内でプレイヤーがその縮尺までズームできるなら、実際のユーザビリティ上の不具合として扱ってください。
• アニメーションでは、まず決定論的に生成した短い静止フレームのセットを添付してください。GIFは人による確認に役立ちますが、静止フレームのほうが具体的な不具合を指摘しやすくなります。
• 見出しで合格としても、報告された小さな不一致や不確実性をなかったことにはできません。Reference Landmarksを使って解決してください。セカンドオピニオンは、直接確認やリグレッションゲートの代わりにはなりません。
• メインエージェントが見落とした問題をサブエージェントが見つけた場合は、その失敗モードを該当する機能計画または視覚チェックリストにすぐ追加してください。