web-design-guidelines

書いた画面のコードを、共通の基準で点検したいときです。

引き金になる言葉

引き金になる言葉が説明文に並んでいます。「UI をレビューして」「アクセシビリティを確認して」「デザインを監査して」「UX をレビューして」「ベストプラクティスと照らして」。

★基準を手元に持っていない

このスキルで最も重要な性質です。本文の 4 段の流れの 1 段目がこれです。

毎回のレビューの前に、新しい基準を取得せよ。

https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md

規則の中身は SKILL.md に入っていません。同梱ファイルは無く、本文は 1KB 台（1,231 バイト）です（2026-10-09 確認）。

最後の行が判断に効きます。レビューの基準が実行時に決まるので、「何を指摘されるか」を入れる前に確かめられません。取得先を自分で開いて読んでおくのが確実です。

流れが 4 段だけ

1. 基準を取る取得先から最新の基準を取る
2. ファイルを読む指定されたファイルを読む（指定が無ければ聞く）
3. 照らす取得した基準のすべての規則と照らす
4. 指摘を出すfile:line の簡潔な形で指摘を出す

2 段目が親切です。ファイルの指定が無ければ、どれをレビューするか聞きます。勝手に全部読みません。

4 段目の形も指定されています。取得した基準の中に出力の形式も書かれていて、ファイル名と行番号で返る形です。修正箇所に辿れます。

引数の当てが付いている

frontmatter に argument-hint: <file-or-pattern> があります。ファイルかパターンを渡す前提だと宣言されているので、src/components/*.tsx のような渡し方ができます。

通信できない環境

通信できない環境では動きません。基準を毎回取りに行く作りです。社内の閉じた環境では最初の段で止まります。

ブランドの表現の正解を決めたいとき

ブランドの表現の正解は決めてくれません。これは共通の基準への適合を見るスキルです。配色や字体の方向を決めたいなら frontend-design や ui-ux-pro-max の側です。

実際のブラウザでの確認の代わり

実際のブラウザでの確認の代わりにはなりません。読むのはコードです。動く画面の挙動や表示速度は webapp-testing のような側で確かめてください。

指摘の網羅性は取得した基準に依存する

指摘の網羅性は取得した基準に依存します。基準が変われば指摘も変わります。同じコードを 2 回レビューして、違う結果が出ることがあります。

設計そのものの是非

設計そのものの是非は扱いません。「この画面構成が正しいか」ではなく「基準に沿っているか」を見ます。

外部への通信の記述がある

SKILL.md の解析では、外部への通信の記述が見つかっています。同梱ファイルはありません（2026-10-09 確認）。

基準を GitHub から取ってくる

社内の規程で外部への通信を制限している場合は、取得先を許可する必要があります（スキルを入れる前に確認すること）。

コードを外部へ送る指示は無い

レビュー対象のコードを外部へ送る指示は、原本にありません。読むのは手元のファイルです。ただし使っている取得の道具の設定は自分で確かめてください。

基準の中身を事前に読んでおく

基準の中身を事前に読んでおいてください。何で点検されるかが実行時に決まるので、取得先の URL を自分で開いておくと予想が付きます。

2026-10-09 に開いた時点では、アクセシビリティ、フォーカス、フォーム、動き、文字組み、画像、性能、ダークモード、ハイドレーションなど 16 の分類と、指摘すべき悪い型の一覧が入っていました。出力は「ファイルごとにまとめ、file:line の形で、前置き無しに簡潔に」と指定されています。

取得先が変わると壊れる

取得先が変わると壊れます。URL が本文に焼き込まれているので、公開元が移動させた場合は取得の段で失敗します。

ライセンス

ライセンス: SKILL.md には書かれていません。リポジトリの README に MIT と書かれています（LICENSE のファイルはありません）。再配布や商用利用の前に公開元の表記を確認してください。

基準はどこにありますか

スキルの中にはありません。GitHub の vercel-labs/web-interface-guidelines から毎回取りに行きます。

同梱ファイルは無く、本文も 1KB 台です。中身は「取ってきて照らせ」という手順だけです。

通信できない環境でも使えますか

使えません。基準の取得が 1 段目です。

閉じた環境で使いたいなら、基準を自分で取ってきて手元に置く形に書き換える必要があります。

指摘はどんな形で返りますか

ファイル名と行番号です。file:line の簡潔な形が指定されています。

修正箇所に直接辿れるので、レビューの結果をそのまま作業に移せます。

レビューするファイルは指定できますか

できます。 argument-hint が <file-or-pattern> なので、ファイルでもパターンでも渡せます。

指定しなければ、どれをレビューするか聞かれます。

同じコードで違う結果が出ることはありますか

あります。基準を毎回取りに行くので、基準が更新されれば指摘も変わります。

これは利点でもありますが、結果の再現性は下がります。

対応しているエージェントはどれですか

Claude Code です。本文が WebFetch という Claude Code の道具の名前で取得の手順を書いています。

別の実行環境で使う場合は、その環境の Web 取得の機能と対応づけてください（指標の意味と限界）。