haslanli/glance

ユーザーが長い回答に対して「もっと簡潔に」「要点だけ」「tl;dr」「短く」「簡単に」「図で」と求めたときに、回答を一目で理解できる形に要約・再表示します。

glance とは?

このスキルは、Claudeが生成した長い回答や複数の回答を、ユーザーが「簡潔に」「要点だけ」「tl;dr」「図で」などと要求したときに、理解しやすい形式に再構成します。対応言語は英語だけでなく、日本語(「要点だけ」「一言で」)、中国語(「长话短说」)、ロシア語(「покажи кратко」)など多言語に対応しており、自然言語でのリクエストにも応答します。スキルの主な機能は、回答の内容を保持しつつ、まず平易な一言で要約し、データがある場合はチャートやタイル、表などのビジュアルを表示し、最後に箇条書きで補足情報を提供します。数字、名前、パス、コマンド、警告など重要な情報は削除せず、文章量のみを元の半分から3分の2に削減します。`/glance` コマンドで起動し、`/glance on` で持続モード、`/glance super` で超簡潔モード、`/glance off` で通常モードに戻します。Claude Desktopアプリ(サイドチャット含む)とターミナルの両方で動作し、ビジュアルツールが利用可能な環境では高度なチャートやインタラクティブテーブルを描画します。複数の回答やセッション全体の要約にも対応し、矛盾する情報は後の回答を優先し、重複を排除して統一的に表示します。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/haslanli/glance-skill/tree/HEAD

Installed? Explore more 生産性&コラボレーション skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

glance は何をしますか?

誰かが、時間も背景知識もない回答を手にしています。一度目を通せば(glance)、その意味、何をすべきか、何がまだわかっていないかがわかるはずです。tldrは、すでにその言語を理解している読者向けに回答を圧縮します。glanceは回答を翻訳し、視覚的に示します。

コマンド

引数が help(または --help、-h、?)の場合、このブロックをそのまま表示して停止します:

/glance            最後の回答を一目でわかるように再表示
/glance <what>     特定の回答、その一部、または複数を再表示:「ビルドについてのあなたの返信」、
                   「数字だけ」、「今日やったことすべて」、「これまでのすべての決定」、
                   または貼り付けられたテキスト
/glance on         最後の回答を再表示し、以降 `/glance off` までこの方法で応答
/glance super      onと同様だが、すべての箇条書きを断片に短縮
/glance off        通常の返信に戻す
/glance status     現在のモードを表示
/glance help       これを表示

- すべての数字、名前、パス、手順、警告、未解決の質問は保持されます。
- 回答にデータがある場合は、チャート、タイル、グリッド、カード、または再構成された表として表示されます。
- モードはこの会話内でのみ `/glance off` まで持続します。
- `/btw` 内では、モードは引き継がれません。ターミナルでは、`/btw` は一度だけ回答し、何も保持しません。デスクトップアプリでは、`/btw` はサイドチャットを開くため、そこで設定されたモードはそのサイドチャット内に留まります。

どの回答を対象とするか

  • 引数なし、on または super: このコマンドの前にClaudeが返した最後の回答。スレッド全体(要求がない限り)、ユーザーのメッセージ、ツールの生の出力は対象外。その回答自体がglanceだった場合は、その前の回答を対象とする。該当する回答がない場合は、1行でその旨を述べて停止する。
  • その他の引数 は指示として扱う。同僚が読むように解釈する。回答を指し示す(「移行についてのあなたの返信」、「2つ上のメッセージ」)、範囲を絞る(「数字だけ」、「決定のみ」;範囲内のすべてを保持し、範囲外はすべて削除)、複数の回答やセッション全体に及ぶ(「今日やったことすべて」、「これまでの決定すべて」、「итог всего прогресса」)、貼り付けられたテキストを含む、またはこれらを組み合わせることができる。該当する回答が2つある場合は、最も新しいものを選び、1行で名前を示す。該当するものがない場合は、1行でその旨を述べて停止する。決して別のものを代わりに再表示しない。
  • ユーザーが自分の言葉で質問した場合(/glance を使わずに、「покажи кратко」、「長すぎる、要点だけで」、「これについてはどこまで進んでる?」):そのリクエストを指示として読み、言語を問わずその言語で応答する。
  • ソースは回答のみ。 選択された回答の内容のみを再表示する。ファイル、ツール出力、会話で以前に表示されたデータは、たとえより詳細であっても対象外。回答が3つのサービスを1行にまとめていた場合、glanceもその1行を維持する。
  • すでに短く平易な場合(非専門家でも理解できる数行):そのまま返し、1行で「すでに一目でわかる内容です」と付記する。
  • モード中の場合: 通常通りターンの作業(ツール、チェック、編集)を実行し、その後glance形式で応答する。

複数の回答またはセッション全体

指示が複数の回答にわたる場合(これまでの進捗、セッションの要約、ある時点以降のすべて、すべての決定)、それらすべてを1つのglanceとして再表示する:

  • ソース: その範囲内でClaudeが返したすべての回答、その過程でユーザーが述べた決定、およびClaudeが保持していたタスクリスト(あれば)。以前のglanceは、同じ範囲内の回答を再表示しているためスキップする。会話のみから構築する。git履歴、ファイル、トラッカーを読んでギャップを埋めない。なぜなら、読者はここで何が見つかり、何が行われたかを尋ねているからである。範囲の一部が会話内に残っていない場合(たとえば、初期のターンが要約に圧縮された場合)、残っているものを使い、その範囲を1行で述べる。
  • 回答ごとではなく、1つのglance。 最初の文で全体的な状況を述べる。範囲全体にわたる読者の質問(何が完了したか、何が決定されたか、何が未解決か、次は何か)を中心に箇条書きをグループ化し、このコンテンツ独自の言葉でラベル付けする。事実が属する手順の名前は、意味を理解するために必要な場合のみ記載する。
  • 統合し、すべてを保持する。 複数の回答で繰り返される事実は1回だけ表示する。すべての回答からのすべての数字、名前、パス、コマンド、警告、未解決の質問を残す。
  • 後の回答が優先される。 後の回答が前の回答を更新または矛盾する場合(新しい測定値、修正の適用、決定の撤回)、後のバージョンを使用し、その近くに数語でその旨を述べる:「/search 280 ms(キャスト修正前は350 ms)」。後の回答で解決された未解決の質問は、もはや未解決ではない。
  • ビジュアル は最大3セクションまで。範囲全体で最も重要なデータに割り当てる。通常、データがある手順ごとに1セクション。残りはコンパクトな表または箇条書きにする。
  • 長さ はすべてのソース回答を合わせて測定する。

glanceの構成

以下の順序で:

  1. 回答を日常的な言葉で。 1~2文、最大約25語。友人に言うような言い方で:「10月初めの2つの変更で、請求額が2倍以上になりました。」元の言い回しではなく、専門用語なし、比喩なし。
  2. データがある場合はビジュアル。 以下の説明を参照。
  3. ビジュアルに表示されないものの箇条書き: 原因、手順、決定、注意点、未解決の質問。
    • 読者の質問(なぜ起こったか、何をすべきか、何がまだ不明か、何が必要か)を中心にグループ化し、このコンテンツ独自の言葉でラベル付けする(「10月初めの2つの変更」、「修正、安い順」)。元の見出しを再利用せず、固定のラベルセットを使わない。
    • 1行につき1つの箇条書き、最大2行。文ではなく短いフレーズで書く(長さの節を参照)。
    • 非専門家が回答を理解するために必要な用語が初めて登場する場合、2~4語の説明を角括弧で追加する。日常的な言葉は説明せず、glanceあたり1~2つに抑える。
    • コマンド、コード、パス、エラーテキストはそのまま、コード書式で保持する。

これ以外は含めない。文はビジュアルの前に、箇条書きは直後に配置する。間に回答を言い換えたりビジュアルを説明する段落は挿入しない。

ビジュアル

いつ使うか。 回答にデータがある場合:比較する数値(項目間、グループ間、時間経過)、同じ詳細を持つ複数の項目、変化した値、または多くの項目のそれぞれのステータス。これらの場合、ビジュアルはデフォルトであり、追加ではない。回答が主に推論であり、いくつかの数値が含まれるだけの場合は、ビジュアルを省略する。

何を使うか。 このデータを一目で読みやすくするもの。回答がデータについて述べていることに基づいて選び、テーマや習慣で選ばない。2つの請求書に異なるビジュアルが必要な場合がある。回答の最初の文を読み、読者がそれを信じるために何を見る必要があるかを考える。

  • 合計がAからBに変化し、回答がその差を構成する変化を示している → ステップの合計が正確に一致するブリッジ
  • 1つの項目が変化のほぼすべてを占めている → その項目をタイル(正確な算術でそのシェア)で先頭に、残りを棒グラフで表示
  • 各行に複数の期間の値があり、各行の動きが重要 → 行ごとに小さなインライントレンドがある表
  • 項目がある値から別の値に移動し、回答が示す予算、目標、またはライバルと比較されている → before→after行、各値の下にベンチマークを薄く表示
  • 問題、障害、損失、または無駄を原因でグループ化 → 原因リスト:各原因にその数または量の棒グラフと、その下に影響を受ける項目
  • 回答の対象となる1~4つの数値 → 見出しタイル(単一の数値はタイルに。1本の棒グラフにはしない)
  • 1つの値をその制限または全体と比較(ディスク使用率92%、予算使用率80%)、または複数の項目をそれぞれの制限と比較 → メーター
  • 期間またはカテゴリをまたがる1つの系列(最大12) → カラム;より多くのポイントが時間経過 → 線グラフ
  • 項目間の量 → 最大から最小の順に1つのスケール上の棒グラフ
  • 1つの合計が2~6の部分に分割され、回答が分割について述べている → 部分のリストの上の分割棒グラフ;部分同士の比較 → 棒グラフ
  • 一部の項目で上昇し、他の項目で下降する変化、すべて同じ単位 → ゼロラインからの発散棒グラフ
  • before→after、または複数の項目のそれぞれについてのいくつかの数値(行ごとに単位が異なる可能性あり) → 数値ごとに1列、注目すべき行を青色で着色、回答が目標または制限を示す場合は線に対する棒グラフを追加した表
  • 各設定における各項目のステータス(テストマトリックス) → 設定ごとに1列、すべてのセルに1語、失敗セルのみ赤色の表
  • 同じ詳細を持つオプション → 比較、推奨オプションをマーク

円グラフやドーナツグラフは決して使用しない。2つ目のY軸は決して使用しない。1つのチャートに2本以上の線は決して使用しない。キットの3色(ソフトブルー、ブルー、レッド)以外の色は使用しない。上記の形式でデータを1つのスケールと1つの単位で正直に表示できない場合は、表を使用する。

1~3セクションの1つのビジュアル(例:タイル、メインチャート、1つのリスト)。すべての値はビジュアル上に表示され、ホバーを必要としない。キットは2つの例外(多くのポイントを持つ線グラフ、インライントレンド)を指定し、ホバー読み上げを提供する。

対話型は価値がある場合のみ。 ビジュアルは静的に保つ。ただし、データの行が多すぎて一度に把握できない場合(約15行以上)、または回答が同じ行を2つ以上の方法でスライスする場合(タイトルと言語、月とサービスによる)。その場合は、キットのインタラクティブテーブル(並び替え、フィルターチップ、長いリスト用の検索ボックス)またはビュースイッチを使用し、以下のルールに従う:

  • 最初のビュー(クリック前)はすでに質問に答えていること:すべての行が表示され、静的なビジュアルと同じように並べ替えられマークされているか、回答が対象とするスライスが表示されている。
  • コントロールは元のデータを別の方法で表示するだけ。what-if、予測、トレンドライン、平均、元のデータにない数値は表示しない。値を変更または計算するコントロールも表示しない。
  • フィルターは回答自身のカテゴリと用語を使用する(「損失のみ」、「失敗」)。回答が行わないグループ化は使用しない。
  • フィルタリングされたビューは、表示されている行数を示す(「40行中12行を表示」)。
  • 1つのテーブルとそのコントロール。複数のチャートをダッシュボードに結びつけることはしない。
  • ビジュアルツールがない場合はクリックできるものはない:完全なテーブルを最初のビューのように並べ替えて提供する。

どのように実装するか。

  • ビジュアルツールがある場合(Claudeデスクトップアプリ、その/btwサイドチャット含む、visualizeツール):read_me をモジュール mockup と data_viz で呼び出す(線グラフの場合のみ chart を追加)。次に、このスキルのフォルダ内の references/ui-kit.md を読み、そこからビジュアルを構築する:CSSブロックをそのまま貼り付け、1文のスクリーンリーダー要約から始め、そのコンポーネントのみを使用し、再スタイルしない。ツールのガイドとキットが異なる場合は、キットを優先する。show_widget で描画する。回答文は show_widget を呼び出す前に記述する(read_me を先に呼ぶのは問題ない)。これにより、読者はビジュアルの前に回答を得られる。箇条書きはその後。
  • 回答が請求書や支出の変化を説明する場合、最初に references/bills.md を読む:そのような読者が何を見る必要があるか、上記のどの形式が適合するかが書かれている。
  • ビジュアルツールがない場合(ターミナル、またはターミナル内の/btw):マークダウン表(以下に再構成)、または箇条書き内のbefore→after。
  • 色は意味を伝えるためだけに使用:ソフトブルーは通常のマーク、ブルーは注目すべきもの、レッドは否定的なもの。直接的なラベルまたは短い凡例で説明する。
  • 値とラベルはビジュアル上に配置。説明文は応答内に残す。

再構成し、正確にすること。 元の表をそのままコピーしない。再構成の方が速く読める場合:重要な順(通常は最大の変化または最も重要な項目が先)に並べ替え、重要な行をマークし、表をチャートに変換する。どのように再構成しても、正確でなければならない:

  • 元の表と同じ行、同じ値、同じ単位。削除、統合、丸めは行わない。
  • データ内にあるキー(例:ドルでの変化)で並べ替え、並べ替えた後に順序を確認する。
  • 元のデータがサポートするものだけをマーク:「悪化」は元のデータがそう述べているか、数値が明らかに間違った方向に動いた場合のみ。「推奨」はそれが推奨するもののみ。
  • 派生数値(差、シェア)はビジュアル上でのみ、元の値の正確な算術であり、ビジュアルに必要な場合のみ追加する(ブリッジステップ、主要項目のシェア);計算済みとしてラベル付けする。それ以外は数値を追加せず、箇条書きに新しいカウントや比較を決して入れない。
  • 元の値が不明瞭な場合は、そのまま保持する。

正確にデザインする。 キットが間隔、フォントサイズ、配置、ダークモード、狭いパネルを処理するため、上書きしない。キットが決定できないこと:

  • 1つの開始点。 回答が対象とする図、項目、または行を青色で目立たせる(hi、または表の行には at)。それ以外はすべてソフトブルーで二次的に表示。
  • 同じ順序、同じ名前。 項目はタイル、チャート、行、箇条書きで同じ順序、同じ名前で表示される。
  • 同じ単位、数値を先に。 1つの行または系列内では、すべての値を同じ方法で記述する(「8 vCPU」、「4 vCPU」)、元のデータと同じ単位、区切り文字、小数点を使用する。「専用」などの修飾語は値の下の小さな行に、約20文字に収めて記述する。より長い注釈は箇条書きに属する。
  • 決定セルを目立たせる。 オプションごとに最大1つの強調された欠点、元のデータが理由として挙げるもの、数語で記述(「PostgreSQLと相性が悪い」、「予算超過」)。推奨オプションをマークする。読者がすべてのセルをスキャンしなくても理由がわかるようにする。
  • 1行に1行。 元のデータが使用する名前を使用し、短く保つ。これにより、すべての表の行が1行で同じ高さになる。名前の説明が必要な場合は、箇条書きで平易な言葉で説明する。
  • 青色は注目を示す;赤色は否定を示す。 青色は回答が対象とするものに使用する。たとえ悪いニュースでも:請求額を跳ね上げたサービスは青色。赤色は、回答が示す線(制限、目標、予算)を超えた値、または失敗している値にのみ使用する:その数値、線を超えた棒グラフの部分。

…

[以降は省略されました。全文は元のSKILL.mdを参照ください。]

関連スキル