integrate-gestalt
について
このスキルは、`expand-awareness`から得られた複数の視点を統合し、単一の創発的洞察を生成します。領域間の緊張関係と共鳴を分析し、部分の総和を超える一貫した「ゲシュタルト」を形成します。`expand-awareness`の後、`express-insight`の前に使用することで、統合された結論を明確に表現できます。
クイックインストール
Claude Code
推奨npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/integrate-gestaltこのコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします
ドキュメント
Integrate Gestalt
expand-awareness が生んだパノラマ的知覚から一貫した全体を形成する — 平均化、妥協、最良ドメインの答えの選択ではなく、いかなる単一視点からも生じえなかった創発パターンを特定することによって。
使用タイミング
expand-awarenessが複数ドメインから生知覚を表面化させ、観察が統一された洞察になる必要がある- 複数のドメイン視点が利用可能だが、いかなる単一視点もすべての証拠を説明しない
- 問題がいくつかの角度から解析され、別個の解析がリストを超える必要がある
- 「これらすべてを一緒に取ると何を意味するか?」という問いに自明な答えがない
- 統合が「最良ドメインを選ぶ」へ崩壊し続け、新しい何かを形成しないとき
- 形成されたゲシュタルトを入力として要求する
express-insightの前
入力
- 必須:
expand-awareness(または同等のパノラマ的知覚)からのマルチドメイン観察 - 任意: マルチドメインスキャンを促した元の問いまたは問題
- 任意: ゲシュタルトが満たさねばならない既知の制約
- 任意: 以前の失敗した統合試行(単一ドメイン答えに崩壊したもの)
手順
ステップ1: 緊張をマップする
パノラマ的知覚で特定されたドメインの各ペアについて、それらがどう関連するかを特性化する。3 つの可能な関係は緊張(彼らは不一致)、共鳴(異なる角度から強化)、直交(無関係な側面に対処)である。
緊張-共鳴マップを使う:
Tension-Resonance Map
+-------------------+-------------------+-------------------------------+
| Domain Pair | Relationship | Detail |
+-------------------+-------------------+-------------------------------+
| A vs B | tension / | |
| | resonance / | |
| | orthogonal | |
| Evidence: | | What specifically disagrees, |
| | | reinforces, or is unrelated? |
| Implication: | | What does this relationship |
| | | suggest for the whole? |
+-------------------+-------------------+-------------------------------+
| A vs C | ... | ... |
+-------------------+-------------------+-------------------------------+
| B vs C | ... | ... |
+-------------------+-------------------+-------------------------------+
すべてのドメインペアに 1 行を埋める。N ドメインには N(N-1)/2 ペアがある。これが 10 行を超えるなら、まず関連ドメインをグループ化してグループ間でマップする。
緊張を優先する — それらが最も統合的情報を運ぶ。共鳴は確認する; 直交は脇に置ける; しかし緊張は解決を要求し、ゲシュタルトはそれらがどう解決するかに見出される。
期待結果: すべてのドメインペアが具体的証拠と共に特性化された関係を持つ完成した緊張-共鳴マップ。少なくとも一つの真の緊張が特定される — 緊張がなければ、ドメインは創発を生むほど異なっていないかもしれない。
失敗時: すべてのペアが共鳴を示すなら、ドメインは表面レベルで合意している。より深く掘る: どこで彼らは異なる理由で合意するか? 異なる理由の合意は隠れた緊張。関係が特性化できないなら、expand-awareness からのパノラマ的知覚が浅すぎるかもしれない — 統合を試みる前に戻ってドメイン固有観察を深める。
ステップ2: 図を見出す
ゲシュタルト心理学では、図は地から創発する。地はステップ1 からの緊張-共鳴マップ。図は最少の矛盾で最多のドメインを統一する支配パターン。
- マップでクラスタをスキャン: どのドメインのグループが互いに共鳴するか? これらのクラスタが候補図を示唆する
- 各候補図について問う: 「最多の観察を意味付ける単一視点は何か?」
- 図は妥協(合意するまで各ドメインを弱める)でも選択(最強ドメインを選ぶ)でもない。それはドメイン観察を再文脈化する新しい枠組み
- テスト: 候補図を一文で述べる。それは入力ドメインの一つに属するように感じるか? イエスなら、まだゲシュタルトではない — 変装した domain answer
- 緊張を特に見る: 真の図は両ドメインの位置ではなく、不一致するドメイン間の空間にしばしば住む
図が創発している兆候:
- 同じ再フレーム下で複数の緊張が同時に解決する
- 矛盾していたドメイン観察が同じ現象の補完的側面となる
- 図が、なぜ各ドメインが見たものを見たかを、なぜ不一致したかを含めて説明する
期待結果: 一つまたは二つの候補図が単一文として articulated される。各候補はドメイン観察から選択するのではなく、それらを再文脈化する。候補はマップの主要緊張を少なくとも説明する。
失敗時: 図が現れないなら、統合は早すぎるかもしれない。2 つの回復経路: (a) expand-awareness に戻り、欠けていたドメインを加える — 鍵となる視点が不在のため図が形成できないことがある; (b) 解決を強制せずに緊張と座る — 一部のゲシュタルトは努力ではなく孵卵を必要とする。現在の状態を記し後で戻る。
ステップ3: 全体をテストする
ステップ2 の候補ゲシュタルトは受け入れられる前に 3 つのテストを生き残らねばならない。
Test A — 緊張説明: ステップ1 のすべての緊張を歩く。ゲシュタルトはそれを解決するか、再フレームするか、既約トレードオフとして明示的に承認するか? 未対処の緊張は早すぎるゲシュタルトを示す。
Test B — 単一ドメイン起源: この洞察は単一ドメイン内から来たかもしれないか? ドメイン専門家が頷いて「はい、既に知っていた」と言うなら、ゲシュタルトはドメイン答えに崩壊し戻った。真のゲシュタルトはすべてのドメインを驚かせる — 各々は自分の貢献を認識するが全体は認識しない。
Test C — 回転下の一貫性: 各ドメインの視点から順番にゲシュタルトに mentally に近づく。形を保つか、どのドメインから見るかに依って違って見えるか? 堅牢なゲシュタルトは任意の角度から見られた同じ洞察; 脆弱なものは回転下で意味を変える。
採点:
- 3 テストすべてパス: ステップ4 へ進む
- Test A 失敗: ゲシュタルトは不完全 — 未解決緊張を追加制約としてステップ2 に戻る
- Test B 失敗: ゲシュタルトは創発的でない — ステップ2 に戻り単一ドメインフレーミングを明示的に除外する
- Test C 失敗: ゲシュタルトは一貫していない — 一つに装った 2 つの別個の洞察かもしれない。分割し各半分を独立にテスト
期待結果: 候補ゲシュタルトが 3 テストすべてをパスするか、失敗モードが明確に特定されステップ2 への戻りを導く。
失敗時: 候補が複数反復後に繰り返し失敗するなら、この問題にとってドメインが自然なゲシュタルトを形成しないかもしれないと考える。すべてのマルチドメイン観察が創発を生むわけではない — 時には正直な答えは緊張がマップされたドメイン視点の構造化リスト。偽の統一を強制するのではなく緊張-共鳴マップを出力として届ける。
ステップ4: 洞察を名指す
ドメイン専門家が彼らのドメイン内から単独で書かなかったような単一文でゲシュタルトを articulate する。この文が成果物。
- 文を書く。それは:
- 行動可能または反証可能であるに十分具体的
- すべての貢献ドメインを包含するに十分一般的
- 入力ドメインのうち少なくとも 2 つを驚かせる
- いかなる単一ドメインのジャーゴンからも自由(または意図的に再文脈化されたジャーゴンを使う)
- ステップ3 の 3 基準に対して文を最終的にテスト
- 任意で、ゲシュタルトがドメイン貢献からどう創発したかを辿る一段落の拡張を加える — これは由来であり、洞察自体ではない
- どのドメインが貢献したか、どの緊張が鍵だったか、図-地関係が何だったかを記録 — このメタデータは将来の統合試行をサポート
名指された洞察は、その由来と共に、コミュニケーション用に express-insight への入力になる。
期待結果: ゲシュタルトを捉える単一文、簡潔な由来段落を伴う。文は「単一ドメインなし」テストをパスする。それを読み、いかなる貢献ドメインの実践者も自分の分野の貢献を認識するが、単独でその陳述に到達できなかっただろう。
失敗時: 文がドメイン言語に崩壊し続けるなら、否定テストを試す: ゲシュタルトが何でないかを述べる。「これはセキュリティ推奨でも、性能最適化でも、アーキテクチャパターンでもない — それは [ゲシュタルト]」。否定はドメインフレームをクリアし創発的定式化のための空間を作る。
バリデーション
- すべてのドメインペアに対して具体的証拠と共に緊張-共鳴マップが完成された
- 少なくとも一つの真の緊張(強調の単なる違いではない)が特定された
- 候補ゲシュタルトが妥協または選択ではなく再フレームとして articulate された
- Test A パス: すべての主要緊張が解決、再フレーム、または承認された
- Test B パス: いかなる単一ドメインも単独でこの洞察を生めなかった
- Test C パス: 各ドメインの視点から見られたときゲシュタルトが形を保つ
- 最終洞察が由来と共に単一文で表現された
よくある落とし穴
- 平均化: 各ドメインの位置を表面的に合意するまで弱める。これはゲシュタルトではなくマッシュを生む。統合がさえないと感じるなら、それは平均化
- King-making: 最強ドメインの答えを選びマルチドメイン言語で装う。Test B がこれを捕える — 一つのドメイン専門家が驚かずに頷くなら、king-making
- 早すぎる閉鎖: 緊張に対してテストせず最初の候補図を受け入れる。最初に現れる図はしばしば最も自明であり最も統合的でない
- 強制された統一: ドメインが真に直交のときゲシュタルトが存在しなければならないと主張する。直交ドメインはゲシュタルトではなく構造化リストを生む — そしてそれは有効な結果
- ジャーゴンブレンディング: 複数ドメインの技術用語を統合的に聞こえるが何も意味しない文に組み合わせる。最終文の各用語は独立に意味があるべき
関連スキル
expand-awareness— このスキルが統合する生のパノラマ的知覚を生む; 常に integrate-gestalt に先行express-insight— 形成されたゲシュタルトを聴衆にコミュニケート; 常に integrate-gestalt に続くbuild-coherence— 構造化評価を使って競合オプション間で選ぶ; integrate-gestalt は既存オプションから選ぶのではなく新しい全体を形成するbrahma-bhaga— 虚空から創造する; integrate-gestalt は豊富さ(複数の満たされた視点)から創造するmeditate— クリーンな知覚を可能にするため事前文脈をクリアする; このスキルに先行する expand-awareness の前に有用coordinate-reasoning— マルチパス評価で情報フローを管理する; ゲシュタルトが複数推論スレッドの調整を伴うとき補完的
GitHub リポジトリ
関連スキル
evaluating-llms-harness
テストこのClaudeスキルは、lm-evaluation-harnessを実行し、MMLUやGSM8Kなど60以上の標準化学術タスクでLLMをベンチマークします。開発者がモデルの品質を比較し、トレーニングの進捗を追跡し、学術的な結果を報告するために設計されています。このツールはHuggingFaceやvLLMモデルを含む様々なバックエンドをサポートしています。
cloudflare-cron-triggers
テストこのスキルは、cron式を使用してWorkersをスケジュールするためのCloudflare Cron Triggersの実装に関する包括的な知識を提供します。定期的なタスクの設定、メンテナンスジョブ、自動化されたワークフローの構築を網羅し、無効なcron式やタイムゾーン問題といった一般的な課題への対処法も含みます。開発者はこれを使用して、スケジュールされたハンドラーの設定、cronトリガーのテスト、WorkflowsやGreen Computeとの連携を構成できます。
webapp-testing
テストこのClaude Skillは、Playwrightベースのツールキットを提供し、Pythonスクリプトを通じてローカルWebアプリケーションのテストを可能にします。フロントエンドの検証、UIデバッグ、スクリーンショット撮影、ログ表示を実現し、サーバーライフサイクルを管理します。ブラウザ自動化タスクにご利用いただけますが、コンテキストの汚染を避けるため、スクリプトのソースコードを読むのではなく直接実行してください。
finishing-a-development-branch
テストこのスキルは、開発者がテストの合格を確認し、構造化された統合オプションを提示することで、完成した作業を仕上げることを支援します。実装が完了した後のマージ、PR作成、ブランチの整理といったワークフローを案内します。コードが準備できてテスト済みの際に使用し、開発プロセスを体系的に完了させましょう。
