show-me

見せてください

相手が見ていないレンダリングは、存在しないのと同じです。

このスキルは、何かを完成させてから実際に相手に渡すまでの隔たりを埋めます。画像を文章で説明しても、見せたことにはなりません。ファイルパスを表示しても、見せたことにはなりません。どちらも納品した気分になりますが、実際にはどちらも違います。

インストールするものはありません。HTMLを書いて、開いて、相手に見てもらいます。

使う場面

回答が視覚的なもので、それを文章で説明しようとしているときはいつでも使います。

• 計画、構成、ロードマップ、一連の手順
• 2つ以上のものの比較
• レイアウト、ページ、デザイン、ワイヤーフレーム
• レポート、レビュー、ダッシュボード、進捗の要約
• ユーザーが選択肢から選ぶ必要のある場面すべて

2回読む必要がありそうなら、1回描いて見せてください。

モード 1 - SHOW

1つ、または複数のバージョンを並べます。

1. 一時パスに、完全に自己完結した HTML ファイルを書きます。CSS はインラインにし、外部へのリクエスト、CDN リンク、ウェブフォントは使いません。ネットワーク接続なしでレンダリングできる必要があります。
2. <meta charset="utf-8"> を含めます。これがないと、すべてのアポストロフィが文字化けして3文字になります。
3. ファイルを開き、ブラウザーを前面に表示します（後述）。
4. それから初めて、何かを伝えます。

モード 2 - PICK

ユーザーが2つ以上の方向性から選ぶ必要がある場合に使います。

最低3つです。 選択肢が2つでは、二択を装った「はい／いいえ」にすぎません。3つになると、相手は本当に望んでいるものが見え始めます。そして多くの場合、答えは1つ目の要素を3つ目の形に組み込んだものになります。

1ページに横並びで配置し、それぞれに短いラベルと、その案が打ち出す主張を一文で添えます。装飾ではなく、主張を説明してください。それから質問します。

視覚的な選択肢を言葉で説明して選ばせてはいけません。 レイアウトの文章による説明は、頭の中にあるモデルであって、実物ではありません。そのため、相手は間違った対象について判断するか、まったく判断できなくなります。まずレンダリングし、それから尋ねてください。

レンダリング前に行う、一文テスト

各案の方向性を一文で説明してください。同じ一文が2つの案に当てはまるなら、別々にデザインしたのではなく、1つのアイデアを異なる見た目にしただけです。 戻ってやり直してください。1つの仕掛けを3通りにしたボードでは、どれを選ばれても何も学べません。

ボード

次のように作ります。選択肢だけが視覚的な印象を持つよう、意図的にシンプルにしています。また、各カードには選択内容をコピーするボタンが付いているため、どれを指しているか入力する代わりに、クリックして回答できます。

<!doctype html><meta charset="utf-8"><title>Pick a direction</title>
<style>
 :root{--bg:#fff;--fg:#14171a;--mut:#5d6b7a;--line:#e3e8ef;--card:#f7f9fb;--accent:#c2410c}
 @media (prefers-color-scheme:dark){
   :root{--bg:#0f1418;--fg:#eef2f6;--mut:#9aa8b6;--line:#243039;--card:#161d23;--accent:#fb923c}}
 *{box-sizing:border-box}
 body{margin:0;background:var(--bg);color:var(--fg);padding:40px 32px 80px;
      font:16px/1.55 ui-sans-serif,-apple-system,"Segoe UI",Roboto,sans-serif}
 h1{font-size:26px;margin:0 0 6px}
 p.lede{margin:0 0 30px;color:var(--mut);max-width:70ch}
 .grid{display:grid;gap:22px;grid-template-columns:repeat(auto-fit,minmax(300px,1fr))}
 .card{border:1px solid var(--line);border-radius:12px;background:var(--card);
       padding:18px;display:flex;flex-direction:column;gap:10px}
 .card img,.card svg{width:100%;display:block;border-radius:7px;border:1px solid var(--line)}
 h2{font-size:17px;margin:0}
 .angle{color:var(--mut);font-size:14px;margin:0;flex:1}
 button{font:inherit;font-size:14px;padding:9px 14px;border-radius:7px;cursor:pointer;
        border:1px solid var(--accent);background:transparent;color:var(--accent)}
 button:hover{background:var(--accent);color:var(--bg)}
</style>
<h1>Pick a direction</h1>
<p class="lede">One line on what to judge, and what to ignore.</p>
<div class="grid">
  <div class="card">
    
    <h2>A &mdash; name of the device</h2>
    <p class="angle">The argument this one makes, in one line.</p>
    <button onclick="navigator.clipboard.writeText('A');this.textContent='Copied — paste it back'">Pick A</button>
  </div>
  
</div>

ボードの誠実さを保つ3つのルール：

• 装飾ではなく、仕掛けに名前を付けます。 「左側に沿ってタイムラインを配置」は仕掛けです。「青バージョン」は装飾であり、同じものを2回作ったということです。
• 画像はすべて埋め込みます。 <img src="/some/local/path.png"> は、ファイルを移動した瞬間に壊れたアイコンとして表示されます。ページに Base64 として埋め込むか、インライン SVG または HTML で描画してください。
• 形状を評価するなら、グレースケールでレンダリングし、その旨をリード文に書きます。 構成を見る前に、色で主張が決まってしまいます。

正しく開く

open -a "Google Chrome" file.html では、相手に何も見せていません。 タブは作成されますが、ブラウザーは前面に表示されないため、相手が実際に見ているものの背後に重なります。macOS では、代わりに次を使います。

osascript <<'EOF'
tell application "Google Chrome"
  activate
  set w to front window
  make new tab at end of tabs of w with properties {URL:"file:///ABSOLUTE/PATH"}
  set active tab index of w to (count of tabs of w)
end tell
EOF

activate はウィンドウを前面に表示し、active tab index の設定は新しいタブを選択します。両方が必要です。Linux では xdg-open が同等のコマンドで、Windows では start を使います。

それから、正しく動作したか確認します。 アクティブなタブの URL を読み戻し、自分のファイルであることを確認してください。確認の間に、別のウィンドウや別のプロセスがフォーカスを奪っている可能性があります。

osascript -e 'tell application "Google Chrome" to return URL of active tab of front window'

コマンドが終了コード 0 で終了したことは、実行された証拠にはなりますが、相手が見た証拠には決してなりません。

HTML で表示するものと、そうしてはいけないもの

見たり共有したりするものにはHTMLを使います。計画、レビュー、比較、レポート、ダッシュボード、オプション一覧、セッションの引き継ぎなどです。

別のツールに貼り付けるものにはプレーンテキストを使います。SNS の投稿、ニュースレター本文、ドキュメント、設定ファイル、指示ファイルなどです。こうしたものに HTML を使うと貼り付け先で問題が起きます。また、設定ファイルでは、その後のすべてのセッションでトークンを消費する一方、何のメリットもありません。

作成に取りかかる前に、どちらを作るのか明示してください。

台無しにする2つのこと

テキストの多いものには、背景のグリッドやテクスチャを使わないでください。 ダッシュボードでは見栄えがよくても、情報量の多い文書は本当に読みづらくなります。

まず自分で見てください。 自分で開いていないレンダリングについて、正直に説明することはできません。壊れたページを候補として提示することにもつながります。

その周りで伝えること

説明はレンダリングに任せましょう。周りに添える言葉は、ほとんど必要ありません。

手順ではなく、結論から伝えてください。 1行目で、相手が見ているものと、それについてのあなたの評価を伝えます。これから何をするか、どうやって作ったかから始めてはいけません。

最後は、今すぐ実行できる次のアクションを1つだけ、独立した行に書きます。

Next: pick a direction and I will build it out.

次のステップは1つだけにしてください。選択肢を並べてはいけません。「変更したい場合はお知らせください」や、相手が依頼できることを5つ並べるのも避けてください。次にすることが本当に何もなければ、作業が完了したと伝えて終わります。

失敗も含めて、結論をはっきり伝えてください。 「こちらは壊れていますが、残りの2つは確認する価値があります」と伝えるほうが、黙っているよりもよく、壊れたページを候補として提示するよりも適切です。

推測しない

最も時間を浪費する失敗は、レンダリングの出来が悪いことではありません。誰も確認していないことを根拠に、自信満々に作ってしまうことです。

ファイル名、数値、ステータス、パス、リンク先がわからない場合は、実際に確認してください。ファイルを読む、クエリを実行する、ページを開くなどです。もっともらしくても確認していない答えを出すことは、近道ではなく失敗です。

本当に確認できない場合は、**「未確認」**とはっきり伝え、何が不足しているのかを示してください。単に正しそうに聞こえる内容で穴を埋めてはいけません。ファイル名から値を推測してはいけません。実行していない確認の結果を報告してはいけません。

これは、Anthropic 自身のガイダンスがハルシネーションへの対処として示している考え方と同じです。不確実であることを認め、わからないと言う許可をモデルにはっきり与え、最もありそうに聞こえる答えを選ばせないようにします。

発言する前の確認

確認することは1つです。このセッションで、相手はこれを実際に目で見ましたか？

見ていないなら、成果物がどれだけ完成していても、作業は終わっていません。