LLMエージェントに求められる役割は、質問に答えることから、スライド作成やスプレッドシート編集、3Dシーンの構築、CAD設計、音楽制作まで、実際にソフトウェアを操作して成果物を仕上げることへと広がっています。こうしたタスクをこなすうえで重要なのは孤立した知識ではなく、目標をどう分解し、どのツールを使い、途中経過をどう確認し、失敗からどう立て直すかという再利用可能な手順知識です。ところが、この手順知識を蓄えるスキルライブラリの多くは専門家による手書きか、エージェント自身の実行履歴、あるいはテキストやコードからのマイニングに限られており、人が最も自然に技術を学ぶ手段であるチュートリアル動画はほとんど活用されてきませんでした。

こうした状況に対して、動画・コードリポジトリ・記事・参考成果物といった人間が作成したマルチモーダルなリソースを、階層的で実行可能な「Skill Wiki(スキル知識をカテゴリごとに整理した参照用のデータベース)」に蒸留するResource2Skillというフレームワークが登場しました。スライド作成やWeb制作、3Dシーン制作、リアルタイム3D制作、CAD設計、表計算、音楽制作という7つの実務ドメインを対象にした検証では、このスキルライブラリへのアクセスがスキルなしのエージェントに対して平均11.9ポイントのスコア向上をもたらし、Claude CodeやCodex CLIといった市販の実行基盤よりも高い性能を示しました。

この記事では、動画のような扱いにくいリソースをどのようにして実行可能なスキルへ変換しているのかという仕組みの部分から、7つのドメインで得られた具体的な実験結果、スキルライブラリの規模やオンライン獲得の効果を切り分けた分析、そして実務に導入する際のヒントと限界まで、順を追って解説します。

1. テキスト中心のスキルライブラリが見落としてきたもの

LLMエージェントは質問応答だけでなく、ソフトウェアを操作して高品質な成果物を作ることを期待される場面が増えています。こうしたタスクの成否を左右するのは孤立した事実知識ではなく、目標をどう分解し、どのツールやAPIパターンを使い、途中の状態をどう確認し、操作に失敗したときにどう立て直すかという再利用可能な手順知識(Procedural Knowledge)です。エージェント分野ではこの手順知識を「スキル」と呼び、経験を再利用可能な専門知に変換する自然な抽象化として位置づけてきました。

しかし既存のスキルライブラリには、作られ方に大きな偏りがあります。単一ドメインでのエージェント自身の実行履歴から蓄積していく方式や、専門家が手作業でテキスト・コード・アセットをパッケージ化する方式、あるいはテキストやコードのコーパスから上位下位関係を持つ知識ツリーとしてマイニングする方式が中心で、人間が技術を学ぶ際に最も自然な手段であるチュートリアル動画や画面録画のワークフローはほとんど活用されてきませんでした。動画チュートリアルには、操作の時間的な順序、各編集ステップが画面に与える視覚的な効果、テキストだけでは説明しづらい暗黙の設計判断が凝縮されています。

一方で、動画を扱うのは簡単ではありません。動画をそのままエージェントのメモリに入れるのはコストが高く冗長な上、不要なセットアップや繰り返しの説明も多く含まれます。かといって動画をテキスト要約に圧縮してしまうと、動的な操作やビフォーアフターの視覚的変化、レイアウト、タイミング、ツール操作の順序といった、動画だからこそ伝えられる情報が失われてしまいます。「動画を含む人間作成のマルチモーダルなリソースから手順知識を自動的に抽出し、ソフトウェアエージェント向けのスケーラブルなスキルライブラリを構築できるか？」という問いに対して、Resource2Skillは実用的な回答を提示しています。

2. 動画やコードを実行可能なスキルへ変換する4段階パイプライン

Resource2Skill の概要と全体像

Resource2Skillは、構築・Wiki化・選択・実行の4段階を、単一のMCP（Model Context Protocol）を介した「閲覧・選択・実行」の一貫したフローに統一したフレームワークです。

一連の処理の流れは以下の通りです。

1. 解析と蒸留: 「動画チュートリアル」「コードリポジトリ」「記事」「参考成果物」の4種類のソースを解析・蒸留します。
2. Wikiへの登録: 厳格な品質ゲートを通過したものだけを、階層構造を持つWikiに登録します。
3. エージェントによる活用: エージェントがWiki内のスキルを「閲覧して選び、組み合わせる」形で利用します。
4. 成果物の出力: ドメインアダプタを介して、7つの実務ドメイン（PPT・Excel・Web・Blender・UE5・CAD・Reaper）でレンダリングされた成果物を出力します。
5. 評価の仕組み: システムの評価も同じ流れの中に組み込まれています。「完全なWiki」「テキストのみのフラットなライブラリ」「スキルなしのエージェント」を同一のタスク集合で比較し、視覚・音声に対応したLLM judge（採点役のLLM）がルーブリック（評価基準）に基づいてスコアリングを行います。

スキルのデータ構造

1つ1つのスキルは、次のタプルとして定義されます。

$$s = (p, x_{text}, x_{visual}, x_{code}, m)$$

各要素の役割は以下の通りです。

• \(p\)（パス）: ドメインごとのタクソノミー（分類体系）上の位置を示すパス
• \(x_{text}\)（テキスト）: スキルの名前・仕組み・適用条件・入力・期待される効果を記した文章
• \(x_{visual}\)（視覚情報）: サムネイルやスクリーンショットなど
• \(x_{code}\)（コード）: 実行または流用可能なコード断片
• \(m\)（メタデータ）: フィルタリング・監査・出所管理に使うデータ

3つのコンテンツビュー（テキスト・視覚情報・コード）の相互補完:
テキストが「適用条件と仕組み」、コードが「実行のための足場」、視覚情報が「レイアウト・スタイル・動きなどの文章では表現しきれない情報」を担うことで、互いの情報を補完し合っています。

スキル構築オペレータ（Construction Operator）

スキル候補を生成する構築オペレータは、視覚情報に対応したLLM呼び出しとして実装されており、独自の事前学習パラメータは持ちません。1件のリソースに対し、次の3ステップで処理を進めます。

1. リソース取得: ドメインごとのクエリを用いてリソースを取得します。
2. 証拠抽出: モダリティに応じた決定的な前処理を行い、証拠を抽出します（動画＝キーフレーム抽出、コードリポジトリ＝AST（抽象構文木）ベースのコード領域抽出、記事＝段落分割）。
3. 構造化蒸留: 抽出した証拠を、LLMによって構造化されたJSON形式のスキル候補へ蒸留します。

品質ゲート（5つの決定的なチェック）

生成されたスキル候補は、以下の5つのメカニカルな判定をすべて通過しなければWikiに登録されません。

• 完全性: 必須のフロントマター項目とテキスト本文が十分な長さで揃っているか
• 出所の追跡可能性: ソースパスが実際に取得可能なリソースを指しているか
• 重複排除: 出所とドメインから計算した識別子が、既存スキルと重複していないか
• モダリティの一貫性: 宣言されたテキスト・視覚・コードの各ファイルが実際にディスク上に存在するか
• コードの構造的な実行可能性: サンドボックス上で、最小限のサンプル入力に対してコードが実際に動作するか

特徴: この品質ゲートはLLMによる曖昧な採点ではなく、スキーマ検証・ファイル存在確認・サンドボックス上での実行テストなど、機械的かつ確定的な判定で実行されます。

スキルの選択・実行・オンライン拡張

スキルの選択（MetaBrowse）

二段階の仕組みで必要なスキルを選定します。

1. 一次絞り込み: タクソノミー上のパスを含むBM25（語彙の一致度に基づく検索スコアリング手法）スコアを用いて候補を抽出します。
2. 二次選定: LLMが構造化された証拠を読み込み、実際に使用するスキルの部分集合を選択します。適合する候補が存在しない場合は「0件」を選択することも許容されており、既存スキルへ無理に当てはめるのを防ぐ設計になっています。

スキルの実行

エージェントとドメインアダプタは単一のMCPツールサーフェスを共有します。選択されたスキルのコードは、言語モデルによる翻訳を挟むことなく、ドメインのMCPサーバー上で直接実行されます。

コードを持たない「参照専用スキル」であっても無駄にはならず、エージェントがそのテキストや視覚情報を参考に自身でコードを記述する形で活用されます。

オンライン獲得との統合

オフラインのWikiだけで要求をカバーできない場合、同じ構築オペレータをオンラインで動かし、新たなスキルを一時プールとして動的に追加できます。このように、オフライン構築とオンライン獲得は独立した別々のパイプラインではなく、同一メカニズムの使い分けとして統一されています。

3. 7つの実務ドメインにおける4システムの比較

実務ドメインと評価タスクの設定

検証には以下の7つの実務ドメインが選定され、各ドメインで固有の技術スタックが用いられています。

• スライド作成: SVGとして生成した後に .pptx 形式へ変換
• 表計算: openpyxl を利用したExcel操作
• Web制作: HTML/CSS/JS（Playwright でスクリーンショットを取得）
• 3Dシーン制作: bpy をヘッドレス実行するBlender
• リアルタイム3D制作: UE5-MCPブリッジ経由でPythonアクションを実行するUE5
• CAD設計: ezdxf と FreeCAD のレンダラー
• 音楽制作: MCP経由で ReaScript を実行するReaper

タスク（brief）の設計:
各ドメインごとに、スキルライブラリの構築に使ったリソースとは重複しないよう厳格に審査された80件のタスク依頼が用意されています。なお、依頼を作成する担当者には、どのWikiやエージェントが評価に使用されるかをあらかじめ知らせないブラインド設計が採用されています。

比較システムとエージェントバックエンド

検証では、以下の4種類のシステムを比較します。

1. 提案手法（フル構成）: Resource2Skillの全機能を活用する構成。
2. スキルなし構成: スキルライブラリを一切使わず、ドメイン操作ツールに対して自由形式のコードを直接記述させる構成。
3. Claude Code: 市販のエージェント実行基盤をそのまま使用する構成。
4. Codex CLI: 市販のエージェント実行基盤をそのまま使用する構成。

3および4はスキルライブラリを一切マウントしておらず、実行基盤そのものの地力（ベースライン）を測定するために配置されています。

モデル規模に対する頑健性の検証:
これら4つのシステムに対し、以下の4つのエージェントバックエンドを横断的に適用することで、モデル規模の違いに左右されない頑健な結論を導き出せるよう設計されています。

• GPT-5.5
• GPT-5.4
• GPT-5.4 Mini
• GPT-5.4 Nano

評価・採点の仕組み

成果物の評価は、モダリティに応じた自動採点役（LLM judge）が担当します。

• 音声を伴わない6ドメイン: GPT-5.4 のビジョン対応 judge
• 音楽制作ドメイン: GPT-4o 系の音声対応 judge

採点プロセス:

1. ブラインド評価: judge は実験条件のラベルを伏せられた状態で、タスク依頼とレンダリングされた成果物のみを確認します。
2. ルーブリック評価: ドメインごとに定義された5つの評価軸に基づき、各軸 0〜10 点でスコアリングします。
3. 総合スコアの算出: 5つの評価軸の単純平均を総合スコアとします。

信頼性を支える厳格な判定ルール: 成果物が得られなかった場合や、最低品質基準を満たさない場合は、理由を問わず総合スコアを0点として扱う厳格な集計方法が採用されています。

4. スキルアクセスがもたらす一貫した性能向上

全体的な比較結果と平均スコア

主要な比較実験において、モデル×ドメインの全28通りの組み合わせのうち26通りで、スキルを活用する「Resource2Skill」が最良のスコアを記録しました。

全モデル・全ドメインにおける4システムの平均総合スコアの比較は以下の通りです。

システム	平均総合スコア
スキルなし（自由形式コード）	45.0%
Claude Code（市販実行基盤）	50.4%
Codex CLI（市販実行基盤）	50.5%
Resource2Skill（スキルあり）	56.8%

分析のポイント:

• 市販の実行基盤（Claude Code / Codex CLI）も素のエージェントより性能を底上げしますが、Resource2Skillはより強力な方の市販基盤に対しても28セル中26セルで上回る結果となりました。
• 残り2つの例外についてもスコア差は1ポイント以内に収まっています。
• この結果は、性能向上の主因が「実行基盤そのもの」ではなく、「精選されたスキルライブラリの存在」にあることを強く示しています。

ドメイン別の傾向と特徴

ドメインによってスキルの導入による改善幅には大きな違いが見られました。

• 最も改善幅が大きいドメイン（リアルタイム3D制作）:
  • スコアが30〜40ポイント上昇しました。
  • 改善の理由: スキルなしの自由形式コードエージェントでは、UE5のPython APIだけで最低限成立するシーンすら組み立てられず、最低品質基準を満たせずに失敗扱い（0点）となるケースが多いためです。
  • GPT-5.4での具体例:
    • 総合スコア：29.1%（スキルなし） \(\rightarrow\) 67.3%（スキルあり）
    • シーン設計軸：30.7% \(\rightarrow\) 71.4%（+40.7ポイント）
    • 演出全体の完成度軸：11.2% \(\rightarrow\) 71.8%（+60.6ポイント）
• 最も改善幅が小さいドメイン（音楽制作）:
  • スキルなしの状態でもある程度完成度の高い音源を作成できるため、元の地力が高い領域であったことが背景にあります。

全体の傾向: 7ドメインの総合スコアを俯瞰すると、スキルを使うシステムの成績がすべてのドメインで「スキルなし」を包み込むように凌駕しており、特にリアルタイム3D制作においてその差が最も顕著に開いている様子が確認できます。

統計的検証と人手による評価（A/Bテスト）

得られたスコア差は、統計的・人手評価の両面から裏付けられています。

• 統計的有意性:
  • 主要な比較セルにおいて、スキルの有無によるスコア差はいずれも有意水準 0.1% 未満（\(p < 0.001\)）の統計的有意性を示しました。
  • 報告された9セル中8セルでは、さらに厳しい \(p < 10^{-8}\) の水準に達しています。
• 人手によるブラインド A/B 評価:
  • 5人の評価者が2つの成果物を並べて優劣を判定するブラインドテストを200件実施しました。
  • 引き分けを除いた比較のうち85.5%でスキルを使う側が支持され、自動 judge が示した優劣の方向性が人手評価によっても確認できる結果となりました。

5. スキルライブラリの育て方

スキル数と性能向上の関係（スケーリング特性）

スキルの数を0件から完全なライブラリまで段階的に増やしながら性能を計測した結果、どのドメインにおいても「スキル数の増加とともに性能が単調に向上し、200件前後で伸びがほぼ頭打ちになる」傾向が確認されました。

• 0〜200件の区間（最も効果が大きい）:
  • 表計算ドメイン：14.2ポイント改善
  • 音楽制作ドメイン：3.1ポイント改善
• 400件〜完全なライブラリの区間:
  • どのドメインでも0.8ポイント程度の上乗せにとどまる

スキルの役割の変化:

• 初期に追加されるスキル: 共通的な操作や、失敗からの復旧手順などの基礎をカバーします。
• 後から追加されるスキル: ドメイン固有の細かいギャップ（特殊な操作や例外処理など）を埋める役割を果たします。

オフラインライブラリ vs. オンライン獲得

オフラインで事前に構築したライブラリと、実行時に不足をリアルタイムで補う「オンライン獲得」の組み合わせ効果を検証しました。

検証条件:

• 構成比較: 「オフラインのスキルプール（891件）＋最大100件までオンラインで新蒸留したスキルを追加する構成」 vs 「オフラインのみの構成」
• タスク条件: ① 通常のベンチマークタスク、② 未知タスク（あらかじめオフラインプールではカバーしきれないと分かっているタスク）

検証結果:

タスクの種類	オフラインのみ	オンライン追加（最大100件）	変化幅
通常のベンチマーク	65.4%	66.1%	+0.7ポイント（ほぼノイズ範囲）
未知タスク	41.2%	62.8%	+21.6ポイント

結論（オンライン獲得の位置付け）:
オンライン獲得は、常に全体性能を底上げする「ブースター」ではなく、オフラインライブラリの欠損をピンポイントで埋める「ギャップフィラー（隙間補強）」として機能することが明らかになりました。そのため、標準的な評価運用（通常ベンチマーク）では、オフラインのみの構成がデフォルトとして採用されています。

6. 何が効いているのか？（要因分析・アブレーション解析）

性能向上の要因を正確に切り分けるため、複数の観点で条件を絞った比較（アブレーション実験）が実施されています。

階層的Wikiインターフェースの有効性

Wikiの構造が与える影響を検証するため、「スキルなし」「構造を持たないテキスト一覧（フラットライブラリ）」「階層的なWiki」の3条件を比較しました。

• フラットライブラリの時点でも「スキルなし」を上回ります。
• 階層的Wikiは、フラットライブラリをさらに 2.5〜8.2ポイント 上回りました。
• 傾向: 特にカテゴリ構造やコードによる実行の足場が重要となる「表計算」「Web制作」「3Dシーン制作」で大きな差が開きました。
• 分析: 階層的なブラウジングが探索範囲を効率的に絞り込み、コードと視覚情報がテキストだけでは不足する実行の手がかりを正確に補っていることが窺えます。

リソース種別の組み合わせ（動画の圧倒的な重要性）

「動画」「コード」「記事」「参考成果物」の4つのソースのうち、動画を除いた3ソース構成にすると、平均スコアは 68.9% から 59.4% へと急落しました。これは動画のみの単一ソース構成（66.8%）よりも 7.4ポイント低い結果です。

• 低下幅が大きかったドメイン:
  • 表計算：-14.2ポイント
  • Web制作：-11.5ポイント
• 分析: 時間的な操作順序や視覚的な手順が極めて重要なドメインにおいて、動画は他のソースでは代替できない不可欠な情報源であることが示されています。
• 他ソースの補完的役割: 動画以外のソースを追加していく効果は比較的緩やかであり、全ソースを組み合わせた構成は最良の2ソース構成を 0.3〜0.9ポイント 上回る程度にとどまっています（動画以外のソースは主に多様性を確保する役割を果たしています）。

モダリティ（Text / Visual / Code）の相互補完効果

同じリソースプール、同じ受理済みスキル、同じ検索予算のもとで、エージェントに提示するモダリティのみを変化させる実験が行われました。

• テキストのみ: 65.0%（テキスト自体に適用条件やルーティングの手がかりが含まれているため、これだけでも高い性能を発揮）
• テキスト ＋ 視覚情報: +1.9ポイント 上昇
• テキスト ＋ コード: +2.0ポイント 上昇
• フル構成（テキスト ＋ 視覚情報 ＋ コード）: 68.9%（すべてのドメインで最高性能を記録）

結論: 性能向上は単なるテキストメモリの増強ではなく、マルチモーダルなスキル内容そのものの相互補完によってもたらされていることが裏付けられました。

スキル選択戦略（MetaBrowseの優位性）

タクソノミー構造に基づく絞り込みとLLMによる選択を組み合わせた提案手法（MetaBrowse）は、他の5つの選択戦略と比較して全ドメインで最高の成績を収めました。

選択戦略	平均総合スコア
MetaBrowse（タクソノミー × LLM選択）	68.9%
語彙検索（BM25）のみ	66.0%
語彙検索 ＋ 密ベクトル検索の再ランキング	64.2%
密ベクトル検索のみ	60.0%
ライブラリからのランダム抽出	58.0%
スキルなし	57.3%

分析:
単純な検索類似度だけでは捉えきれない「タスクとの適合性」を、タクソノミー構造を用いた絞り込みが見事に補完しています。特に「表計算」「スライド作成」「3Dシーン制作」において、最も強力な検索専用ベースラインとの間で顕著なスコア差が開く結果となりました。

7. 導入する際の実務上のポイントと限界

コンテキストコスト（トークン消費量）とスケーラビリティ

実務運用へ組み込む際の重要な検討事項である「追加コンテキスト消費量」と処理フローの詳細は以下の通りです。

スキルのデータ量と選択のステップ:

• 1件のスキルエントリ: フロントマター・構造化テキスト本文・実行可能コードを合わせて平均 約4,332トークン で構成されます。
• ステップ1（一次絞り込み）: BM25を用いてタクソノミー全体から候補を 20件 に絞り込みます。
• ステップ2（二次選択）: 絞り込んだ20件の軽量なフロントマター（1件あたり200〜500トークン程度）のみをLLMセレクタに提示します。
• ステップ3（展開・提示）: 最終的に選ばれた 5件 のスキル全文をエージェントに公開・適用します。

タスクあたりの追加トークン消費の内訳:

• 選択ステップ（フロントマター提示）：4,000〜10,000トークン
• 展開ステップ（5件の全文公開）：約22,000トークン
• 合計追加トークン量：約26,000〜32,000トークン

実務上のポイント: BM25による絞り込み件数（20件）と最終選択数（5件）が固定されているため、ライブラリ全体の規模が拡大しても1タスクあたりの追加コンテキスト量は増加しません。 既存モデルのコンテキストウィンドウ内に十分収まる設計となっています。

実行基盤への組み込みと実務的含意

Claude Code や Codex CLI といった既存の市販実行基盤に本手法を組み込むだけで、「実行基盤そのものを強化するよりも大きな性能向上」が得られることが実証されました。

この結果は、成果物の品質を左右する主要な変数が「実行基盤の作り込み」ではなく、その上流に配置される「スキルライブラリの品質」にある可能性を強力に示唆しています。

システムの主要な限界

実用化にあたっては、以下の3つの限界点にも留意が必要です。

1. LLM judge依存のスコアリング:
   • 評価の多くをLLM judgeに依存しています。17件のタスクを対象とした人手評価との一致度は、総合軸でスピアマン相関 0.71、級内相関係数 0.66 となっています。
   • 特に「実用性」を測る評価軸では、インタラクティブ性が欠けていても見た目の機能性を過大評価しやすい不一致が報告されています（※なお、同一judgeを2回実行した際の一致度は 0.83 であり、judge自体の再現性は人間とjudge間の差よりも高いことが確認されています）。
2. オンライン獲得のレイテンシコスト:
   • オンラインでのスキル獲得（検索・蒸留・検証）は通常の実行より処理時間がかかるため、常用ではなく限定的な「ギャップフィラー（隙間補強）」としての位置づけにとどまります。
3. 生リソースとの同一予算比較の未実施:
   • 本研究における検索ベースライン（BM25や密ベクトル検索）との比較は、あくまで「蒸留済みWiki」の上で行われたものです。動画や記事などの「生のリソースコーパス」に対し、同等のトークン予算で直接検索した場合との比較検証は今後の課題とされています。

分析から見えた2つの典型的な失敗パターン

具体的な成功例・失敗例の精査から、以下の2パターンの失敗傾向が特定されています。

• 部分的なグラウンディング不足:
  • 検索されたスキルの表面的なパターンは取り込めるものの、配色や数式の参照先といった細かいパラメータが最終成果物に反映されない現象。
  • 具体例: Web制作における仕上げの低さ、表計算におけるセル参照エラー、3Dシーン制作における露出過多なレンダリングなど。
• 保守的な合成（パターンの固執）:
  • スキルが提示する単一のパターンに頼りすぎるあまり、スキルなしのエージェントが偶発的に生み出すようなバリエーションや変化が失われる現象。
  • 具体例: プレゼン資料でのプレースホルダーの残留、音楽制作でのセクション展開の乏しさなど。

おわりに

動画チュートリアル、コードリポジトリ、記事、参考成果物といった、従来のAIエージェント開発では活用が進んでいなかった人間作成のマルチモーダルリソースを、階層的かつ実行可能な「Skill Wiki」へと蒸留するアプローチは、7つの実務ドメインおよび4つのエージェントバックエンドを横断して、平均11.9ポイントという一貫した性能向上を実証しました。

本研究からは、スキルライブラリを実際に設計・運用する上で極めて有益な知見が提示されています。特に、「動画が他で代替できない決定的な情報源であること」、「ライブラリの規模は無制限に拡張すべきではなく200件前後で効果が頭打ちになること」、そして「オンライン獲得は常時機能するブースターではなく未知タスクに対するギャップフィラーとして機能すること」といった点は、今後のシステム設計における重要な指針となります。

実務においてエージェント基盤を構築する観点では、既存の実行基盤自体を作り込むこと以上に、その上流に「いかに高品質なマルチモーダルスキルライブラリを配置できるか」が成果物の品質を左右するという示唆は非常に有意義です。

一方で、評価体系がLLM judgeに依存している点や、生のリソースコーパスと同等トークン予算で比較されていない点、オンライン獲得時のレイテンシコストなど、実際の導入にあたって考慮すべき限界も明確になっています。今後は、プログラム的ツールインターフェースや公開手順のないドメインへの適用範囲の拡大、オンライン獲得のコスト最適化などが主要な課題となります。これまで扱いの難しかった動画リソースを再現可能な手順知識へと変換できる道筋を示した成果は大きく、対象ドメインの広がりに伴い、この設計思想の重要性は一層高まっていくと考えられます。

More Information

• arXiv:2606.29538, Yijia Fan et al., 「RESOURCE2SKILL: Distilling Executable Agent Skills from Human-Created Multimodal Resources」, https://arxiv.org/abs/2606.29538