clipboard-screenshot

クリップボードのスクリーンショット

ユーザーのクリップボードは、あなたからは見えません。このマシンには小さなブリッジがあり、Unix ソケットに接続すると、クリップボードの現在の内容をあなたに渡して接続を閉じます。クリップボードにスクリーンショットがある場合、そのデータは PNG（場合によっては別の画像形式）です。

ソケットは $HOME/.clipboard.sock にあります（$CLIPBOARD_SOCKET で上書きできます）。ホームディレクトリ内に配置されているため、1 台のマシンを複数のユーザーで使う場合も安全です。各ログインのブリッジ（または ssh config の RemoteForward /home/%r/.clipboard.sock <local> による転送ソケット）は、それぞれのホームディレクトリ内に配置されます。そのためパスが衝突せず、他のユーザーのブリッジから読み取ったり、他のユーザーのブリッジにデータを渡したりすることはありません。CLIPBOARD_SOCKET を別のユーザーのソケットに向けないでください。それはあなたのユーザーではなく、そのユーザーのクリップボードです。

これにより、「ユーザーが画像をコピーした」状態から「あなたがその画像を見る」までの経路ができます。足りない手順は、画像データをコンテキストに取り込むには、Read するファイルを経由するしかないことです。そのため、まずデータをディスクに保存する必要があります。ファイル名の拡張子は、実際の画像形式に合わせてください。

画像を取り込む

同梱のスクリプトを実行します。作業用ディレクトリがある場合は指定し、取り込んだ画像がユーザーのプロジェクトに保存されないようにします。

~/.claude/skills/clipboard-screenshot/scripts/grab-clipboard-image.sh <scratchpad-dir>

（このスキルが別の場所にある場合、スクリプトはこのファイルから見た相対パス scripts/grab-clipboard-image.sh にあります。）

保存先のパスと検出された形式が出力されます。

path: /path/to/scratchpad/clipboard-20260821-072411-317849213.png
type: PNG image data, 670 x 586, 8-bit/color RGBA, non-interlaced

次に、そのパスを Read します。画像が会話に表示され、確認できるようになります。

このスクリプトを使えば、4 回の操作を 1 回にまとめられます。また、手作業で間違えやすい点が 2 つあります。nc の標準入力を /dev/null からリダイレクトしないと、接続を開いたままにしてしまいます。さらに、ファイルには実際の形式に合った拡張子を付ける必要があります。実際には JPEG なのに .png として保存した画像は、正しく表示されないことがあります。

見えたものを伝えてから、作業を続ける

画像に基づいて行動する前に、何が写っているかを 1、2 文で伝えてください。

これは単なる形式的な手順ではありません。ユーザーには、あなたがどのデータを受け取ったのか見えず、クリップボードの内容は古くなっていることもあります。別のものをコピーした後かもしれませんし、撮影しようとしたスクリーンショットに、意図しないウィンドウが写っている可能性もあります。「bb golden の実行に失敗したターミナルです」と伝えて、実際にはそれが送りたかったものではなかった場合、ユーザーはすぐに気づきます。そうすれば、違うものをデバッグするのに時間を費やす前に済みます。誤った画像を取り込んだことを伝えないのは、一文で知らせるよりも、はるかに大きな損失になります。

その後は、ユーザーが実際に依頼したことを進めてください。画像の取り込みは、たいてい目的を達成するための手段です。実際の依頼は、「なぜ失敗するのか」「このレイアウトを修正して」「この表を書き起こして」といったものです。他に依頼がなければ、画像を説明することがそのまま回答になります。必要に応じて詳しく説明してください。

ユーザーの説明だけに頼らず、画像を読んでください。ユーザーは「ログにエラーがある」と言うかもしれませんが、スクリーンショットには、そのエラーを出したコマンド、作業ディレクトリ、行番号も写っているかもしれません。ユーザーが言及しなかったそうした詳細が、問題解決の鍵になることがあります。

表示される色が、実際に公開される色とは限りません

取得した画像は、読み込んだときには完璧に見えても、ウェブページに表示すると色あせて見えることがあります。ネイビーがスレートグレーに、鮮やかな緑が淡い色に変わるのです。実際に確認された原因は、反転したガンマ値を含む PNG の gAMA チャンクです。正常なファイルでは 45455（γ 1/2.2）となるところが、219998（γ 2.2）になっています。ブラウザーはこのチャンクに従ってすべての中間調を明るくしますが、Read、sharp、そしてほとんどの画像ビューアーは無視するため、色あせに気づけません。このチャンクはクリップボードのバイト列そのものに含まれており、ブリッジではなく、アートワークをエクスポートしたものが付与しています。

そのため、ユーザーが再公開した取得画像は色あせているのに「元の画像」は問題ないと言う場合、まずページの CSS を調べるのはやめてください。PNG のチャンクを一覧表示し、gAMA を確認します。修正には、ロスレスで再エンコードします（sharp の .png() による再変換でチャンクを取り除けます）。デコードした再エンコード前後の生ピクセルを比較して、メタデータだけが変わったことを確認します。この問題が確認されたのは一度だけ（2026-08-31）で、チャンクを書き込んだエクスポートパイプラインは特定できていません。そのため、特定のソースだけでなく、ウェブ向けの取得 PNG はすべて疑ってください。

取得に失敗した場合

このスクリプトでは、失敗の種類ごとに必要な対応が異なるため、原因を分けて扱います。

終了コード	意味	対応
3	接続先がありません。ソケットファイルがないか、ファイルはあってもリッスンしていません。	ユーザーのクリップボードブリッジが実行されていません（ssh 経由の場合は、リモートフォワードが停止しているか、ソケットが古くなっています）。そのことを伝え、ブリッジを起動するか再接続するよう依頼してください。または、画像をファイルに保存してパスを教えてもらってください。再試行したり、コピーし直すよう求めたりしないでください。ブリッジの停止はクリップボードの内容とは無関係です。
4	接続できましたが、クリップボードから何も送られてきませんでした。	クリップボードは本当に空です。スクリーンショットをもう一度コピーするようユーザーに依頼してください。コピーできたように見えても、実際にはできていないことがあります。
5	クリップボードに別の内容があります。	検出した種類を伝えてください。ユーザーが貼り付けようとしていたテキストだった場合は、チャットに直接貼り付けてもらえます。
6	接続できましたが、ブリッジからの送信が完了しませんでした。	ブリッジが停止しているのではなく、応答しなくなっています。一度なら再試行する価値があります。再びタイムアウトした場合は、ユーザーにブリッジを再起動してもらってください。

終了コード 3 と 4 は、区別しておく必要があります。ブリッジが停止してもソケットファイルはディスク上に残るため、ファイルが存在することは何の証明にもなりません。ブリッジが停止しているだけなのに、クリップボードが空だと伝えると、ユーザーはずっとそこにあったスクリーンショットをもう一度コピーしに行くことになります。

何が起きたかを率直に伝え、ユーザーが解決できるようにしてください。読み込めなかった画像の内容を推測するより、読み込めなかったと伝えるほうが適切です。

再取得する

取得するたびにタイムスタンプが付くため、2回目の取得で1回目が上書きされることはありません。ユーザーが新しいものをコピーして「今度はこちらを見て」と言ったら、スクリプトをもう一度実行してください。前のファイルを使うと、ユーザーは現在の画像を見ていると思っているのに、古い画像が表示されます。2枚のスクリーンショットを比較する場合は、1枚ずつ取得し、両方のパスを保持してください。