landing-site

ランディングサイト — 目的、UX、デザインの基準

サイトの入口は site/（Vite + React + Tailwind、ダークモード専用）で、vigiles.sh にデプロイされます。このスキルは、すべての変更に適用される基準です。繰り返し発生する問題を防ぐためのものです。それは、要素を減らすのではなく追加してしまうことで、ページがモダンではなく、窮屈でテンプレートのような（「tilda 風の」）印象になることです。

すべてのルールの根底にある唯一のルール：迷ったら、削除してください。引き算でデザインします。 要素を削除しても意味が失われないなら、削除してください。ボックス、キャプション、2つ目のボタン、安心させる一文などを_追加する_変更は、必要性が証明されるまでは疑わしいものです。

目的（サイトの役割）

• 最優先目標 — npx vigiles audit を実際に実行する訪問者の割合を最大化することです。 これは、すべてのデザイン上の判断が目指す唯一のコンバージョン指標です。CTA は 優れたもの（手間がなく、わかりやすく、いつでもアクセス可能）でなければなりません。誰かが コマンドを実行する助けにならない変更は、採用する価値がありません。
• 対象者： Claude Code、 Codex、Cursor などのエージェント型コーディングツールを日常的に使う開発者です。彼らは懐疑的で、スマートフォンでは流し読みします。
• 目を引くポイントは採点済みのレポートです。仕組みを説明するのではなく、結果を見せてください。
• 最初に伝える約束：「エージェントハーネスの Lighthouse」— スキル、フック、サブエージェント、参照資料を、ワンコマンド、設定ゼロ、アップロードなしで採点します。
• デモフレームは4つの役割を同時に果たします。1つが他を押しのけないよう、4つすべてを考慮してデザインしてください。 (1) 導入 — vigiles が何かを一目で伝えます（採点済みレポートそのものが売り込みです）。(2) デモ — 手間をかけずに実際の採点結果をすぐに表示します（組み込みの FEATURED チップ）。(3) ブラウザー内で実行 — GitHub の匿名 API を使って、公開リポジトリのみを対象に、リポジトリ名を入力するだけで自分のリポジトリをライブで採点します。(4) 残りのユーザー向けコマンドコピー — 非公開またはローカルのリポジトリはブラウザー内で実行できないため、ここでは npx vigiles audit をわかりやすくコピーできるようにします（コマンドを渡すのであり、ブラウザー内で実行したように見せかけるのではありません）。ここから、必ず守るべき明確さのルールが2つ導かれます。(a) 表示中のリポジトリがどれで、それが事前定義された例（チップ）なのか、自分のリポジトリ（入力されたもの）なのかを、フレームで常に明確にすること。曖昧にしてはいけません。(b) 非公開リポジトリ向けの導線は、文章に押し込んだ後付けではなく、第一級の機能として扱うこと。ラベル付きのわかりやすいコマンドコピーを用意し、390px 幅で確認してください。コマンドを3行重ねて繰り返さないでください（上部に $ vigiles audit <slug> と表示し、その下にリポジトリ名を示す強調チップがあるのに、さらにコマンドを表示するのは情報過多です。上部の役割は、採点対象のリポジトリとそのソースを特定する**ことであり、コマンドを再掲することではありません）。
• コピー：気の利いた表現より具体性を優先し、読者がもともと抱いていなかった疑念を決して生み出さないでください。 ここで防ぐべき実際の失敗は2つです。(1) 気の利いた見出しが意味不明に読めること（「『有効』は『正しい』ではない。」）。具体的な痛みから始めてください（「設定は有効。でもエージェントは壊れている。」）。細かなニュアンスは下のカードで伝えます。(2) 弱点をわざわざ目立たせる防御的な FAQ（「採用できるほど安定していますか？」は、目を不安を誘うバージョン番号に向けさせます）。懐疑的な読者が実際に尋ねる、自信を持たせる質問に置き換えてください（「私のマシンから何かが送信されますか？」「非公開リポジトリを採点できますか？」）。各文を、初見の懐疑的な読者の視点で検証してください。これを読むと、コマンドを実行する可能性は高まりますか、低くなりますか？ 低くなるなら、削除するか、表現を変えてください。
• 信頼性：デモレポートには実際のスキャン結果だけを表示し、結果を捏造しないでください。 ブランドの約束は「主張ではなく、測定」です。そのため、レポート内にハードコードされた偽の数値が1つでもあると、実際の検出結果への信頼まで後から損なわれます。本当にここでは実行できない項目（モデルによって判定されるトリガー率）については、正直なプレースホルダー（数字なしの全角ダッシュ「実行して入力」）を使ったロック状態の予告なら問題ありません。何も偽っていないからです。ツールが実際に計算する項目について「結果」を捏造するのは不可です。実際に計算された結果を表示するか、レポートフレームの外に正直な説明カードを置いてください。
• 試しやすくする： 人気の OSS リポジトリをあらかじめ入力した「これを採点」チップをワンクリックで選べるようにし、訪問者が入力しなくても、自分のリポジトリを持っていなくても、実際のレポートを確認できるようにします。リリース済み — DemoAudit の FEATURED チップには、実際のレポートが組み込まれており、すぐに表示されます。
• すべての結果表示には、共有機能と固定リンクを用意してください。 チームメイトに渡せない採点結果は行き止まりです。したがって、(1) 完了した採点結果はすべて、読み込み時に監査を自動実行するコピー可能なディープリンク（vigiles.sh/?repo=owner/repo#try）にします。URL がそのまま共有単位です。(2) どの結果もワンタップで共有できます（モバイルではネイティブの共有シート、それ以外ではリンクをコピー。DemoAudit の ShareRow）。(3) ディープリンクでは、入力欄やチップと同じスラッグを使うため、共有リンク、入力したリポジトリ、チップのいずれも、同じコード経路に解決されます。新しい結果表示にも、両方を必ず用意してください。リリース済み — 動作を維持してください。（共有はオプトイン、辞退は無料、採点対象は人ではなく成果物という、この機能が従う評判に関するルールは、ルートの CLAUDE.md にある gate-first-adoption ルールです。ここで繰り返す必要はありません。）
• コンバージョンを計測する： ファネル（コマンドのコピー、入力内容の送信、チップの試用、再採点、共有クリック）の分析を行います。このサイトは GitHub Pages を利用しており、Vercel は利用していません。そのため、Vercel Analytics は適用されません。静的ホスティング向けの軽量でプライバシーに配慮した、スクリプトタグ型の分析ツールを使用してください。Plausible / Fathom / GoatCounter が候補です。ファネルにはすでに計測機能が組み込まれています。track()（site/src/lib/track.ts）が demo_* イベントを発火し、プロバイダーが接続されるまでは安全なノーオペレーションになります。残作業： プロバイダーのスクリプトタグを index.html に追加し、イベントが届くことを確認してください。分析に含めるのは結果の種類だけとし、入力されたスラッグは決して含めないでください（非公開リポジトリ名を漏らしてはいけません）。

方針 — 決定事項（最新の状態を保つこと。方針はここに記載されています）

現在のサイトの背後にある戦略上の決定です。方針が変わったらこのセクションを更新してください。これはスタイルガイドではなく、設計ドキュメントです。ここにある決定はどれも、実際に試行錯誤を重ねてたどり着いたものです。黙って覆さないでください。

• デフォルトのデモには必ず問題点を見せること — まずは実際に低評価のものを表示し、Aばかり並べないこと。 FEATURED のチップは、認知度の高いリポジトリを対象にした本物の F → C → B → A の評価スケールです（現在は davila7/claude-code-templates が F、disler/claude-code-hooks-mastery が C、madappgang が B、obra/superpowers が A）。こうする必要がある理由：実際に人気のあるプラグインの多くは、ブラウザーで実行できる決定論的な評価軸では、ほとんどが A/B になります。劇的な問題（スキルが実行されない、説明が競合する）は、ブラウザーでは実行できない、モデルの実行に依存するトリガー率の評価層にあります。そのため、きれいに見えるデフォルトではツールの必要性が伝わらず、むしろツールに反する印象になります（「問題ないのに、なぜこれが必要なの？」）。デフォルトには本当に問題のあるリポジトリを使い、レポートでヴィジルが何かを検出する様子を見せて、驚きを生み出す必要があります。 低評価のデフォルトを更新する場合（リポジトリは時間とともに修正されます）：git clone https://github.com/<slug> を実行してから node dist/cli.js audit <dir> --json で調査します（注：クラウド環境では codeload と api.github.com はプロキシによってブロックされています。github.com 経由の git clone は動作します）。(a) 認知度が高く、(b) 客観的で、1行の修正で解決できる問題（使われていないツール、認識されない skills/ ディレクトリ、発火しないフックイベントなど。意図的に恥ずかしい設計にしたものではない）があるリポジトリを選び、公開評価を公正なものにしてください（Lighthouse モデルが評価するのは、公開されている成果物の公開評価です）。レポートは site/src/demo/reports/ に保存し、FEATURED に組み込んでください。モデル層の問題はブラウザーのデモには含めません。設計上、デモは決定論的な評価だけを対象としているためです（以下のブラウザー内デモの不変条件を参照）。これらの問題を誠実に見せる場所は、結果を捏造することではなく、LockedRow の予告です。
• 名前だけ挙げて説明しないことは、コピーの最大の失敗要因です — すべての概念に説明を添えるか、削除してください。 初めて訪れた人は、「リンター」「参照」「強制」「仕様」、あるいはカテゴリー名の意味を知りません。すべての概念には、初出時に平易な英語で説明を添えるか、削除してください。専門用語を説明なしに持ち出さないでください（以前の README でこれを学びました — 「HARNESS は初出時に定義する」。サイトは後退し、また学び直すことになりました）。ヴィジルについて聞いたことのない、初めて Claude Code/Codex を使うユーザーの視点で、すべての行を確認してください。
• 説明の重複はレポートにまとめる — 独立した説明カードを追加しないでください。 驚きを生み出すのはレポートです。ブラウザーでは見せられない概念（モデルの実行に依存するトリガー率や、ローカル設定が必要なリンターの相互参照）は、枠の下に浮かぶカードではなく、レポート内の破線付きの CLI 専用行 にします（report-view/src/Report.tsx の LockedRow / CliRulesRow）。サイト上でレポートの説明が2か所にある場合は、重複する方を削除してください（これが、Wedge の5カテゴリーの帯と、独立した「Your rules → enforced」カードを削除した理由です。レポートにはすでに両方が含まれています）。
• 入力方法は一度に1つ — 選択肢を並べるのではなく、Public/Private タブにすること。 ヒーローの入力欄には、入力欄、「public API」のキャプション、プライベートコマンドへの案内、プライバシーに関する文言がすべて積み重なり、窮屈でした。現在は DemoAudit の Public | Private タブ になっています。Public はリポジトリ名を入力するライブコンボボックス、Private は npx vigiles audit コマンドをコピーするものです。一度に表示する入力方法は1つです。
• 正直な予告にとどめ、ぼかしたり捏造したりしないこと（以前の「ぼかして表示する」という指示に優先します）。 モデルの実行に依存する行には、ぼかした偽の数値ではなく、ダッシュ付きのプレースホルダー（recall — · precision —）を使います。ぼかしは、表示のバグにも、ダークパターンのペイウォールにも見えます。また、数値を捏造することは「主張ではなく測定」という原則に反します。主張された数値を批判するコピーの近くにあるなら、なおさら誤りです。より強い予告が必要になった場合は、捏造したりぼかしたりした数値ではなく、example とラベルを付けた実測値を使ってください。

UX 要件

• コマンドを最優先。 npx vigiles audit は、あらゆる OS、あらゆるターミナルで使える共通のアクションです。最優先の CTA とし、それ以外はすべて補助的なものにします。
• Claude Code のディープリンク（claude-cli://）はデスクトップ専用の拡張機能であり、決して主要な導線にはしません。 モバイル／CC Web／Claude Code を使っていないデスクトップでは、何も起きないまま行き止まりになるためです。機能する場所にだけ表示し、何も起きないボタンは絶対に設置しないでください。
• モバイルでは正直に伝えます。 何も起きないボタンは設置しません。デスクトップ専用のアクションを実行できない場合は、そのことを明確に伝え、代わりに実際のアクション（コマンド）を提示してください。
• 画面ごとに主要なアクションは1つ。 補助的なアクションは控えめにします。テキストリンクか控えめなピル型ボタンにし、主要なアクションと競合する、目立つ全幅ボタンを2つ目に置かないでください。
• 特定のハーネスに依存しないこと。 Claude Code を先に出さず、「Claude Code または Codex」と表現してください。Claude Code は実装の詳細であり、見出しにする要素ではありません。内部の仕組みを過剰に説明しないでください。
• 気軽に試せて、親しみやすいこと。 ざっと目を通すだけでも、1画面以内で何のツールか、どう試すかが分かるようにしてください。長文を読ませないでください。

デザイン基準 — モダンでミニマルに（詰め込みを避けるルール）

Linear／Vercel／Raycast の雰囲気を参考にします。自信を感じさせるダークなデザイン、ゆとりある余白、少ない言葉、セクションごとに明確な焦点を1つ。機能を詰め込んだテンプレートにはしないでください。

• すべての要素に存在意義を持たせてください。 別の要素を言い換えているだけのもの（スクリーンショットの内容を繰り返すキャプション、二度出てくる信頼性の説明、重複する小見出し）は取り除いてください。
• ほかの要素からすでに伝わるラベルは削除してください。 GitHub／スターへのリンクがあるなら、「無料・オープンソース」のバッジは重複です。「特定のリポジトリを監査」というバッジを「特定のリポジトリを評価」という見出しの上に置くのも、同じ内容の繰り返しです。文脈からすでに伝わるラベルはノイズになります。
• リンク／CTA はすべて、具体的で実行可能なものにしてください。 クリックすると何が起きるのか、読者に正確に伝わる必要があります。「Claude Code をお持ちですか？…」のような、曖昧または受け身の補助リンクは避けてください。明確で具体的なアクションとして提示する価値のない補助的な導線は削除するか、ナビゲーションに移してください。目立たない折り返し位置のリンクより、常に表示されるナビゲーションリンクのほうが効果的です。
• セクションごとに焦点を1つにしてください。 最初に目が留まる要素を1つにします。
• ボックスより余白とタイポグラフィを活用してください。 枠線付きの全幅ボックスを3つ以上重ねないでください。同じ見た目が続くと詰め込まれた印象になります。枠線ではなく、文字の階層と余白を活用してください。ただし、余白は意図的に使います。画面がほとんど空白になるのも避けてください。
• 安心材料は1行で一度だけ。 信頼性を伝える文言（「何もアップロードされません」など）は、簡潔に一度だけ表示します。3行の段落にしたり、セクションごとに繰り返したりしないでください。
• 一貫性を持たせてください。 ヒーロー（バッジ＋見出し＋補足文＋ビジュアル）は全体で1つのアイデアを伝え、それぞれの要素が新しい情報を加えるようにします。補足文がスクリーンショットにすでに表示されている内容を説明するだけなら、削除するか、より明確な内容にしてください。
• 色や強調は控えめにしてください。 アクセントカラーは1色にし、意味を持つ色（評価の段階など）は常に同じ意味で使います。各ポイントで太字にするのは1つのフレーズだけにし、すべての節を強調しないでください。装飾目的の絵文字を散りばめないでください。
• 余白の間隔は一貫した尺度で設定してください。 リズムを崩すような、その場しのぎのマージン調整は避けてください。

アンチパターン（これまでに発生した問題）

• 入力欄＋大きなボタン＋3行の安心材料＋区切り線＋コマンド＋キャプション＋別のボタンを、1画面に積み重ねること。（対策：要素を3つ程度に絞り、それ以外は削除します。）
• 製品の画像の下に、その画像の内容を繰り返すキャプションを追加すること。
• フローを見直す代わりに、問題ごとに通知／ボタンを追加すること。
• 優先順位をつけず、ディープリンクとコマンドという2つの CTA を競合させること。
• 見出しで「お使いの Claude Code 内で実行される…」と説明し、Claude Code を最優先にした形で安心材料を伝えること。
• デスクトップ専用のフロー（Claude Code の claude-cli:// ディープリンク）を、フォールバックとしてモバイルにも表示すること。別のセクションにすでにあるコマンドを繰り返すだけで、スマートフォンでは同じ npx vigiles audit ブロックが連続して表示されてしまいます。（対策：デスクトップ専用セクション全体を hidden sm:block にします。ヒーローと CTA で必要な情報はすでに伝わります。）

ブラウザー内デモ（リリース済み — 維持すべき不変条件）

稼働中の「任意のリポジトリを評価」デモは実装済みです（DemoAudit.tsx と site/src/demo/）。公開リポジトリを入力または貼り付けるか、注目チップをタップすると、ハーネスファイルをクライアント側で取得し、CLI と同じコンパイル済みエンジンを実行します。以下のルールは今後の方針ではなく、維持すべき不変条件です。

• すべての結果を共有できます（上記の共有可能性の目標を参照）。 評価が完了すると、ワンタップで共有でき、安定して自動実行される ?repo= ディープリンクが付与されます。これはデモの必須要件であり、あれば便利という程度のものではありません。これを備えない結果表示はリリースしないでください。
• ホスト型ではなく、ブラウザー内で実行します。 監査処理はすべて訪問者のブラウザー内で実行します（GitHub API 経由でリポジトリのファイルを取得し、純粋な JavaScript 検出器を実行します）。これにより「何もユーザーのマシンから外部に送信されない」ことを強調し、バックエンドも費用も不要になります。「ホスティング」は現行サイトと同様に、vigiles.sh で静的ファイルを配信することだけです。キャッシュ付きサーバーレスバックエンドは明確に計画外です。
• 決定論的な処理のみを実行します。 モデル不要の指標（Truthfulness／Structure／Safety-via-lethal-trifecta／description-overlap）を実行します。モデルが必要な trigger-rate はスキップします。そこには LLM とクォータが必要だからです。
• 監査の実行中は、実際のプログレスバーまたはストリーミング状態を表示します。ファイルの取得や各指標の実行状況を示し、ただ回り続けるスピナーにはしません。処理中であることが伝わる表示にしてください。
• ロックされた LLM の機能は、ぼかしではなく、正直なプレースホルダーでほのめかします。（上記の「正直にほのめかし、ぼかしや偽装はしない」という決定を参照してください。以前の「ぼかして表示する」という指針に優先します。）モデルが必要な trigger-rate は、レポート内の CLI 専用の破線行（LockedRow）として表示し、プレースホルダーにはダッシュ（recall — · precision —、「実行すると入力されます」）を使います。また、「何をコピーするか」を明示する「プロンプトをコピー →」を表示します。これにより、ユーザーがローカルで実行したくなるよう促しつつ、内容を一切捏造しません。ぼかし表示はレンダリング失敗や有料の壁のように見え、数値も偽装するため、使用しないでください。
• 実際のレポートコンポーネントを再利用します（AuditReport JSON からレンダリングします）。スクリーンショットは使いません。これがレポートビューを共有パッケージに置く理由です（以下を参照）。

共有 UI のリポジトリ構成（リリース済み — 維持すべき不変条件）

監査レポート（report/）とランディングサイト（site/）は、ワークスペースパッケージ（@vigiles/report-view（packages/report-view/））を介して同じレポートビューを共有します。このパッケージは AuditReport をレンダリングし、Report コンポーネント（デモ内のフレームには variant: "summary"、CLI のスタンドアロン HTML レポートには "full"）、スキーマ、バンドトークン、theme.css を所有します。npm WORKSPACES（workspaces: [packages/*, report, site]）として接続されています。不変条件： デモと CLI レポートは、同じコンポーネントと同じ AuditReport JSON からレンダリングします。スクリーンショットや、重複したコンポーネント、相対パスで相互インポートしたコンポーネントは使用しません。利用側は、このパッケージの src を @source で指定する必要があります（Tailwind v4 は node_modules を無視します）。ルートの公開 vigiles パッケージと CI ゲート（api-surface、coverage）は正常な状態を維持します。ワークスペースはプライベートであり、その files から除外されています。（CI に不可欠な設定については research/report-view-and-browser-demo.md を参照してください。）

プロセス — サイトを変更してリリースする前に

ゲートでの見逃し → まずゲートを修正する（必須）。 このスキルのレビューで本来見つけるべきだった不具合（モバイルレイアウトの崩れ、要素の切り抜け、説明のないコントロールなど）がユーザーに届いてしまった場合、根本原因はコンポーネントだけでなく、このスキルにあります。不具合を修正する前に、または修正と同じ変更内で、次回は同じ種類の問題をすべてゲートで検出できるよう、このスキルを更新してください。不足していたチェック項目を以下のチェックリストに追加し、見逃された問題を明記したうえで、手順どおり機械的に確認すれば検出できるほど具体的なチェック内容にしてください。ゲートをすり抜けてリリースされた不具合は、スキルの不具合です。コンポーネントだけを直して先に進めば、次の不具合も見逃すことになります。（ステップ 2 にモバイルレイアウトのチェックリストがあるのはこのためです。見出しが 1 行に 1 語ずつになるほどフレックス行が押しつぶされた問題や、スマートフォンで <pre> の例が右端で切れてしまった問題など、実際の見逃しをもとに作成されました。）

1. この基準に照らして判断してください。 「何を追加できるか」より先に、「何を削除できるか」を考えてください。
2. デスクトップとモバイル（390px）の両方で、ページ全体を毎回上から下までスクリーンショットに撮り、実際に確認してください。 モバイルはデスクトップの幅を狭めただけのレイアウトではありません。両方を確認するまでは、変更を検証したことになりません。追加または変更したすべてのコンポーネントを、390px でスクロールして全体を表示し、スクリーンショットに撮ってください。 上端だけを撮ったり、「画面の下だから大丈夫だろう」と判断したりしてはいけません。モバイルでの表示をスクリーンショットで実際に確認していないコンポーネントは、例外なく未検証です。 モバイルレイアウトのバグチェックリスト — 変更したコンポーネントすべてについて、390px のスクリーンショットで次の項目を確認してください（どれもこのチェックをすり抜けて実際にリリースされた不具合です。スクリーンショットから問題がないと言い切れない場合は、確認が不十分です）。
   • つぶれた Flex カラム — 片側にテキスト、もう片側にボタンやバッジがある flex ... justify-between の行が、スマートフォンでは縦に積み重なるべきなのに横並びのままで、テキストが1〜2語ごとに改行されるほど狭くなっている状態です。修正方法：flex-col sm:flex-row（モバイルでは縦積み、sm+ では横並び）を指定してください。狭い画面で flex-1 min-w-0 のテキストブロックと shrink-0 のボタンを競合させないでください。
   • コードや長いテキストの切れ・はみ出し — <pre>／<code>／長いインライン文字列がカードの右端で切れている状態です（overflow-x-auto のブロックは、スマートフォンではスクロール可能ではなく、切れている ように見えます）。修正方法：折り返すように whitespace-pre-wrap break-words を指定するか、例を短くしてください。390px で、すべての <pre> と等幅フォントの例を確認してください。
   • テキストが端に接触している、または端からはみ出している状態、およびレンダリング不具合に見える要素（スティッキーバーの向こうにゴーストのように透けている、ぼやけたブロックが読み込み失敗のように見えるなど）。
   • レスポンシブグリッドのセル衝突（390px だけでなく、両方のブレークポイントを確認してください）。 sm: をまたいで列数が変わる CSS グリッド（例：grid-cols-[1fr_auto] → sm:grid-cols-[10.5rem_1fr_auto]）では、別の子要素が同じ col-start／row-start セルに固定されていると、自動配置された子要素が気づかないうちに次の行へ移動します。その結果、コマンドの直後に横並びになるはずのラベルが2行目に移動して中央寄りにインデントされ、「なぜこれが中央にあるのか？」という見た目になります。これは VerbMap で実際に発生しました。モデルの注記に2列のモバイルレイアウト用の col-start-2 row-start-1 が残ったまま、sm:col-start-3 が設定されていなかったため、デスクトップでは回答と衝突し、2行目に押し出されていました。修正方法：明示的に配置するグリッドの子要素すべてに、幅の広いグリッド用の sm:col-start を指定し、デスクトップのスクリーンショットでも配置を確認してください（このクラスは390pxでは表示されないため、モバイルのグリッドは問題なく、崩れるのは sm: のレイアウトです）。ブレークポイント間でグリッドのテンプレートを変更したら、すべての子要素の配置が両方で設定されているかを確認してください。 続いて、モバイルでスクロールしながら、さらに次の2点も確認してください（どちらも実際に問題を引き起こしたことがあります）。
   • セクション間で内容を重複させないでください。 同じコマンドブロック／CTA／信頼性を示す文言を、隣り合う2つのセクションに表示してはいけません。セクションのモバイル向け代替表示がヒーローやCTAの内容を繰り返すだけなら、それは重複です。コマンドを繰り返すのではなく、そのセクションをモバイルで非表示にしてください。
   • モバイルでデスクトップ専用のフローを行き止まりにしないでください。 デスクトップ専用の操作（Claude Code の claude-cli:// ディープリンク）が、スマートフォンでほとんど何もないカードやコマンドだけのカードに縮退するのは、ノイズです。スマートフォンでは使えないデスクトップ機能を予告するだけの表示を残さず、セクション全体に hidden sm:block を指定してください。（ブラウザー内のデモ自体はモバイルで動作します。デスクトップ専用なのはディープリンクによる引き継ぎです。） （Global Playwright と vite preview、または screenshot スキルを使用してください。）
3. ページ全体を複数のユーザー視点から、まとまりのあるものとして読み通してください。 変更したセクションだけを切り離して確認してはいけません。変更箇所単体では問題がなくても、ページ全体の流れや一貫性を損なったり、あるペルソナには答えていても別のペルソナを混乱させたりすることがあります。少なくとも次の5人の読者として、デスクトップと390pxの両方でサイト全体を確認し、ペルソナごとに「分かりやすいか、流れに納得できるか、コンバージョンするか（npx vigiles audit を実行するか）」を考えてください。
   • Claude Code／Codex のヘビーユーザー（プラグインやスキルを使っていて、詳しい情報を求めている）
   • 初めての訪問者／スマートフォンで流し読みする懐疑的な人（30秒しか読む気がない）
   • プラグイン／スキルの作成者
   • 納得しない限り何も実行しない懐疑的なシニアエンジニア
   • 導入を評価する意思決定者／リード これらの視点からの確認は、以下の Fable パスに組み込んでください（Fable は複数の視点を同時に保つのが得意です）。ドキュメントでは review-docs スキルが同様の役割を果たします。目的は、セクションごとの磨き込みではなく、ページ全体と対象者間の一貫性をリリース前に見つけることです。
4. 重要な変更では、初めて訪れたユーザーとして Fable にブラインドレビューを依頼してください。 最も重要なレビュアーは、vigiles を一度も聞いたことがない Claude Code／Codex ユーザーで、リンクからこのページにたどり着いた人です。デスクトップと390pxのスクリーンショットを Fable に渡し、次の手順をそのまま実施してください（「レビューしてください」とだけ伝えてはいけません）。
   • 上から下へ、セクションごとに確認してください。 各セクションについて、次の3点を記録します。（a）実際に何を伝えているかを一文でまとめる。（b）奇妙、不一致、破損、窮屈、コントラスト不足、またはレンダリング不具合に見えるもの（怖い文の上に全面緑色のバーがある、ぼやけた要素が読み込み失敗のように見える、塗りつぶされたバーの横に — がある、レールが折り返されて位置がずれている、「1 hooks」など）。（c）その場で頭に浮かぶ疑問（「何をコピーするのか？どこに貼り付けるのか？」「どのプラグインか？」「目に見える問題がないのに、なぜ92なのか？」「これはリポジトリをアップロードするのか？」）。
   • 見るだけでなく、操作してください。 リポジトリを入力し、チップをタップし、動詞の行を展開し、コピー／共有ボタンをすべてクリックし、スマートフォン幅にサイズ変更してください。分かりにくい、目に見える反応がない、説明のない内容をコピーするコントロールは不具合です。
   • 「いいえ」の場合は具体的な阻害要因を挙げて、2つの判定を示してください。 （1）実際に試してみるか — npx vigiles audit／init を実行するか？（2）共有するか — リンクをチームメイトに送るか？共有は成長を促す手段なので、共有したいと思わせない結果画面は細かな指摘ではなく、修正すべき問題です（共有可能性の目標を参照してください。ShareRow は控えめなボタンを置くだけでなく、共有を後押しする必要があります）。
   • 影響の大きい順に並べ、各項目に具体的な修正方法を示してください。 信頼性に関わる不具合（現実味が必要な場所で、デモが作り物や破損のように見えること）は、見た目の磨き込みより優先されます。指摘された問題を修正してください。 Fable の P0／P1 による「削除／修正」は任意ではありません。記録するだけで先に進まないでください。5人のペルソナによる確認（ステップ3）も同じパスに組み込んでください。Fable は複数の視点を同時に保てますが、主な視点は初めて訪れたユーザーです。
5. ビルドと Prettier がクリーンであることを確認してください。main への push 時に pages.yml によるデプロイが決定論的に行われることも確認してください。