slop-eval

Slop Eval

skill-evaluation がスキルを評価するのと同じ方法でデザインを評価します。すべての指摘に具体的な根拠を示し、すべての評価軸に 0～100 のスコアを付け、計算はスクリプトで行い、出力は構造化レポートにします。印象だけで評価することはありません。

兆候のカタログは references/tells.md にあります。チェックを始める前に読んでください。 肯定的な評価基準（シグネチャーの公式、一貫性のチェック、slop→premium の対比、「Adding Soul」ガイド）は references/premium-markers.md にあります。評価軸 7～8 の採点前、および修正案を作成する際に読んでください。 デザインコンテキストガイドは references/contexts.md にあります。評価対象のデザインの種類に応じて、優先順位と許容範囲を調整するために読んでください。

ソース

• The pols.dev anti-slop design law — 兆候のカタログ、絶対ルール、シグネチャーの公式の出典です。
• 手法は以下の skill-evaluation を参考にしています（根拠の提示、加重評価軸、スクリプトによる採点、失敗モードの診断）。

パラメーター

パラメーター	説明	デフォルト
target	評価対象：ライブ URL、スクリーンショット、コードパス、または Figma のエクスポート	ユーザーに確認
brief	ブランド概要、またはデザインに反映されたユーザーの明示的な指示	なし
context	デザインの種類：landing、saas、editorial、ecommerce、auto	auto
output	レポートの保存先パス	./SLOP-REPORT.md
compare	トラッキングモード（経時変化の追跡）用の以前のレポートのパス	なし

レポートはユーザーが使用している言語で作成してください。カタログ内で検索しやすいよう、兆候の ID と名前は英語のままにしてください。

評価モード

標準モード（デフォルト）

デザインを 1 件評価します。スコア、兆候、セクション台帳、優先順位付きの修正案を含む Slop Report を作成します。

比較モード

異なる 2 件のデザインを並べて評価します（例：競合分析、A/B バリアント）。別の対象または既存のレポートを指す --compare を追加してください。

トラッキングモード

同じデザインを経時的に評価して、改善度を測定します。次の場合に使用します。

• 毎週またはスプリントごとのデザインレビューを行う
• リデザイン後の進捗を測定する
• 修正によって実際にスコアが変化したかを検証する

使用方法：

# First evaluation — establishes baseline
slop-eval --target https://site.com --output ./reports/baseline.md

# Later evaluation — tracks evolution
slop-eval --target https://site.com --output ./reports/week-2.md \
  --compare ./reports/baseline.md

トラッキングモードでは、レポートに以下が追加されます。

• 傾向を示すスコア推移表（✅ 改善／⚠️ 悪化）
• 解消された兆候（修正されたもの）
• 新たな兆候（追加されたもの）
• 後退（悪化した評価軸／セクション）
• セクション台帳の推移
• 進捗指標（週あたりの解消された兆候数、スコア改善率）
• 次の反復に向けた推奨事項

トラッキング出力の全形式については、references/output-template.md を参照してください。

根拠を確認できる手段

検証できる内容は、提供された情報によって異なります。確認できなかった項目は決して採点せず、検証不能と記載して除外してください（skill-evaluation の N/A と同様です）。

手段	検証できること	検証できないこと
コード（CSS/JSX/HTML）	フォント、16 進数カラー値、グラデーション、シャドウ、角丸、opacity:0 によるゲーティング、アイコンのインポート、レイアウトの骨組み	視覚的な中央揃え、レンダリング後のコントラスト、継ぎ目、コントロールが反応するかどうか
スクリーンショット	視覚要素全般：配色、タイポグラフィ、レイアウト、配置、中央揃え、クリッピング、コントラスト、継ぎ目	ホバー／スクロール時の動き、反応しないコントロール、非表示コンテンツの罠、レスポンシブ動作
ライブ URL（閲覧＋スクリーンショット）	上記すべてに加え、インタラクション、動き、ファーストビュー内の表示要素	実際に操作しなかったもの

コードがある場合は、目視する前に grep してください：fonts.googleapis|next/font、 lucide-react、linear-gradient、box-shadow、border-radius: *9999、 backdrop-filter、opacity: *0、initial={{ *opacity: *0、 overflow: *hidden、clip-path、position: *fixed。該当箇所は調査の手がかりであり、断定の根拠ではありません。記録する前に、カタログの項目と照らし合わせて確認してください。

エビデンス取得手順書

target が何かに応じて経路を選び、必ず最後にエビデンス一覧 （取得したもの、検証不能なもの）を作成してください。これはレポートのヘッダーに反映されます。

ライブ URL — 最も情報量の多い経路です。アクセス可能な場合は、常にこちらを優先してください。 このセッションで利用できるブラウザー自動化（Playwright や Chrome DevTools などのブラウザー MCP、または MCP がない場合の 代替手段である npx playwright screenshot）を使い、すべての成果物をスクラッチパッドに保存してください。これにより、所見で file + region を参照できます。

1. デスクトップ（1440×900）とモバイル（390×844）で読み込み、ネットワークがアイドル状態になるまで待ちます。
2. スクロールする前に、読み込み直後の両ビューポートをフルページで撮影します。スクロールで表示されるまで opacity:0 のままのセクションは、ここでは空白として写ります（M1 のエビデンス）。
3. ページの先頭から末尾までスクロールし、もう一度フルページを撮影します。2 枚を見比べ、スクロールで表示されるコンテンツ、継ぎ目（C11、X13）、折り返し位置の要素の帰属（L16）を確認します。
4. インタラクションを確認します。メイン CTA、カード 1 枚、ナビリンク 1 つにカーソルを合わせ（M2–M4）、すべてのタブ、アコーディオン、トグル、ボタンをクリックし（M8）、ページ内を Tab キーで移動して視認できるフォーカスリングを確認します（X14）。
5. 端で切れているもの（X2）、円形やタイル状の数字とアイコン（X1）、横並びの価格列（X3）、ボタンのラベル（X5）を 2 倍に拡大して切り抜きます。
6. コード経路の grep に必要なレンダリング済みソースを取得します。ネットワークパネルまたは <link>／@font-face からフォント名を、スタイルシートから計算済みの hex 値を取得します。

ブラウザー自動化を利用できない場合 → HTML／CSS を取得（curl）してコード経路の確認を実行し、ユーザーにデスクトップとモバイルのフルページ画像を依頼します。画像が届くまでは、視覚のみで判断する項目とインタラクションの確認項目をすべて検証不能とします。生の HTML から視覚項目を採点してはいけません。

スクリーンショット — 各画像を確認します。部分的な切り抜きしか提供されていない場合は、全項目を評価する前にデスクトップとモバイルのフルページ画像を依頼してください。ヒーロー部分だけの画像では、L11、L15、または一貫性の評価軸を裏付けられません。すべてのインタラクション確認（M1、M8、X14、ホバー時の挙動）は検証不能です。

コード経路 — grep を実行して、該当したすべてのファイルに加え、レイアウト／ページのコンポーネントとグローバルスタイルを読みます。プロジェクトをローカルで実行できる場合は、開発サーバーを起動し、ライブ URL の手順書に従って続行します。コードとライブレンダリングの組み合わせだけが、すべての項目を検証できます。

Figma エクスポート — 視覚的な特徴についてはスクリーンショットと同様に扱います。さらに、フォント、hex 値、間隔はファイルから正確に取得できます。プロトタイプが共有されていない場合、モーションとインタラクションの評価軸は検証不能です（評価軸 5 は NA と採点します）。

評価軸と重み

#	評価軸	重み	採点対象
1	色と光	2x	特徴 C1–C15
2	タイポグラフィとコピー	2x	特徴 T1–T10、W1–W3
3	コンポーネントと装飾	1x	特徴 K1–K27
4	レイアウトと構成	2x	特徴 L1–L21
5	モーションとインタラクション	1x	特徴 M1–M8
6	実装と仕上がり	2x	特徴 X1–X14
7	独自性とユニークさ	3x	7 要素の公式（肯定的な評価基準）
8	一貫性	2x	4 項目の確認（肯定的な評価基準）

評価軸 7 の重みが最も大きいのは意図的です。特徴リストを避けること自体が、依然として手抜きにあたるというのが、この規則の最も根本的な原則です。特徴がひとつもなく、独自性もないページは、節度を言い訳にして未完成のまま放置された仕事です。

スコアリング

軸 1～6（テルをカウント）。 軸ごとに確認済みのテルを重大度別に数え、 次の式で計算します：score = max(0, 100 − 30·critical − 15·major − 5·minor)。
scripts/score.py axis CRIT MAJOR MINOR を実行してください。手計算はしないでください。1 つのテルは 1 回だけ数えます。あるパターンが複数のセクションで繰り返されていても、テルは 1 つです（根拠に繰り返しを記載してください。カタログに記載がある場合、繰り返しによって minor から major に格上げされることがあります）。

軸 7（シグネチャ）。 premium-markers.md の評価基準に従って、7 つのフォーミュラ要素をそれぞれ 0（なし）、50（試みているが弱い）、または 100（強い）で採点します。軸のスコアはその平均です。

軸 8（一貫性）。 4 つの一貫性チェックを同じく 0／50／100 で採点し、その平均を取ります。

累積ルール。 1 ページに major のレイアウトテルが 3 つ以上ある場合、軸 4 の上限は 40 です。既知のひな形を組み合わせただけのページは、各ブロックがどれほど整っていても雑です。

ゲート（総合スコアの実行時に --cap として指定します）：

• シグネチャゲート： 軸 7 が 40 未満の場合、総合スコアの上限は 59 です（最高評価は C）。余白がどれほど整っていても、シグネチャのないページは救えません。
• 絶対ルールゲート： critical のテルが 1 つでも確認された場合、総合スコアの上限は 69 です（実行上の問題がある場合、評価 A にはなりません）。

総合スコアと雑さ指数。

overall    = sum(axis_score × weight) / sum(weight)   # capped by gates
Slop Index = 100 − overall

scripts/score.py overall 1:80:2 2:65:2 ... [--cap 59] [--cap 69] を実行します。 検証できない軸は NA とし、どちらの合計からも除外します。--fail-below N を指定すると、CI ゲートのためにゼロ以外で終了します。たとえば、プレビュー環境へのデプロイに対する PR のゲート設定は次のとおりです。

# .github/workflows/slop-gate.yml (step excerpt)
- name: Slop gate
  run: |
    # run slop-eval against $PREVIEW_URL, export each axis score, then:
    python3 skills/slop-eval/scripts/score.py overall \
      1:$A1:2 2:$A2:2 3:$A3:1 4:$A4:2 5:$A5:1 6:$A6:2 7:$A7:3 8:$A8:2 \
      --fail-below 40

評価スケール

評価	総合スコア	雑さ指数	判定
A	80–100	0–20	プレミアム — 意図的で、独自性があり、適切に実装されている
B	60–79	21–40	よく検討されている — ほぼ意図的だが、一部にデフォルト設定がある
C	40–59	41–60	ありきたり — 整っているが、テンプレート的、または独自性がない
D	20–39	61–80	雑 — プリセットを組み合わせている
F	0–19	81–100	完全に雑

絶対ルールのチェック

実装に関する 6 つの法則をそれぞれ合格／不合格／検証不能で判定し、専用の 表に報告します。不合格が 1 つでもあれば critical のテルとなり（該当する軸でカウントされ、絶対ルールゲートも適用されます）：

1. デフォルトでコンテンツが見える — 入場アニメーションによって何も隠されていない （opacity:0 + 表示）（M1）
2. 切り抜きを避ける — クリップ、切り欠き、オーバーフロー、固定高さによってテキストやコントロールが切れていない （X2、X11）
3. 並列要素の位置合わせ — 比較対象となる列のベースラインを揃え、ボタンを適切な位置に固定する （X3）
4. 正しく中央揃えする — 中央揃えが意図されたすべての要素を、数学的にも視覚的にも中央に配置する （X1）
5. 十分なコントラストを確保する — すべてのテキストで、背景との間に実際の値の差を確保する （X5）
6. コントロールが機能する — インタラクティブに見えるすべてのコントロールが応答する （M8）

ワークフロー

1. 証拠を集める — 上記の証拠収集 SOP に従って target を調査します。証拠一覧に、取得したものと検証不能なものが記載されたら完了です。
2. references/tells.md を読む — 照合に使うカタログです。
3. 軸 1～6 を調査する — カタログをグループごとに確認します。根拠を示すか、記録しないか：具体的な根拠（16 進数値、フォント名、file:line、またはスクリーンショット内の領域）がある場合に限り、テルを記録します。根拠がなければテルはありません。各候補をプレミアム版の注記と照合します。パターンを丁寧に作り込んだものはテルではありません。すべてのカタロググループを調査し、記録したすべてのテルに引用が付いたら完了です。
4. 絶対ルールをチェックする — 6 項目すべてを、根拠とともに合格／不合格／検証不能で判定します。
5. 軸 7～8 を採点する — references/premium-markers.md を読み、7 つのシグネチャ要素と 4 つの一貫性チェックを採点し、それぞれに 1 行の理由を付けます。11 項目すべてにスコアと理由を付けたら完了です。
6. 計算する — テルをカウントする各軸について score.py axis を実行し、続いてウェイトと適用対象の --cap を指定して score.py overall を実行します。手計算は絶対にしないでください。
7. レポートを書く — references/output-template.md を読み、その構成を正確に output に出力します。最後に、スコアを最も大きく改善する優先度順の修正を 3～5 件記載します（ウェイト適用後の改善幅が大きいものから順にします。シグネチャが欠けている場合は、通常、単独のテル 1 つより優先度が高くなります）。

注意点

• ブリーフはルールに優先します。 ユーザーやブランドが選択（色、レイアウト、効果）を明示的に指示した場合、それは兆候ではありません。ルールそのものが、ユーザーの指示を100％優先すると定めています。デザインが明らかにブリーフに沿っている場合は、ブリーフを確認してください。除外した兆候は、適切な正当化タグとともにレポートに記載してください（以下の除外システムを参照）。
• 文脈によって兆候の意味は変わります。 実データにモノクロを使うのは適切です。実際の製品らしく内容が入ったウィンドウは特徴であり、偽ウィンドウの兆候ではありません。テクスチャのある細かなマイクログリッドは上質ですが、ページ全体の方眼紙は粗雑です。記録する前に、必ず上質なペアを確認してください。
• きれいな見逃しを評価しないでください。 粗雑さを避けようとしたデザインで最もよくある失敗は、兆候がゼロでも特徴が弱いことです。そのために特徴のゲートがあります。情け容赦なく適用してください。
• 深刻度を厳密に判断してください。 クリティカルは、壊れている場合（6つの絶対ルール）にのみ使います。青紫のグラデーションは目立ちますが、壊れてはいません。メジャーです。
• 軸をまたいで重複させないでください。 切り取られたグローのように、2つの軸に当てはまりそうな兆候もあります（色と実行）。カタログでは各兆候を必ず1つの軸に割り当てています。その軸でのみ数えてください。
• ポートフォリオの兆候。 L19（自分の定番スタイルの再利用）は、確認に同じ作者の過去の作品が必要です。それがなければ推測せず、「検証不可」としてください。

除外システム

除外する兆候には、すべて正当化タグを付ける必要があります。タグのない兆候は、例外なくカウントされます。これにより監査証跡が作られ、安易な除外を防げます。

正当化タグ

タグ	使用する状況	例
// BRIEF:	クライアント／ステークホルダーがこの選択を明示的に指示した	// BRIEF: client requested blue-purple gradient as brand identity
// DESIGN DECISION:	具体的な理由を伴う、文書化されたデザイン上の決定	// DESIGN DECISION: countdown is real — sale ends 2026-08-01
// CONTEXT:	デザインの文脈上、このパターンが許容される	// CONTEXT: mono typeface is appropriate for code snippets in SaaS docs
// PREMIUM PAIR:	これは粗雑な版ではなく、練り上げられた版である	// PREMIUM PAIR: glass effect has proper refraction, edge dispersion, tuned shadows

有効な除外と無効な除外

有効な除外：

| C1 | Blue→purple gradient | `// BRIEF: brand guidelines v2.3 specify #6366f1→#8b5cf6` |
| K14 | Countdown timer | `// DESIGN DECISION: real sale ends 2026-12-31, verified in CMS` |
| T4 | Mono as house voice | `// CONTEXT: SaaS product with code-heavy documentation` |
| K25 | Glass effect | `// PREMIUM PAIR: proper backdrop blur, chromatic dispersion, directional light` |

無効な除外（兆候は引き続きカウントされます）：

| C1 | Blue→purple gradient | "we liked it" | ❌ Not a justification
| K9 | Default CTA pair | "it's our style" | ❌ Too vague
| L1 | Default hero stack | "approved by team" | ❌ Who? When? Why?
| K6 | Kitchen-sink card | "industry standard" | ❌ Slop IS the industry standard

除外数の上限

• 除外が5件超 → 1件ずつ確認してください。大量の除外は、ブリーフに従っていないか、評価者の判断が甘すぎることを示しています。
• 除外が10件超 → 何かがおかしい状態です。ブリーフがほぼすべてを許容している（その場合、評価する意味は何でしょうか）か、スコアを水増しするために除外が使われています。
• 特徴的な要素の除外 → 正当であることはほとんどありません。S1〜S7を除外した場合、そのデザインには定義上、特徴がありません。

レポートでの除外の記録

「除外した兆候」テーブルでは、次の形式を使います。

## Excluded tells

| ID | Tell | Exclusion reason |
|----|------|------------------|
| C1 | Blue→purple gradient | `// BRIEF: brand guidelines v2.3 specify #6366f1→#8b5cf6` |
| K14 | Countdown timer | `// DESIGN DECISION: real sale ends 2026-12-31, verified in CMS` |

**Exclusion summary:** 2 tells excluded (1 BRIEF, 1 DESIGN DECISION)

除外への異議申し立て

他の人の粗雑さに関するレポートを確認するときは、まず除外を確認してください。

1. タグが付いていますか？ タグがなければ、兆候はカウントされます。
2. タグは適切ですか？ // BRIEF: には実際のブリーフへの参照が必要です。
3. 理由は具体的ですか？ 理由が曖昧なら、兆候はカウントされます。
4. 除外数は妥当ですか？ 5件を超える場合は、精査が必要です。

Jev による評価（任意）

ハーネスが TypeSafe Jev にアクセスできる場合、主観的な採点手順（軸7〜8）と品質チェックリストの検証に Jev を使用して、評価の較正を行えます。

Jev を使用する箇所：

• 軸7（特徴） — 0／50／100の評価基準による7つの採点質問（S1〜S7）
• 軸8（一貫性） — 0／50／100の評価基準による4つの採点質問（H1〜H4）
• 品質チェックリスト — 二値検証用の27個の Noul 質問

Jev を使用しない箇所：

• 軸1〜6 — 兆候の検出は事実に基づきます（根拠を示すか、除外する）。算術処理は score.py が行います。
• ゲートと上限 — score.py が適用する決定論的なルールです。

検出プロトコル

1. MCP Tool `jev_eval` configured in harness → use it
2. Model `typesafe/jev-latest` via OpenRouter → request it
3. Auxiliary slot (Hermes/Devin/Codex) with Jev → delegate
4. Fallback → inline scoring via current LLM using premium-markers.md rubric

統合ファイル

ファイル	説明
scripts/jev_questions.json	型付き質問 38 件（Score 11 件 + Noul 27 件）
references/jev-integration.md	プロトコル全体、リクエスト／レスポンス形式

完全なドキュメント：検出の詳細、ハーネス固有の手順、リクエスト／レスポンスの構造については、references/jev-integration.md を参照してください。

---

品質チェックリスト

納品前の最終ゲートです。すべての項目を確認してください。1 つでも失敗すれば、レポートは未完成です。これは自己評価の基準であり、提案ではなく必須のゲートとして扱ってください。

スイープ前の確認

• 証拠の一覧が完成している — 取得したもの（コード、スクリーンショット、公開 URL）と検証不能なものを記録している
• 概要が記載されている — 提供されている場合はレポートのヘッダーに要約し、提供されていない場合は「概要なし」と記載している
• デザインのコンテキストを特定している — どのような種類のデザインか（ランディングページ、SaaS ダッシュボード、エディトリアル、E コマース）。references/contexts.md を読み、優先度と許容範囲を調整している
• すべてのリファレンスファイルを読んでいる — スイープを開始する前に、tells.md、premium-markers.md、contexts.md を読み込んでいる

スイープ中の確認

• 根拠の提示または除外を徹底している — 記録された各兆候に ID + 重大度 + 具体的な根拠（16 進数値、フォント名、file:line、またはスクリーンショット上の領域）がある
• プレミアム版との照合を実施している — 兆候を記録する前に、そのパターンが洗練されたプレミアム版ではないことを確認している
• 移植可能性テストを適用している — 判断が難しいケースでは、「この要素は変更せずに別のサイトへ移せるか？」と確認している。移せる場合 → 兆候。移せない場合（そのブランド固有のもの）→ 兆候ではない
• 正当化テストを適用している — 判断が難しいケースでは、「尋ねられた場合、デザイナーはこの選択を具体的な理由で正当化できるか？」と確認している。できない場合 → 兆候。粗雑なデザインは正当化できませんが、意図的な選択は正当化できます。
• セクションを明記している — Section Ledger に記載する各兆候を、特定のセクション（Hero、Features、Pricing、Footer など）に割り当てている
• 重大度を適切に判断している — 「重大」は絶対ルールへの違反にのみ使用し、重大度を不必要に引き上げていない

除外の確認

• 除外理由が記録されている — 除外した各兆候に、// BRIEF: または // DESIGN DECISION: による理由がある
• 除外が正当である — 「気に入った」「見た目がよかった」は有効な除外理由ではありません。明示的な概要の指示、または具体的な理由を伴う、記録済みのデザイン上の決定のみが有効です。
• 除外数が妥当である — 5 件を超える兆候を除外した場合は、それぞれを再確認してください。大量の除外は、兆候が該当しないのではなく、概要に従っていない可能性を示します。

スイープ後の確認

• 検証不能な項目すべてに印が付いている — 暗黙に合格扱いしたり、スキップしたりしていない
• 6 件すべての絶対ルールを報告している — 根拠とともに合格／不合格／検証不能を示している
• 11 件すべての特徴／一貫性項目を採点している — 0／50／100 と、それぞれ 1 行の根拠を記載している
• Section Ledger が完成している — 主要な各セクションに、兆候の件数と対応を添えて判定（CLEAN／SUSPICIOUS／INFLATED／CRITICAL）を記載している
• ゲートを正しく適用している：
  • 特徴ゲート：Axis 7 が 40 未満の場合、全体スコアの上限は 59
  • 絶対ルールゲート：重大な違反が 1 件でもある場合、全体スコアの上限は 69
  • 複合上限：重大なレイアウト上の兆候が 3 件以上ある場合、Axis 4 の上限は 40
• 計算はスクリプトのみで行っている — すべての採点に score.py を使用し、手計算していない

レポートの確認

• テンプレートに厳密に従っている — 構造が output-template.md と一致している
• 修正案を重み付きの影響度順に並べている — 特徴に関する問題（重み 3 倍）は、通常、単一の兆候より上位になる
• 言語が正しい — レポートはユーザーの言語で記載し、兆候 ID は英語のままにしている

最終セルフ監査

提出する前に、次の点を自問してください。

• 「見落とした明らかな粗雑さはまだないか？」 — 見た目から明らかに粗雑だとわかるのに指摘できていないものがあれば、それをカバーする兆候を探すか、カタログの不足点として記録してください。
• 「過剰に修正していないか？」 — 明らかに粗雑なデザインに対する報告が簡素すぎるなら、兆候を見落としている可能性があります。洗練されたデザインに対する報告が膨らんでいるなら、誤検出の可能性があります。
• 「他の人が書いた報告でも信頼できるか？」 — 同僚の成果物をレビューするつもりで報告を読んでください。すべての主張に根拠がありますか？