create-adapter

アダプターを作成する

Harbor リポジトリで新しいベンチマークアダプターをブートストラップします。このスキルでは、harbor adapter init を使ってアダプターのディレクトリを生成し、その後の実装に関するすべての判断はアダプターのチュートリアルに従います。

参照する仕様

アダプターのチュートリアルは、このスキルにおける正式な仕様です。スキャフォールディング以外の操作を行う前に、最後まで読んでください。

adapters/ADAPTER_CONTRIBUTING.md

このパスは Harbor リポジトリのルートからの相対パスです（このスキルの前提条件については、以下を参照してください）。チュートリアルには、以下の内容が記載されています。

• 生成するタスクとアダプターコードパッケージに必要なディレクトリ構造。
• ベンチマークの分析、オラクルの検証、パリティ実験、データセットの登録、提出を扱う手順（ステップ 1～9）。
• task.toml、parity_experiment.json、adapter_metadata.json、dataset.toml のスキーマ。
• パリティのマッチング条件、事前チェックリスト、デバッグ手順。
• README の形式ルール（機械的に解析されるため、逸脱すると自動化が機能しなくなります）。

このファイルの内容を、以前からの知識で置き換えないでください。これを仕様として扱ってください。

前提条件

• Harbor CLI がインストールされ、PATH から利用できること（harbor --version が成功すること）。
• 作業ディレクトリが Harbor リポジトリのルートであること。
• Harbor のチェックアウトが最新であること：git fetch origin && git status を実行し、遅れている場合は main をプルしてください。古いチェックアウトでは、最近のアダプターやエージェントの修正が反映されず、後のパリティ検証で誤った失敗が発生する原因になります。

ワークフロー

1. チュートリアルを読む

ファイルシステムや CLI を操作する前に、adapters/ADAPTER_CONTRIBUTING.md を最後まで読んでください。特に以下の内容に注意してください。

• Required Directory Structures — 生成するタスクとアダプターのレイアウトに関する仕様です。
• Step 1. Understand the Original Benchmark — コーディング前に、上流プロジェクトについて特定すべき内容です。
• Step 8. Register the Dataset → Naming rules — name フィールドと <org>/<task> 形式の要件です。

2. ユーザーからベンチマークの情報を集める

スキャフォールディングの前に、以下の情報を集めてください。ユーザーがまだ情報を提示していない場合は、作業を進める前に確認してください。これらの情報は、スキャフォールドと、その後のチュートリアルの手順に影響します。

フィールド	重要な理由
アダプター名	小文字で、ハイフン区切りにします。ベンチマークで一般的に使われる識別子（例：swe-bench、aider-polyglot）と一致する必要があります。adapters/ 配下のディレクトリ名になり、アンダースコアに変換された後は Python パッケージ名になります。
人が読める名前	--name で渡し、生成される README に表示されます。
上流リポジトリの URL	チュートリアルのステップ 1（ベンチマークの分析）と、後で設定する original_parity_repo フィールドに必要です。
オラクルソリューションの有無	ベンチマークに参照ソリューションが含まれている場合は、それを使用します。含まれていない場合、オラクルソリューションは LLM で生成する必要があります（チュートリアルのステップ 3 →「Benchmarks without oracle solutions」）。
エージェントのシナリオ	ステップ 4 のどのシナリオに該当するかを確認します：（1）互換性のある既存のエージェント、（2）フォークして LLM エージェントを追加、（3）カスタムエージェント。この選択により、パリティ計画が決まります。

3. アダプター用のブランチを作成する

チュートリアルのステップ 2 に従って、専用ブランチで作業してください。

git checkout -b <adapter-name>-adapter

4. スキャフォールドを実行する

名前が両方とも決まっている場合は、非対話形式を優先してください。

harbor adapter init <adapter-name> --name "<Human-Readable Name>"

それ以外の場合は、harbor adapter init を対話形式で実行し、CLI のプロンプトに従ってください。

期待される出力：pyproject.toml、README.md、src/<adapter_name>/、および src/<adapter_name>/task-template/ 配下のタスクテンプレートファイルを含む、新しい adapters/<adapter-name>/ ディレクトリ。続行する前に、ディレクトリが存在することを確認してください。

5. チュートリアルに引き継ぐ

チュートリアルの「Step 1. Understand the Original Benchmark」から続けてください。ガイドに記載されていない構成、フィールド名、ワークフローを作り出さないでください。

特に注意すべきポイント（いずれもチュートリアルに記載されていますが、アダプター構築で最もよくある失敗です。手順を進める際は、あらかじめ確認してください）：

• 生成されるすべての task.toml で、[task] の下に name フィールドを含める必要があります。 main.py は、各タスクに対してサニタイズ済みで、一意かつレジストリで使用可能な名前を決定する役割を担います。name のないタスクは登録できません。チュートリアルの「Naming rules」テーブルを参照してください。
• タスク名はアダプターの実行間で安定している必要があります。 不安定な名前を使うと、再公開時にレジストリのダイジェストが変わり続けます。アップストリームに安定した識別子がない場合は、再現可能なソートに基づき、決定論的な命名規則（例：{dataset}-1、{dataset}-2）を付けてください。
• task.toml の先頭で schema_version = "1.4" を使用してください。 パッケージのバージョンは、task.toml の [task].version と dataset.toml の [dataset].version で個別に設定します。希望するレジストリータグがあれば、PR の説明でリクエストしてください。
• main.py は --output-dir、--limit、--overwrite、--task-ids に対応する必要があります。 再現可能な実行とタスク単位のデバッグに、これらのフラグが必要です。
• 生成される README.md は、下流の自動化によって解析されます。 テンプレートの定義に従って、すべてのセクションを正確に記入してください。補足情報は Notes セクション、または parity_experiment.json／adapter_metadata.json の notes フィールドに記載してください。セクションの追加、名前の変更、並べ替え、削除はしないでください。
• 独断でパリティ実験を実施しないでください。 チュートリアルの Step 4 では、API の費用が発生する前に、エージェント、モデル、実行回数についてチームで調整する必要があります。まず健全性チェックを完了し、両側で対称的にフル実行を行ってください。

シナリオ別の参照アダプター

実装について疑問が生じたら、ベンチマークの形式に合った既存のアダプターを参照してください。

シナリオ	アダプターの例	使用する状況
互換性のあるエージェントがすでに存在する	adapters/adebench/	アップストリームがすでに Claude-Code／Codex／OpenHands／Gemini-CLI に対応している場合
アップストリームをフォークして LLM エージェントを追加する	adapters/evoeval/	Harbor 互換のエージェントがない LLM ベースのベンチマーク
カスタムエージェントと別個のデータセット	adapters/bixbench/、adapters/financeagent/	独自のインタラクション仕様が必要な場合。financeagent では LLM-as-a-Judge も紹介します
インプレースのカスタムエージェント	adapters/medagentbench/	別個のデータセットを使わない、カスタムの HTTPAgent
マルチエージェントのワークフロー	adapters/cooperbench/	複数のエージェントがメッセージング／サイドカーを介して連携する場合
GPU タスク	adapters/featurebench/	Docker と Modal を包括的に使った GPU の例

このスキルの対象外

• adapter.py、main.py、タスクテンプレートファイルの実装。これらは、チュートリアルのガイドに従ってコントリビューターが作成します。
• オラクル検証またはパリティ実験の実行。これらにはユーザーの明示的な意思が必要です。また、パリティ実験にはチームでの調整も必要です。
• データセットの公開または PR の作成。これらはチュートリアルの後の手順です。

失敗しやすいケース

症状	考えられる原因	対処方法
harbor: command not found	Harbor CLI がインストールされていない	uv tool install harbor またはリポジトリの開発環境セットアップでインストールしてください。
harbor adapter init が名前の検証エラーで失敗する	アダプター名に無効な文字が含まれている	小文字とハイフンのみを使った名前で再実行してください。
スキャフォールドの作成は成功するが、adapters/<name>/ が存在しない	リポジトリのルート以外から実行している	Harbor リポジトリのルートに cd して、再実行してください。
オラクルはローカルで成功するが、後からパリティ実験が理由なく失敗する	Harbor のチェックアウトが古い	git fetch origin && git status を実行し、遅れている場合は main をプルしてください。