jury について
juryは、スクリーンショットとブラウザーの測定結果だけを使ってウェブサイトを評価するエージェントスキルです。ソースコードや運営者の説明を見ずに、根拠付きのスコアカードと優先順位付きの修正案を作成し、Awwwardsの公式評価ではなく推定値と明記します。
主な機能
- 01スクリーンショットによる視覚評価
- 02ブラウザー測定とアクセシビリティ監査
- 03デスクトップ・モバイルの証拠収集
- 04各スコアに根拠を提示
- 05優先順位付きの改善案
- 06新しい評価者による再採点
活用シーン
- 01公開サイトの訪問者向け品質評価
- 02ローカルの本番ビルドのレビュー
- 03複数のウェブサイトURLの比較
- 04修正前後のスコア変化の追跡
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ juliobsz/ skills --skill juryインストール後、Claude Code で/juryを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/calibration.mdquality-bar.mdscripts/audit.mjsbrowser.mjsserve.mjsshoot.mjs詳細
/jury
Awwwards の審査員のようにウェブサイトを採点します。訪問者に見えるものとブラウザーで測定されるものに基づき、コードやデザインメモ、所有者の意図は一切考慮しません。すべての数値に根拠を添えたスコアカードと、優先順位を付けた修正項目のリストを返します。
Awwwards とは無関係です。 評価基準と重み付けは Awwwards が公開しているものです (awwwards.com/about-evaluation)。スコアは推定値です。その旨をすべてのカードに記載してください。
スキルのルート: このファイルがあるディレクトリ($SKILL。コマンド内では絶対パスに置き換えてください)。スクリプトの実行には Node 20 以降と Playwright が必要です。アクセシビリティのチェックには axe-core も必要です。
references/quality-bar.md にはシステム、ルーブリック、批評者向けブリーフがあります。
references/calibration.md には、この批評者と実際の審査員との測定済みの差が記載されています。これはあなたがスコアカードを作る際に使うもので、批評者には渡さないでください。
なぜブラインドなのか
サイトの目的を知っていると、画面ではなく意図を採点してしまいます。審査員が受け取るのは URL と数分の時間だけです。そのため、批評者にはスクリーンショットと測定値だけを渡します。ソースコード、DESIGN.md、README、所有者からの説明は渡しません。ユーザーがアイデアを説明した場合は、スコアを確定するまで保留し、その後で比較してください(ステップ 5)。
ワークフロー
1. 対象
- URL がある場合: デプロイ済みのサイトを採点します。
- URL がなく、ローカルプロジェクトがある場合: ビルドして、本番用の出力を配信します。開発サーバーは決して採点しないでください。圧縮されていない JS と開発用オーバーレイが WPO を損ない、コンソールのノイズも増やすためです。
- Next.js:
npm run buildを実行し、バックグラウンドでnpx next start -p 4400を実行します。 - 静的出力(Astro、Vite、Next
output: 'export'):node $SKILL/scripts/serve.mjs <dist|out> --port 4400をバックグラウンドで実行します。 - それ以外:各プロジェクト固有の本番ビルドおよび起動コマンドを使います。
- Next.js:
- 開発用 URL しかない場合(ホットリロード付きの localhost):プロジェクトがここにあるなら、代わりに本番用にビルドします。プロジェクトがここにない場合は採点し、WPO の数値は悲観的なものになると伝えてください。
- URL が複数ある場合(「自分のサイトと相手のサイト」など):それぞれについてステップ 3 から 5 を実施します。サイトごとに新しい批評者を使い、カードを並べて提示してください。
- ログインまたはパスワードが必要な場合: 採点できません。公開 URL またはローカルビルドを依頼してください。
証拠は、現在のディレクトリにある .jury/<host>/ に保存します(<host> は example.com や 127.0.0.1-4400 など)。以下では絶対パスを使ってください。
2. ツール
スクリプトは、作業ディレクトリから Playwright と axe-core を解決します。
- 現在のプロジェクトに Playwright がすでにある場合(
node -e "require.resolve('playwright')"が成功する場合)は、そこからスクリプトを実行します。 - それ以外の場合は、レビューのために他の人のプロジェクトへ依存関係を追加しないでください。プロジェクト外のキャッシュフォルダーに一度だけインストールし、そのフォルダーからスクリプトを実行します。
mkdir -p ~/.cache/jury && cd ~/.cache/jury && npm init -y > /dev/null && npm i -D playwright axe-core shoot.mjsが Chromium がないと報告した場合は、そのフォルダーでnpx playwright install chromiumを一度実行します。
3. 証拠
node $SKILL/scripts/shoot.mjs <url> --crawl --nav --out <abs>/.jury/<host>/shots
node $SKILL/scripts/audit.mjs <url> > <abs>/.jury/<host>/audit.txt
shoot.mjs --crawlは、各タイプのページ(ホーム、各トップレベルページ、各コレクションから 1 項目)に加え、404 ページを取得します。各ページについて、デスクトップは 1440、スマートフォンは 390 で撮影します。スマートフォンは中程度の性能のデバイスを想定してスロットリングします(CPU 4 倍、低速 4G)。さらに、動きを減らす設定、キーボードフォーカス、ポインター対象の通常時とホバー時の組み合わせ、アイドル時の動き、ページ遷移のフレームも取得します。ページごとに 1~2 分ほどかかります。audit.mjsは FAIL を検出すると終了コード 1 で終了します。これは検出事項であり、実行の失敗ではありません。- 1 ページだけを手早く確認するには、
--crawlを外し、監査に--max 10を渡します。カードには、1 ページのみが対象であることを記載してください。 - 採点前に、証拠が実際のものであることを確認してください。
shots/home/d-01-hero.pngとshots/summary.jsonを開きます。ボット対策画面、ログイン画面、エラーページ、またはreport.jsonにエラーがある空白のフレームが表示された場合、採点対象はありません。中止してユーザーに伝えてください。Cookie バナーは中止する理由にはなりません。訪問者にも表示されるため、採点対象に含めます。 - クロールは軽量です。監査対象の HTML ページは最大 40 ページ、スクリーンショットのページタイプは最大 8 種類です。ユーザーが所有していないサイトでは、これらの上限を増やさないでください。
4. 採点
- サブエージェントを使う場合: 新しいサブエージェントに、
references/quality-bar.mdの批評者向け説明 (「Critic brief」)を渡し、3つのパス(ルーブリック、.jury/<host>/shots/、.jury/<host>/audit.txt)を埋めます。それ以外は何も渡さず、calibration.mdは絶対に渡さないでください。すべての スクリーンショットを読み込むため、自分のコンテキストを小さく保てます。 - サブエージェントを使わない場合: 同じ説明に従い、証拠だけをもとに自分で採点し、 カードに自己採点であることを記載します。
- この会話でこのサイトを構築または編集した場合: 自己採点はブラインド評価ではありません。サブエージェントを使うか、 スコアが独立した評価ではないことをカードに記載してください。
5. 採点カード
.jury/<host>/scorecard.md に書き、同じカードをチャットにも提示します。
# <site>: jury score
Estimate, not affiliated with Awwwards. <Independent critic | Self-score>, from <n> pages on <date>.
**The idea, as the critic read it:** one sentence
**Critic overall: 6.2** (0.4 Design + 0.3 Usability + 0.2 Creativity + 0.1 Content, on the critic's strict scale)
**Jury estimate: about 7.3** (critic + 1.1, measured on two recent Sites of the Day)
**Band, from the estimate:** below Honorable Mention (under 6.5) | Honorable Mention range (6.5 to 7.1) | Site of the Day range (7.2 and up)
| Criterion | Score | Evidence |
|---|---|---|
| Design (40%) | | file or report field, and what it shows |
| Usability (30%) | | |
| Creativity (20%) | | |
| Content (10%) | | |
| Developer | Score | Evidence |
|---|---|---|
| Semantics/SEO | | |
| Animations/Transitions | | |
| Accessibility | | |
| WPO | | |
| Responsive | | |
| Markup/Meta-data | | |
## Fixes, most score first
1. [Usability] m-03: what is wrong, and what to change
2. ...
## Measured
Mobile LCP and CLS, loader time, FPS, serious axe violations, overflow, `noHoverChange`,
`colorOnly`, idle motion, audit FAIL and WARN counts (from `summary.json` and the audit).
Not scored: anything stills can't show (how motion feels, sound).
陪審員の推定値に加えるオフセットは references/calibration.md から取得します(ここに記載した時点では上記の
1.1 がオフセットです)。そのルールに従い、批評者自身の数値は採点どおりに保ち、開発者の項目には陪審員の推定値を付けません。
その後、チャットでのみ以下を行います。
- ユーザーがサイトで伝えたい内容を指定していた場合は、1行で、批評者の読み取りと 一致しているかを示します。一致していなければ、サイトはそれを伝えられていません。それが最初に修正すべき「創造性」です。
- 全体のスコアを最も引き上げる2つの修正点。
- 提案:このプロジェクトに修正リストがある場合はそれを修正するか、このプロジェクトで
/awwwardsを実行してデザインを一新します。
修正後の再採点
手順3~5を、新しい批評者を使ってもう一度実行します。以前の批評者は使わず、以前のカードも見せないでください。古い数値に引きずられるためです。新しいカードを書く前に、古いカードの名前を scorecard-<n>.md に変更し、その後、カテゴリごとの変更を示します。
ルール
- 証拠がなければ、点数もありません。各スコアにはスクリーンショットのファイル名またはレポートのフィールドを根拠として示します。各カテゴリは6点から始め、6点を超える分は証拠によって裏付けます。
- スコアを高くするための議論はしないでください。批評者が読み違えたスクリーンショットを示す場合に限り、異議を申し立てます。
- 画面上のサイトを評価します。新しいコンセプトは提案せず、今あるものを修正してください。
- 具体的に、ただし意地悪にならないようにします。「m-03:390 px でタイトルが5行に折り返されます。14vw に下げてください」のように書き、「タイポグラフィを改善する必要があります」とは書かないでください。これは誰かが作ったものです。