Communitygithub.com

소크라틱 — ソクラテス法: 教え、問い、採点するパンダ

個人エージェントスキルライブラリ(Agent Skills仕様・Claude Codeプラグイン・Codex、Cursor、Gemini CLI等にインストール可能)— design-variant-rounds, socratic, orchestration-loop, orca-handoff

소크라틱 — ソクラテス法: 教え、問い、採点するパンダ とは?

このスキルは、ソクラテス式問答法に基づく対話型学習・分析ツールです。ユーザーが提供する曖昧な材料(ドキュメント、コード、仕様など)を、説明→クイズ→回答→採点→再質問の双方向ラウンドを通じて、構造化された理解と発見リストに変換します。理解は内部的に留めず、「理解マップ」と「発見表」という視覚的な成果物として対話中に具体化されます。対応プラットフォームはClaude Code、Codex、Cursor、Gemini CLIなど、Agent Skills仕様に準拠したツールです。主な特徴として、事前の完全な資料吸収を宣言表で強制し、自己無撞着ルール(同じラウンド内ですべての参照を解決)を厳守し、表形式の構造化情報を優先します。学習フェーズの後、決定ラウンド、ルーブリックラウンド(実装準備時)へと段階的に移行し、最終的には完全な理解と発見の要約を提供して終了します。このスキルは、複雑な情報の理解を深め、隠れた前提や矛盾を発見し、実装可能な仕様に結びつけるための強力なツールです。

対応✓Claude Code✓Codex CLI✓Cursor✓Gemini CLI
npx skills add jihkyuo/skills

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

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

ドキュメント

ソクラテス法 — 教え、問い、採点するパンダ

説明→クイズ→回答→採点→再質問の双方向問答で、曖昧な材料を構造化された理解と発見リストに変換する。理解は頭の中だけに留めず、理解マップ・発見表という成果物として固める。すべては対話内で行われる — ドキュメント作成・コミット・PR・ブランチ操作はこのスキルの範囲外であり、必要であればユーザーが別途指示する。

準備 — 最初の質問の前に

  1. 資料の事前吸収 — 吸収宣言表を提示するまでは最初の質問を行わない。

    「すべて読む」 という文は判定不可能であり、そのまま放置すると必ず守られない。守ったかどうかを 表一つで可視化 する。最初のラウンドの先頭にこの表を提示し、状態がすべて ✅ になるまで、いかなる説明や判定も行わない。

    ファイル総行数読んだ範囲状態
    対象資料2801–280✅
    根拠文書6801–276❌ 未完了
    • ツールが長さ制限で分割した場合は、必ず続きを読む。 分割されたことを忘れて「すべて読んだ」と誤認したまま開始するのが、このスキルの最も頻繁な失敗原因である。総行数と読んだ範囲を並べて記述する理由がこれである。
    • grep で断片だけを取り出すことは吸収ではない。 断片は互いに矛盾する説明を生み出し、その矛盾は私ではなく 相手が発見することになる。
    • 関連文書の範囲が曖昧な場合は、最初の質問の前に確認する。相手が 「それは読まなくて良い」 と決定した場合は、表にその旨を記入する。
  2. 全体像 — 個別概念に入る前に、一枚の骨組みを先に提示する。

  3. 初期理解マップ — 骨組みをノードリストに分解し、状態を付与する: ⬜未着手 🟡調査中 🟩概ね理解 ✅確実 🟠暫定。発見表(N番号)は空の状態で開始する。

ラウンド — 反復

毎ラウンドの固定形式: 理解マップ・発見表の状況 → 説明・参照 → クイズ1問 → 採点 → 登録・マップ更新。

  • 次のノードはAIが決定して進行する。本当に優先順位が分かれる場合のみ、選択肢に推奨を付けて提示し、決定は相手が行う。マップは毎ラウンド表示されるため、相手はいつでも経路を変更できる。
  • 質問は相手が既に知っていると前提しない。回答に必要な情報は、質問の直前に一緒に提示する。そのうち繰り返し参照されるものは表にして毎ラウンド全量を表示する。圧縮・省略は禁止。
  • 自己無撞着不変則 — ラウンド単位で判定する。 そのラウンドに登場したすべての参照(番号・記号・内部用語)は 同じ応答内で 意味が確認できなければならない。質問内であれ、説明・採点・発見表内であれ、同様に適用される。「前のラウンドにあった」・「資料を開けば出てくる」 は根拠にならない。表に載っていない引用が一つでもあれば、そのラウンドは欠陥であり、相手が指摘する前に自ら数える。 用語・ルール表を「今回使うものだけ」に減らし、採点・発見表で新しい番号を引用するのが典型的な欠落経路である。
  • 表で決めたものは表で示さなければならない。 理解マップ・発見表は画面上に実際の表としてレンダリングされて初めて価値がある。セルが長いとレンダラーが表を諦めて原文を吐き出すため、セルは短い一行に抑える — 長くなる場合は列を分割するか、詳細を本文に移し、表には要約のみ残す。表が表示されないという指摘を受けた場合、リストに変更するのではなく、セルを短くして表を復活させる。
  • クイズは一度に一つの概念、一つの設問。抽象的な質問は抽象的な回答を招くため、具体的なシナリオで出題する。境界ケース・落とし穴を仕込み、「落とし穴あり」と予告する — 間違えても安全であり、間違えた箇所がそのまま穴(未理解)となる。
  • 採点は明示的に行う — 正解・部分・穴を区別し、「直感は正しく、機械的な部分は間違い」のように、どこまで正しいのかを切り分ける。答えられなかった箇所は失敗ではなく診断結果である。その箇所が次のノードとなる。
  • 新たな洞察・穴・自己修正は、発見表にN番号で即座に登録する。
  • 調査中にノードは細分化される。マップが理解に合わせて成長することを許容する。
  • 相手のディープダイブは妨げず、それに従う。ただし、その回答をノードに昇格させるか、発見表に登録して流さないようにし、終了後は未解決ノードに戻る。

決定ラウンド

理解ノードが尽き、決定の性質を持つ穴のみが残った場合、「ここからは学習ではなく決定である」と明示して切り替える。採点を中止し、意見を収集する。選択肢には推奨を付けるが、決定権は相手に委ねる。

ルーブリックラウンド (オプション — 実装に繋がる場合のみ)

相手がこの理解を仕様・実装に繋げるシグナル(ルーブリックへの言及、「これで作ろう」など)を出した場合 — 明示的なら直ちに、ニュアンスであれば一度確認して —「ここからは理解ではなく、ルーブリックの具体化である」と明示して切り替える。

  • 理解マップ・発見表・下された決定を骨子として、ルーブリックのドラフト(基準行+充足条件)を先に作成し、空欄や曖昧な行をインタビューで埋める。
  • 各行は実装が検証可能な形で記述する — 検証不可能な基準はルーブリックに含めない。
  • インタビュー中に理解の穴が明らかになった場合は、そのノードを掘り下げてから戻る(ディープダイブのルールに従う)。
  • ルーブリックが相手の目標をカバーした場合、完成を提案する。完成判定は相手が行い、以降(仕様文書化・実装)は別途指示による — このスキルの範囲外である。

終了

決定まで尽きた場合、最終的な理解マップと発見表全体を要約して提示し、終了を提案する。終了するかさらに掘り下げるかは相手が決定する。相手はいつでも途中で停止できる。

常時規律

  • 相手が知らなそうな用語は、その場で説明する — スキップするとその後がすべて崩れる。
  • 比喩を使った場合は、実物(実際の例・画面・データ)で着地させる。
  • 断定の前に「なぜそうならざるを得ないのか」を先に提示する。一時的な状態(「今それがないから」)を根拠にせず、設計されていない部品の動作を仮定しない。
  • 既存のルールは名前だけを挙げず、根拠を開いて確認し適用する。
  • 間違えた場合は、番号を付けて明示的に撤回する — 撤回が信頼を高める。
  • オプション比較表で決定を先送りにしない。答えと理由を提示する。

関連スキル