3つの違うharnessで、スキルもMCPサーバーも別々に登録し直す面倒を消そうとするCLI

複数のAIコーディングharnessを併用していると、地味に面倒なのが「スキル」「MCPサーバー」「拡張機能」「コマンド」「フック」といった機能拡張を、harnessごとに違う置き場所・違う設定形式で登録し直す作業だ。個人開発者Predator404氏が公開しているOSS「aiToolManager」は、この面倒をひとつのCLI/TUIで横断しようとするプロジェクトだ。

3行まとめ

1. aiToolManagerは、OMP(oh-my-pi)・Claude Code・Prime Agentの3つのharnessにまたがって、スキル・MCPサーバー・拡張機能・コマンド・フックという5つのカテゴリを、共通のCLI/TUIから管理することを目指すツールだ。
2. 現在のバージョンは0.1.0で、package.jsonには"private": trueと明記されている。ディレクトリ内の.omp/・.claude/・.prime/agent/の有無からharnessと適用範囲(グローバル/プロジェクト)を自動判定する設計を仕様書(SPEC.md)に記している。
3. 「フック」画面はClaude Code専用とし、OMP・Prime Agentのフック相当の仕組みは内部的に「拡張機能」として扱う、といった、harnessごとの概念の違いを吸収する設計判断がSPEC.mdに明記されている。

harnessごとに違う「置き場所」を仕様書で1枚にまとめる

このツールの実質的な価値は、コード自体よりも、3つのharnessの内部仕様の違いを丁寧に洗い出したSPEC.mdにある。冒頭にこうある。

"CLI + TUI tool for managing AI coding-agent capabilities (skills, MCP servers, extensions, commands, hooks) across multiple harnesses, differentiating global (user) vs project scope." （「複数のharnessを横断して、AIコーディングエージェントの機能(スキル・MCPサーバー・拡張機能・コマンド・フック)を管理する、グローバル(ユーザー単位)とプロジェクト単位のスコープを区別するCLI+TUIツール」）

harnessの自動検出については、こう定義している。

"presence of .omp/ in cwd (or ancestors up to git root) -> omp, project scope / presence of .claude/ in cwd -> claude-code, project scope / presence of .prime/agent/ in cwd -> prime-agent, project scope" （「作業ディレクトリ(またはgitルートまでの祖先ディレクトリ)に.omp/が存在すればOMP・プロジェクトスコープ。.claude/が存在すればClaude Code・プロジェクトスコープ。.prime/agent/が存在すればPrime Agent・プロジェクトスコープ」）

環境変数OMP_PROFILE・PI_PROFILEはOMPの手がかりになる一方、Claude CodeとPrime Agentには信頼できる環境変数のシグナルが無く、ディレクトリの目印が主な判定材料になる、という制約も明記されている。判定できない場合は--harness・--scopeフラグでの明示指定を必須にする設計だ。

「フック」という概念自体がharnessによって存在しない

SPEC.mdの中で特に興味深いのが、harnessごとの機能概念の非対称性をどう吸収するかという判断だ。

"Hooks screen is Claude Code only (OMP/Prime Agent hook-style modules are mechanically Extensions internally — surface them there instead; do not build a redundant Hooks concept for those two)." （「フック画面はClaude Code専用とする(OMP/Prime Agentのフック相当のモジュールは、内部的には機械的にExtensionsとして扱われている。そちらで表示させ、この2つのharnessのために冗長なフック概念を新たに作らない)」）

つまり、Claude Codeにある「フック」という独立した機能カテゴリは、OMPやPrime Agentには存在せず、それらのharnessでは「拡張機能」という別の概念に吸収されている。この差異を無理にすべてのharnessに同じ5カテゴリを当てはめるのではなく、harnessごとの実態に合わせて画面の出し方を変える、という判断がされている。Claude Code向けの「拡張機能」画面についても「プラグインレベルのトグルとして再定義し、拡張機能レベルとは明確にラベルを分ける」という注記があり、harnessごとの用語の違いを一つずつ潰していこうとする作りが見える。

harnessごとに「置き場所」自体がまるで違う:スキルとMCPサーバーの実例

SPEC.mdが最も踏み込んで書いているのが、機能ごとにharness間で置き場所・仕様が食い違う実態そのものだ。スキル(SKILL.md)の置き場所だけでも、次のように4通りに分かれる。

この違いを吸収するためSPEC.mdが定めている方式は、~/.agents/skills/<name>/(グローバル)・<project>/.agents/skills/<name>/(プロジェクト)を「正典（canonical store）」として実体を1つだけ持ち、各harnessのネイティブディレクトリにはそこへのシンボリックリンクを張るという設計だ。OMP・Prime Agentは.agents/skillsをネイティブに読める(SPEC.mdの表現で言う「ベルト」)が、それでも各harnessのネイティブディレクトリにも同じ実体をミラーする(「サスペンダー」)理由として、「どちらかのharnessでagentsプロバイダのトグルを無効にした場合に、スキルが黙って消えるのを防ぐため」と明記されている。

MCPサーバーの設定ファイルは、スキーマ自体がharnessごとに異なるため正典方式が使えず、SPEC.mdは「シンボリックリンクは不可能。各harnessのネイティブファイルを、実行のたびにメモリ上で直接読み書きする」という別方式を定めている。

「フック」画面がClaude Code専用になる理由についても、SPEC.mdはさらに具体的な設計を記している。Claude Code側にはフックの無効化フィールドがネイティブに存在しないため、削除したマッチャーブロックを記憶しておく「シャドウコピー・サイドカー」を独自実装し、無効化→有効化を利用者がJSONを打ち直さずに往復できるようにする、という設計だ。

現状は「仕様が固まった」段階

package.jsonを確認すると、パッケージ名はai-tool-manager、バージョンは0.1.0、"private": true(npmに公開しない設定)となっている。依存関係は@clack/prompts^0.9.1(軽量なプロンプトライブラリ)・commander^13.1.0(CLIフレームワーク)・yaml^2.6.1・tsx^4.19.2の4つのみ、テストにはvitest^2.1.8を使う設計で、Node.jsの要求バージョンは>=18.20.0と、依存関係は最小限に抑えられている。SPEC.md自体も「grilled, all decisions settled(徹底的に検討し、すべての決定が確定した)」という書き出しから始まっている。この表現からは、まだ実装よりも設計フェーズに重心があることがうかがえる。GitHub APIで確認したところ、スター数は0・フォーク数は0・open issuesは0。リポジトリの作成日時とpush日時はいずれも2026年8月22日17:32(UTC)だが、GitHub APIのコミット一覧(4件)を確認すると、最初の3コミット「aiToolManager v1: core logic, CLI, TUI, tests (round 1)」「Round 3: fix all blocker/major bugs and opportunistic minors」「Fix N1 dangling-symlink mirror bug; wire MCP metadata write」はいずれも8月17日で、8月22日に積まれているのは最後の1コミット「Ignore local conversation-logs/」のみだった。この記事の執筆時点でその後の更新は確認できていない。GitHub APIのlicenseフィールドはnull(未設定)。

SPEC.mdの「決定」と、実装が仕様通り動くかは別の話

この記事を書くためにSPEC.md全体(約14KB)を読んだが、機能一覧よりも「どのharnessにどの概念が無いか」を場合分けして書いている分量の方が多く、割り切りの付け方に開発者自身の使用経験が透けて見えた。GitHubのcontents APIを確認したところ、リポジトリにはbin/・src/・tests/ディレクトリが存在するため、コード自体は書き始められている。だが、この記事はSPEC.md・package.json・GitHub APIのメタデータという設計文書・設定ファイル・リポジトリ統計のみを根拠にしており、実際にnpmでインストールしてOMP・Claude Code・Prime Agentの3つに対して動かし、harnessの自動判定やスキル管理が仕様通りに動くかを検証したわけではない。SPEC.md自身が「決定は確定した」と書いているのはあくまで設計判断の話であり、実装がその設計通りに動いているかどうかは別の話だ。src/・tests/ディレクトリの中身(実装コード・テストケースの具体的な内容)までは開いて確認していない。

同じくPrime Agentを対象にした周辺プロジェクトについては別記事で扱っている。

関連記事

• PrimeAgentの『RLM』という発想が、2週間で3つの独立した移植版を生んだ
• Claude Codeとは──コード生成に留まらない「仕事を渡せる」AIエージェント