mcpField
C
crossthink

crossthink

github.com/lilmgenius生産性1.4k11 回インストール3 日前に更新
リポジトリ

crossthink について

crossthinkは、問題解決の仕組みを異分野から探る読み取り専用スキルです。まず現行の枠内にある選択肢を整理し、他分野の実際に機能する仕組みを対応づけ、転用が失敗する条件も示します。

主な機能

  1. 01現行の枠内の選択肢を先に列挙
  2. 02異分野の実際の仕組みを対応づけ
  3. 03対応関係と失敗条件を明示
  4. 04重複をまとめ、却下案も記録
  5. 05検証に使う次の観察を提示

活用シーン

  1. 01行き詰まった問題の新たな仕組み探し
  2. 02異分野の案が使える条件の検討
  3. 03提案が既存案に何を加えるかの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/lilmgenius/paperthin --skill crossthink

インストール後、Claude Code で/crossthinkを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

問題固有のフレームがすでに提供しているものを列挙し、離れた分野の有効な仕組みを借りて、そのリストにないものだけを残します。

目標

一つのフレームにとらわれた問題は、同じ経路のバリエーションばかりを生み出します。別の分野ですでに機能している仕組みは、フレームが隠している経路を開けることがあります。ただし、移転が実務的である場合に限ります。つまり、元の仕組みが実在し、対象への対応づけで、ここでは誰または何がどの手順を実行するのかが示され、この状況のどの条件で機能しなくなるかが明記されている必要があります。実行結果として、機能しなくなる条件を添えた新しい仕組みが返されるか、対応づけから見つかったものはないと正直に示されます。

対応づけは直接の生成に取って代わるものではありません。試した問題では、直接の生成のほうが利用可能な仕組みを多く見つけましたが、対応づけも、直接の生成では見つからなかった仕組みを見つけました。その大半は、障害が続く間も作業の安全を保つ方法(照合、代替物を使った段階的な実施、エスカレーション、テキストとして保持する調査結果)でした。

ワークフロー

  1. 問題とそのフレームを明確にします。 目標、厳しい制約、明示された未知の事項、そして現在の選択肢を狭めているフレームを記述します。つまり、現在の選択肢がすべてたどる経路と、あれば、それらが待っている手順を記します。問題の事実はそのまま保ち、セッションで好まれている答えは除きます。
  2. まずフレーム自体が持つ選択肢を列挙します。 問題から直接導かれる、異なる仕組みを一行ずつ記します。ここでどのように機能し、何が必要かを示します。このリストが対応づけを評価する基準になるため、分野を選ぶ前に作成してください。
  3. 5行が承認されるまで、離れた分野を対応づけます。 問題の分野から遠い分野(物流、生物学、法律、金融、映画、ゲーム、ハードウェア、認知科学、不動産など)を選びます。それぞれについて、次の3つのセルを埋めます。
    • 元の仕組み:その分野で実際に機能する操作または因果プロセスを、標語ではなく、何が起きるのかとして記します。
    • 対象への対応づけ:ここで得られる具体的な選択肢を示し、誰または何がどの手順を実行するのか、また何が必要かを記します。
    • 機能しなくなる条件:この状況で移転が失敗する具体的な条件と、対処可能な場合はその対処方法を示します。「うまくいかないことがある」や、コストだけでは条件になりません。
  4. 移転できないものを除外します。 セルが空の行、背後に操作がなく言葉を言い換えただけの対応づけ、機能する操作として記述できない元の仕組み(未検証として除外します。この工程では情報源を確認しません)は、理由を添えて却下リストに入れます。
  5. まとめて差し引きます。 同じ機能する操作を共有する行は、1つの仕組みにまとめます。分野、ベンダー、ツール、パラメーター、表現が異なるだけでは、新しい仕組みにはなりません。手順2のリストにすでにある仕組みはすべて、理由 already direct: <its step 2 line> を添えて却下リストに移します。残ったものが結果です。
  6. 報告します。 新しい仕組みを先頭に示し、それぞれについて分野、対象への対応づけ、機能しなくなる条件を記します。まず障害を取り除くものを示し、次に障害が続く間に損害を抑えるものを示します。最初の仕組みを確認または否定できる、最も低コストの観察を記します。最後に却下リストを示します。新しい仕組みがゼロ件でも問題ありません。その場合はそう明記し、手順2のリストを回答として残します。

ルール

  • 直接の選択肢を最初に記し、対応づけで置き換えてはいけません。対応づけは、何を追加するかだけで評価します。
  • 却下した行は理由を添えて保持し、削除してはいけません。
  • 元の分野に関する事実を捏造してはいけません。主張を情報源に照らして確認する作業は factchk に属します。
  • 同じ判断を、より大きな規模、目的、または期間で読み直すのは垂直的な読み取りであり、macrothink に属します。このスキルが行うのは、分野をまたぐ水平的な読み取りです。
  • 読み取り専用かつ助言のみを行います。選択肢を提案するだけで、何も変更しません。また、どれを選ぶかの判断は本来の作業に委ねます。

検証

完了する前に、次の点を確認してください。

  1. フレームとステップ2のリストが、ドメインをマッピングする前に作成されています。
  2. 少なくとも5行が採用されています。各行に、ソースの仕組み、対象へのマッピング、具体的な機能しなくなる状況が記載されています。
  3. 報告された仕組みがステップ2のリストにすでに載っているものではなく、同じ操作を共有する行は統合されています。
  4. 却下された行は、すでに直接対応しているものも含め、すべて理由とともに記載されています。
  5. レポートには次に観察する項目が1つ記載されているか、マッピングによって何も追加されなかったことが明記されています。

コメント