スキル一覧に戻る

adaptic

pjt222
更新日 Yesterday
5 閲覧
17
2
17
GitHubで表示
メタaidesign

について

アドパティックは、3つ以上の領域にわたるパノラマ的統合を実現する5段階のサイクルを調整するマスタースキルであり、逐次的な妥協ではなく統一された理解を生み出します。これは、主要なアーキテクチャ決定前など、領域間の相互作用が極めて重要な複雑なマルチドメイン問題のために設計されています。真の統合には標準的な逐次分析が不十分と感じられる場合に使用してください。

クイックインストール

Claude Code

推奨
メイン
npx skills add pjt222/agent-almanac -a claude-code
プラグインコマンド代替
/plugin add https://github.com/pjt222/agent-almanac
Git クローン代替
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/adaptic

このコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします

ドキュメント

Adaptic

複数ドメインにわたる全景的な統合を達成するため、5ステップのシノプティックサイクルを構成する。逐次分析が妥協(「それぞれを少しずつ」)を生むのに対し、シノプティックサイクルは統合を生む — すべてのドメインを同時に保持し、創発する全体を見出す統一された理解である。

使用タイミング

  • 問題が真に3つ以上のドメインにまたがり、いずれか単一のドメインの深さよりも ドメイン間の相互作用 の方が重要なとき
  • 逐次分析(polymath スタイル)を試したが、その統合が統合というより妥協のように感じられるとき
  • 既存のアプローチが統一されたビジョンというより「それぞれを少しずつ」のように感じられるとき
  • 複数のステークホルダーに影響する重要なアーキテクチャ判断の前
  • ドメイン専門家の意見が分かれ、解決策が彼らの視点の にあり、いずれか一つの内部にはないとき

使用しない場合

  • 単一ドメインの問題 — 該当ドメインのエージェントを直接使う
  • polymath スタイルの逐次分析で十分な、よく理解されたトレードオフ
  • セルフケアやウェルネスの文脈 — 代わりに tending チームを使う
  • 深さよりも速度が重要なとき — フルサイクルは持続的な注意を必要とする

入力

  • 必須: 多ドメインの統合を必要とする問題または問い
  • 任意: 保持するドメインの明示的なリスト(既定: 問題の文脈から自動検出)
  • 任意: 深さ設定 — lightstandarddeep(既定: standard
  • 任意: 表現形式 — narrativediagramtablerecommendation(既定: auto

設定

settings:
  depth: standard          # light (skip meditate), standard, deep (extended perceive)
  domains: auto            # auto-detect or explicit list
  expression_form: auto    # narrative, diagram, table, recommendation

手順

ステップ1: クリア — ワークスペースを空にする

meditate スキルを実行し、事前の文脈、前提、単一ドメイン的なバイアスをクリアする。

  1. meditate の手順全体を実行する: 準備、アンカー、注意散漫の観察、終了
  2. ドメインバイアスに特に注意する — 直近で活性だったドメインを通して問題を枠付けようとする傾向
  3. 全景が見えるより前に到着した、早すぎる解決策をクリアする
  4. depth: light が設定されている場合は、フルメディテーションではなく短い文脈クリアの間(ま)に省略する

期待結果: ワークスペースは空である。優先されるドメインはない。事前選択された解決策はない。エージェントは複数の視点を同時に保持する準備が整った中立で受容的な状態にある。

失敗時: 特定のドメインが「真の問題」として繰り返し主張してくる場合、そのバイアスを明示的に名指す: 「私はこれを主に [ドメイン] の問題として枠付けていることに気づく」。バイアスを名指すことで、その握力は緩む。クリアリングが完全に失敗する場合、問題は真に単一ドメインかもしれない — シノプティックサイクルが必要かを再考する。

ステップ2: 開く — パノラマモードに入る

expand-awareness スキルを実行し、狭い焦点から広視野の知覚へと移行する。

  1. 問題に関連するすべてのドメインを棚卸しする — 事前にフィルタリングや順位付けをしない
  2. 各ドメインについて、その中核的な関心事、制約、価値観を評価せずに記録する
  3. 焦点を緩める: ドメインを一度に一つずつ巡回するのではなく、すべてのドメインを同時に意識に保持する
  4. 「解き始める」という引力に抵抗する — このステップは純粋に視野を開くことに関するものである
  5. 入力でドメインが明示的に指定されている場合は、それを開始セットとして使用しつつ、追加の関連ドメインを発見することにも開かれていること

期待結果: パノラマフィールドが開いている。すべての関連ドメインが同時に意識に保持されている。エージェントは、いずれか単一のドメインへとズームインすることなく、全景を感知できる。圧倒される感覚ではなく、広々とした感覚がある。

失敗時: ドメインリストが不完全に感じられる場合、問う: 「絵を変えるために欠けている視点は何か?」同時的な意識が逐次的なスキャン(ドメインA、次にB、次にC)に崩壊してしまう場合、ペースを落とす — 目標は全フィールドを保持することであり、その部分を巡ることではない。7つを超えるドメインが活性化している場合、関連するドメインをクラスタにまとめて、幅を維持しつつ認知負荷を下げる。

ステップ3: 知覚 — クロスドメインのパターンに気づく

パノラマ的な意識を維持しながら、observeawareness を実行し、見えるすべてのドメインを またいで パターン、緊張、共鳴に気づく。

  1. ステップ2のパノラマフィールドを開いたままにする — 焦点を狭めない
  2. observe を実行して、実際に存在しているものに気づく: ドメインを越えて繰り返されるパターンは何か?ドメイン間にどんな緊張があるか?一見無関係な関心事を結ぶ共鳴は何か?
  3. awareness を実行して、見られていないもの に気づく: どのドメインが微妙に無視されているか?盲点はどこにあるか?水面下でどんな前提が働いているか?
  4. クロスドメインの観察を、まだ解釈せずに記録する:
    • 緊張: ドメインが反対方向に引っ張り合うところ
    • 共鳴: ドメインが互いを強化または響かせ合うところ
    • ギャップ: 全景が明らかにする関心事に、どのドメインも対応していないところ
    • 驚き: あるドメインが絵に予想外の何かを寄与するところ
  5. depth: deep が設定されている場合、このステップを延長する — observe と awareness を複数回循環させ、より微細なパターンが浮上するのを許す

決定的な規律: 各ドメインを順番にではなく、すべてのドメインを同時にまたいで知覚する。逐次的な知覚は、シノプティックサイクルの全要点であるクロスドメインのパターンを失わせる。

期待結果: クロスドメインの観察 — 緊張、共鳴、ギャップ、驚き — の豊かな集合。これらの観察はドメイン間の境界をまたぐもので、いずれか単一のドメインの内部に住むものではない。エージェントは、いずれか単一のドメインの視点からは見えないものに気づいている。

失敗時: 観察がすべて単一ドメイン内のもの(「ドメインAでXに気づく」)の場合、パノラマフィールドは崩壊している。ステップ2に戻り、再び開く。クロスドメインのパターンが現れない場合、問題はシノプティックな扱いを必要としないかもしれない — 真に独立したドメイン問題に分解可能かもしれない。知覚ステップが圧倒的な数の観察を生む場合、緊張を優先する(緊張のあるところで統合が起きる)。

ステップ4: 統合 — 創発する全体を形成する

integrate-gestalt スキルを実行し、クロスドメインの観察を統一された理解へと統合する。

  1. ステップ3で特定された緊張をマップする — 早すぎる解決はせず、創造的な制約として保持する
  2. 図を見出す: すべての観察を一緒に保持したとき、どんな統一された理解が現れるか?これは妥協でも平均でもない — 個々のドメインの視点を含みつつ超える新しいパターンである
  3. 全体をテストする: 統合された理解は各ドメインの中核的な関心事を尊重しているか?緊張を解決しているか、それとも単に紙で覆っているだけか?
  4. 洞察を一つの明確な文で名指す — 単純に述べられないなら、統合はまだ完了していない
  5. 洞察が真に創発的であることを検証する: ドメインを逐次的に分析することで到達できたか?イエスならば、シノプティックサイクルは価値を加えておらず、逐次分析で十分だっただろう

期待結果: すべてのドメインを同時に保持する単一の統合された理解。洞察は構築というよりも発見のように感じられる — それは部分から組み立てられたのではなく、全体から創発した。各ドメインの中核的な関心事は尊重され、ドメイン間の緊張は妥協ではなく解決される。

失敗時: 統合が統一された全体ではなく「各ドメインを少しずつ」を生み出す場合、ゲシュタルトはまだ形成されていない。ステップ3に戻り、回避されている緊張を探す — 統合は緊張を 通して 起こる、緊張を回避してではない。長時間の努力の後にゲシュタルトが形成されない場合、分解する: 最も強い緊張を持つ2〜3のドメインを見つけ、まずそれらを統合し、それから拡張する。

ステップ5: 表現 — 統合された理解を伝える

express-insight スキルを実行し、統合を意図された聴衆に伝える。

  1. 聴衆を評価する: 彼らはどのドメインに馴染みがあるか?どのフレーミングが統合された洞察をアクセス可能にするか?
  2. 表現形式を選ぶ(または入力で指定されたものを使う):
    • Narrative: 部分から全体への旅を理解する必要のある聴衆向け
    • Diagram: 構造的関係を見る必要のある聴衆向け
    • Table: ドメインの視点を体系的に比較する必要のある聴衆向け
    • Recommendation: 行動可能な意思決定が必要な聴衆向け
  3. 統合された理解を透明性とともに表現する: どのドメインが寄与したか、どこで緊張が解決されたか、創発的な洞察がいずれか単一の視点を超えて何を加えるかを示す
  4. 挑戦を招く: 統合のどの側面が最も強く、どの側面が最も思弁的かを明示的に記す

期待結果: 意図された聴衆にアクセス可能な、統合された理解の明確で整った表現。表現はその作業を見せる — 聴衆はドメインの視点が全体にどう寄与したかを見ることができる。形式は聴衆のニーズに合致している。

失敗時: 表現が統合された全体ではなくドメイン視点のリストのように感じられる場合、ステップ4の洞察は翻訳の中で失われている。ステップ4のひとつの文の要約に戻り、その中心から表現を外側へ構築する。聴衆のフレーミングが間違っている場合、問う: 「これを必要とするのは誰で、どんな決定に役立つか?」

バリデーション

  • ステップ1(クリア)が実行された — 事前の文脈とドメインバイアスが明示的に手放された
  • ステップ2(開く)は3つ以上のドメインを同時に保持するパノラマフィールドを生み出した
  • ステップ3(知覚)はクロスドメインのパターンを特定した(ドメイン内の観察だけではない)
  • ステップ4(統合)は個々のドメインを超える単一の創発的洞察を生み出した
  • ステップ5(表現)は聴衆に適した形式で洞察を伝えた
  • 最終出力は逐次的な単一ドメイン分析では生み出せなかった
  • 各ドメインの中核的関心事が統合された理解の中で尊重されている
  • ドメイン間の緊張は妥協ではなく統合を通して解決された

よくある落とし穴

  • 同時を装う逐次: ドメインを一度に一つずつ巡回し、結果を後でホチキス止めするのはシノプティックな知覚ではない。テスト: クロスドメインの 相互作用 が新しい何かを生み出したか、それとも出力はドメイン分析の連結に過ぎないか?
  • 早すぎる統合: パノラマフィールドが完全に開く前に統合へ飛び付く。ステップ2と3は真の統合を可能にする知覚的基盤を構築する — それらを急ぐと浅い統合を生む。
  • 創発ではなく妥協: ドメイン視点の平均化(「セキュリティ50%、ユーザビリティ50%」)は妥協であり、統合ではない。真の統合は両方の関心事が 完全に 満たされるフレームを見出すか、もしくは既約のトレードオフを正直に名指す。
  • 単一ドメイン問題への過剰使用: すべての問題がパノラマ的な統合を必要とするわけではない。問題が一つのドメインにきれいに収まるなら、シノプティックな扱いは価値を加えずにオーバーヘッドだけを加える。「使用しない場合」の基準は理由があって存在する。
  • 表現で洞察を失う: ステップ4は明確なゲシュタルトを生み出すが、ステップ5がそれをドメインごとのリストへ断片化してしまう。統合された洞察を表現の中心として保持し、ドメインの詳細は主構造ではなく支持証拠とする。
  • ドメインの水増し: シノプティックな扱いを正当化するためにドメイン数を人為的に拡張すること。真に関連する3つのドメインの方が、4つが周辺的な7つのドメインよりも良い統合を生む。

関連スキル

  • meditate — サイクルのステップ1; 文脈をクリアし、中立な開始状態を確立する
  • expand-awareness — サイクルのステップ2; 狭い焦点からパノラマ的な知覚へ移行する
  • observe — ステップ3で使用; フィールドにわたって存在するものに気づく
  • awareness — ステップ3で使用; 見られていないものに気づき、盲点を明らかにする
  • integrate-gestalt — サイクルのステップ4; クロスドメインのパターンから創発する全体を形成する
  • express-insight — サイクルのステップ5; 統合された理解を伝える

GitHub リポジトリ

pjt222/agent-almanac
パス: i18n/ja/skills/adaptic
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

関連スキル

content-collections

メタ

このスキルは、Content Collections(Markdown/MDXファイルを型安全なデータコレクションに変換するTypeScriptファーストのツール)の本番環境でテストされた設定を提供します。Zodバリデーションによる型安全性を実現し、ブログ、ドキュメントサイト、コンテンツ重視のVite + Reactアプリケーション構築時にご利用ください。Viteプラグインの設定、MDXコンパイルから、デプロイ最適化、スキーマバリデーションまで、すべてを網羅しています。

スキルを見る

polymarket

メタ

このスキルは、開発者がPolymarket予測市場プラットフォームを活用したアプリケーション構築を可能にします。API統合による取引や市場データの取得に加え、WebSocketを介したリアルタイムデータストリーミングにより、ライブ取引や市場活動を監視できます。取引戦略の実装や、ライブ市場更新を処理するツールの作成にご利用ください。

スキルを見る

creating-opencode-plugins

メタ

このスキルは、開発者がコマンド、ファイル、LSP操作など25種類以上のイベントタイプにフックするOpenCodeプラグインを作成することを支援します。JavaScript/TypeScriptモジュール向けに、プラグイン構造、イベントAPI仕様、および実装パターンを提供します。カスタムイベント駆動ロジックでOpenCode AIアシスタントのライフサイクルをインターセプト、監視、または拡張する必要がある場合にご利用ください。

スキルを見る

sglang

メタ

SGLangは、高性能なLLMサービングフレームワークであり、RadixAttentionプレフィックスキャッシュを活用したJSON、正規表現、エージェントワークフロー向けの高速で構造化された生成を特長とします。特にプレフィックスが繰り返されるタスクにおいて、大幅に高速な推論を実現し、複雑な構造化出力やマルチターン対話に最適です。制約付きデコードが必要な場合や、広範なプレフィックス共有を伴うアプリケーションを構築する場合は、vLLMなどの代替案ではなくSGLangを選択してください。

スキルを見る