Orchestkit Docs MCP

115 個のスキル · 36 個のエージェント · 161 個のフック

まずはこちら

OrchestKit は無料のオープンソース Claude Code プラグインです。レビュー、テスト、セキュリティ、メモリ管理のためのスキル、エージェント、フックを提供します。

claude plugin marketplace add yonatangross/orchestkit && claude plugin install ork@orchestkit

ドキュメント · v10 の新機能 · yonyon.ai

ドキュメントを見る → · OrchestKit コミュニティ →
_{スキルブラウザー、デモギャラリー、セットアップウィザード}

目次

• クイックスタート
• OrchestKit を選ぶ理由
• 利用できるもの
• 主なコマンド
• 設定
• OrchestKit が観測する内容
• インストール
• FAQ
• 開発
• 新着情報
• コミュニティ

クイックスタート

実際に使っているホストを選んでください。Claude Code は完全なプラグイン（スキル＋エージェント＋フック）です。Cursor では、Claude のフックスクリプトを除いた同じ ork プラグインを利用できます。skills.sh はスキルのみです。カタログ全体ではなく、まずは以下の 12 個から始めましょう。

ホストの対応状況

2026-09-08 に pi 0.85、Codex CLI、cursor-agent で測定しました。詳細、コマンド、レーンモデルについては、pi、Codex、Cursor での OrchestKit をご覧ください。Antigravity は 2026-09-18 に agy 1.2.6 で測定しました。証拠の全容は docs/audits/agy-host-support-2026-09-18.md にあります。

Claude Code

/plugin marketplace add yonatangross/orchestkit
/plugin install ork

次に /ork:setup を実行します。ウィザードがリポジトリをスキャンし、スキルを推奨して、MCP 設定を書き込みます。

CLI で同じ操作を行う場合：claude plugin marketplace add yonatangross/orchestkit && claude plugin install ork@orchestkit。

Cursor

Settings → Plugins / marketplaces → yonatangross/orchestkit を追加 → ork を有効化 → 新しいチャットを開く。これは Claude Code がインストールするものと同じプラグインであり、5 つのスキルに分割されたものではありません。インストール → Cursor を参照してください。

skills.sh（Cursor、Codex、OpenCode、…）

実際のインストール状況に基づくスターター 12 件と、保持している ork スキルです（理由の全一覧は インストール を参照してください）：

npx skills add yonatangross/orchestkit -s devops-deployment -s responsive-patterns -s architecture-decision-record -s ui-components -s rag-retrieval -s agent-orchestration -s brainstorm -s expect -s auto -s review-pr -s fix-issue -s commit

全カタログ：npx skills add yonatangross/orchestkit（数百件の SKILL.md ファイルがありますが、これをユニークユーザー数として扱わないでください）。実際のインストール総数は、上の skills.sh バッジで確認できます。

OrchestKit を選ぶ理由

Claude Code のセッションは毎回、ゼロから始まります。使用するスタック、パターン、好みを何度も説明しなければなりません。

OrchestKit を使うと、Claude は本番環境で有効なパターンについての永続的な知識を自動的に得られます：

利用できる機能

すべてを含む、統合プラグインが 1 つあります。

すべて /plugin install ork から利用できます。スキルは必要に応じて読み込まれます。フックは自動的に動作します。

ドキュメントですべてを見る →

主なコマンド

/ork:auto         # Front door: describe a goal, it routes to the right skill
/ork:setup        # Personalized onboarding wizard
/ork:implement    # Full-stack implementation with parallel agents
/ork:expect       # Diff-aware AI browser testing
/ork:review-pr    # PR review with parallel agents
/ork:verify       # Multi-agent validation
/ork:commit       # Conventional commit with pre-checks
/ork:explore      # Analyze unfamiliar codebase
/ork:remember     # Save to persistent memory
/ork:doctor       # Health check

設定

/ork:setup がスタックを検出し、MCP サーバーを推奨して、設定を書き込みます。

推奨 MCP サーバー

最初の 3 つには、.mcp.json で "alwaysLoad": true を設定してください。スキルごとのツール確認を省略し、コールドスタートを約 150ms 短縮します。

Context7 は前提条件ですが、ork には同梱されていません。 22 個のエージェントがフロントマターで mcp__context7__* を利用しますが、.mcp.json はユーザーが管理するプロジェクト単位の設定なので、 この指定が参照するのは、ユーザーが追加するサーバーです。追加しない場合、該当するエージェントはエラーを出さずに、学習データに基づいて回答します。推奨されるのはホスト型 HTTP サーバーで、ローカルプロセスを起動する必要はありません：

"context7": {
  "type": "http",
  "url": "https://mcp.context7.com/mcp"
}

無料枠は 1,000 件のリクエストに対応し、パブリックリポジトリを利用でき、アカウントは不要です。Context7 Pro（1 シートあたり月額 $10）では、1 シートあたり 5,000 件まで利用でき、プライベートリポジトリも解析されます。"headers": { "Authorization": "Bearer ${CONTEXT7_API_KEY}" } を追加し、ctx7sk- キーを環境変数としてエクスポートしてください。ヘッダーを追加するのは、変数をエクスポートしてからにしてください。変数が未設定の場合、展開されていない文字列がトークンとして送信され、すべてのクエリが失敗します。また、匿名の無料枠にもフォールバックしないため、キーを設定しないヘッダー付き設定より、上記のキー不要の設定の方が確実に優れています。レガシーな stdio トランスポート（npx -y @upstash/[email protected]）は、ホスト型エンドポイントに到達できない場合の代替手段ですが、Claude Code のセッションごとに子プロセスを 1 つ起動するため、開いているセッション数に比例してプロセス数が増えます。

スキルのカスタマイズ

スキルはディスク上のファイルとしてインストールされますが、インストール済みのコピーを直接編集しないでください。更新時に上書きされ、正式なプレイブックからいつの間にか乖離してしまいます。拡張する方法（ユーザーレベルのスキル、プロジェクトのスキル、上流への PR、またはバンドルされたスキルの無効化）については、docs/extending-skills.mdをご覧ください。

OrchestKit が監視するもの

OrchestKit は品質ゲートプラグインであり、フックはアドオンではなく製品そのものです。このセクションでは、フックが何を確認し、データがどこに送られ、各項目をどう無効にするかを明確に説明します。

適用範囲：広範かつ意図的です。 OrchestKit は、SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、Stop を含む、32 のライフサイクルイベントにわたって 161 個のフックを登録します。特定のフレームワークやプロジェクト種別に限定されていません。これは、適用するゲート（シークレットの書き込みブロック、保護対象ファイルのガード、Git の安全対策、ファイルサイズ制限、エージェントのステータスプロトコル）が、どのコードベースにも当てはまるためです。一部のプロジェクトだけでゲートを使いたい場合は、プラグインをグローバルではなくプロジェクトごとに有効にしてください。

データの保存先：ご自身のディスク上のローカルファイルです。

ローカルへの書き込みには、意図的にグローバルなキルスイッチを設けていません。ゲートがこの状態に依存しているためです（Git の安全対策とチェーンの陳腐化を検出するフックは、過去のイベントを読み取ります）。完全に停止するには、プラグインを無効にしてください。個別の、通知が多いフックには、それぞれ無効化オプションがあります。ORK_DISABLE_DEBT_TRACKER、ORK_DISABLE_WORKTREE_VERIFIER、ORK_DISABLE_COORDINATION_METRICS、ORK_NO_NOTIFY、ORK_NO_STALE_SWEEP、ORCHESTKIT_SKIP_SLOW_HOOKS などです。

ネットワークアクセスはオプトイン方式で、デフォルトでは無効です。 出荷されるフックバンドルのどこにも、ハードコードされたリモートホストはありません（grep -o 'https\?://' plugins/ork/hooks/dist/*.mjs は何も返しません）。次のいずれかの方法で自分で宛先を設定した場合にのみ、外部への呼び出しが発生します。

• ORCHESTKIT_HOOK_URL と ORCHESTKIT_HOOK_TOKEN。これにより、手動で実行する hooks/bin/telemetry-sync.mjs CLI が有効になります。ローカルの JSONL をご自身の エンドポイントに POST します。フックから呼び出されることはありません。手動で実行してください。
• ORK_HQ_TELEMETRY_URL。テレメトリー HTTP シンクをご自身のコレクターに向けます。
• ORK_HQ_TELEMETRY_USE_HQ_API=1 と HQ_API_URL の組み合わせ。同じシンクを セルフホスト可能な HQ API に向けます。
• セッションの作業カテゴリを分類する2つ目の分類器として使う、ORK_SESSION_CATEGORY_PROVIDER=jev（または shadow）と TypeSafe キー変数 ORK_TYPESAFE_API_KEY の組み合わせ。セッション識別フックはすでに、タイトルとカテゴリを取得するためにローカルの claude -p --model haiku プロセスに問い合わせています。両方の変数を設定すると、同じ8つのカテゴリと同じ基準テキストを使い、TypeSafe の Jev モデル（api.typesafe.ai、モデルは jev-1.13.0 に固定）にも型付きの Choice を1つ問い合わせます。これは上記の「ハードコードされたホストはない」という注記の唯一の例外であり、両方の変数が設定されていない限り休止状態です。マシンから送信される情報：git ブランチ名と、セッションの最初のプロンプトの先頭600文字。これらは、独自のデータポリシーを適用するサードパーティの処理サービスに送信されます。jev モードでの変更点：Jev が信頼度0.8以上で回答した場合、Jev のカテゴリによってセッションの色が決まります（150セッションでの保留評価では、この範囲の正解率は93.5%でした）。0.8未満の場合、またはエラーが発生した場合は、従来どおり haiku のカテゴリで決まります。タイトルと絵文字は常に haiku が決めます。shadow モードでは、表示上の変更はありません。Jev の結果は haiku の結果と並べてログに記録されるだけです。ローカルで有効にするには、claude を起動するシェルで次を実行します：export ORK_TYPESAFE_API_KEY="$(<your secret manager> ...)" と export ORK_SESSION_CATEGORY_PROVIDER=jev。フックログには、セッションごとに両方の結果が1回記録されます。形式は category jev: haiku=<cat> jev=<cat> agree=<bool> confidence=<n> decided_by=jev|haiku threshold=0.8 latency_ms=<n> で、 セッションデータディレクトリ内には、同じフィールド（ラベル、判定、所要時間。プロンプトテキストは含まれません）を記録した session-identity.shadow.json が、生の回答を記録した session-identity.jev.json の隣に保存されます。有効化する場合のコスト：セッションの最初のプロンプトは呼び出しが完了するまで待機します。新しいフックプロセスでの計測値は1.1～1.7秒です（評価時の320ミリ秒は接続がウォーム状態での値です）。諦めるまでの上限は3秒です。
• /ork:auto 用の Jev ルーティング接続部分として、ORK_ROUTE_JEV=shadow（または steer）と ORK_TYPESAFE_API_KEY を組み合わせて使います（#4233）。デフォルトでは無効です。設定すると、ビルド関連のプロンプトすべて（セッションごとに1回実行されるエグゼキューターへのリマインダーで使われるものと同じテスト、すなわち命令形のビルドまたは修正を表す動詞を含み、40文字以上で、明示的な /plugin:skill がないプロンプト）が、19個のルートクラスと4つの補助判定（worktree が必要か、ブラウザーが必要か、変更リスクがあるか、オペレーターが必要か）を含む型付きの Choice として、同じ TypeSafe エンドポイントとモデルに送信されます。マシンから送信される情報：秘匿情報、メールアドレス、イスラエルの電話番号、9桁の ID、op:// 参照、clients/ 配下のディレクトリ名をリダクターでそれぞれ [SECRET]、[EMAIL]、[PHONE]、[CLIENT] に置き換えた後のプロンプトの先頭1,500文字と、リポジトリのベース名です。シリアライズされたリクエストは送信前に再度スキャンされ、秘匿化をすり抜けたものがあれば呼び出しは拒否されます。shadow モードでは、表示上の変更はありません。判定はログに記録されます。steer モードでは、信頼度が ORK_ROUTE_JEV_FLOOR（デフォルトは0.5）以上の場合、1行のエグゼキューターへのリマインダーに、そのクラスに対応するエグゼキューターが表示されます（route: dev_fix -> /ork:fix-issue (conf 0.83)）。モデルは引き続き /ork:auto のテーブルを参照し、提案に同意するかどうかを示します。フォールバックはフェイルオープンです。キーがない、タイムアウト、2xx 以外のステータスコード、不正な回答、信頼度がしきい値未満、または1日のトークン上限（ORK_ROUTE_JEV_DAILY_TOKENS、デフォルトは2,000,000）に達した場合は、いずれも既存の処理がそのまま実行されます。402 または 429 が発生すると、この接続部分は24時間無効になります。プロンプトごとに次のログ行が1つ記録されます： route jev: intent=<class> conf=<n> top3=<a:p,b:p,c:p> worktree=<n> browser=<n> mutation=<n> operator=<n> floor=<n> decided_by=jev|table|off|budget|egress latency_ms=<n> input_tokens=<n> redacted=<n>。 また、プロンプトごとに1つのレコードが session-identity.jev.json の隣にある jev-route.jsonl に記録されます（ラベル、所要時間、秘匿化されたテキストの sha256。プロンプトテキストは含まれません）。オフラインでの再生：node scripts/eval/route-check.mjs --jev および node scripts/eval/jev-route-score.mjs。ベンダーのエージェントスキルは、独自のマーケットプレイスからインストールするピアプラグインです。コピーしたディレクトリではありません： claude plugin marketplace add typesafe-ai/skills の後に claude plugin install typesafe@typesafe-ai を実行します。/ork:doctor はインストール済みのバージョンとマーケットプレイスのバージョンを照合し、更新コマンドを表示します。 URL またはトークンが設定されていない場合、シンクは早期に終了し、 telemetry-sync.mjs は No ORCHESTKIT_HOOK_URL or TOKEN configured. Nothing to sync. を出力して、終了コード 0 で終了します。アナリティクスの送信も、 クラッシュレポーターも、機能フラグの取得もありません。

OrchestKit が決して読み取らないもの。 OS のキーチェーン検索、~/.aws/credentials、 SSH 秘密鍵、ブラウザーの Cookie やログイン情報ストア、クリップボードにはアクセスしません。 ソース内で秘密情報らしいパスが登場する箇所は、 plugins/ork/hooks/dist/pretool.mjs のみです。ここでは id_rsa、.pem、.env、 credentials.json が、Claude による書き込みを防ぐブロックリストを構成しています。 このコードはアクセスを拒否するものであり、これらのファイルを読み取るものではありません。

サードパーティの MCP サーバーは推奨であり、同梱の依存関係ではありません。 このプラグインには .mcp.json は含まれず、mcpServers も宣言されていません。 Configuration の下にある表は参考情報であり、/ork:setup は何かを書き込む前に確認を求めます。

インストール

/plugin install ork

ティア分けはありません。バージョンの混乱もありません。強力なプラグインが一つあるだけです。

Claude Code を使っていませんか？ skills.sh 経由で、 あらゆるエージェント（Cursor、Codex、OpenCode、…）にスターター 12 個を追加できます。 初日から大量のスキルをすべてインストールする必要はありません。以下は、当社の一覧における skills.sh のインストール実績と、実際に使い続けている ork スキルから選んだものです。

npx skills add yonatangross/orchestkit -s devops-deployment -s responsive-patterns -s architecture-decision-record -s ui-components -s rag-retrieval -s agent-orchestration -s brainstorm -s expect -s auto -s review-pr -s fix-issue -s commit

すべてのスキル：npx skills add yonatangross/orchestkit。最新のインストール総数は ここに固定値で記載するのではなく、上記の skills.sh バッジ で確認できます。

Cursor

Cursor は Agent Plugins と Cursor プラグインを読み込みます。 このリポジトリには、Agent Plugins のマニフェストがすでに plugins/ork/plugin.json に含まれています。 GitHub リポジトリを Cursor のマーケットプレイスとして追加し（Settings → yonatangross/orchestkit）、 ork を有効にしてから、新しいチャットを開いてください。これは Claude Code がインストールするものと同じプラグインであり、 5 つのスキルだけを含む派生版ではありません。

プラグインの rules キーには、src/rules/ と src/shared/rules/ から生成された 14 個のルールも含まれています。これらはエージェントが取得するため、説明がタスクに一致した場合にのみ コンテキストを消費します。

Claude のフックスクリプトは Cursor には登録されません。${CLAUDE_PLUGIN_ROOT} に依存しているためです （orchestkit#293、クローズ済み）。HQ リポジトリでの Cursor による適用は、利用側プロジェクトの .cursor/hooks.json で行います。

「Include third-party Plugins」を有効にすると、~/.claude/plugins の SKILL.md が漏れる可能性があります。 これはインストールではありません。証明となるのは、ork プラグイン ID とスキルカタログ全体です。

Codex

Codex は独自のプラグイン形式、スキルピッカー、スタンドアロンのロール設定を使用します。 OrchestKit の Codex マーケットプレイスを追加し、小規模で移植性の高いワークフローパックをインストールしてください。

codex plugin marketplace add yonatangross/orchestkit --ref main --sparse .agents/plugins --sparse plugins/ork-codex
codex plugin add ork-codex@orchestkit-codex

インストール後、Codex を再起動してください。$ork-brainstorm、$ork-explore、$ork-implement、 $ork-assess、$ork-verify、または $ork-review-pr を明示的に呼び出してワークフローを実行できます。 説明が簡潔なため、Codex が関連するワークフローを自動的に選択することもできます。

Codex はプラグインマニフェストではなく ~/.codex/agents/ からカスタムロールを読み込むため、 プラグインではロールをテンプレートとして提供しています。OrchestKit のチェックアウトから、 一度だけ実行する上書きなしのインストールを行ってください。

plugins/ork-codex/scripts/install-codex-roles.sh ~/.codex/agents

これにより ork_explorer、ork_implementer、ork_reviewer、ork_verifier がインストールされます。 これらを起動する前に Codex を再起動してください。

無人実行：ork-mech プロファイル

機械的な作業（名前変更、バージョン更新、codemod、差分で終わる一括処理）では、同梱のプロファイルをインストールし、それに対して codex exec を実行します。

plugins/ork-codex/scripts/install-codex-profile.sh ~/.codex
codex exec --profile ork-mech "<task>" </dev/null

このプロファイルは、config.toml に貼り付けるスニペットではなく、ファイルです。codex-cli 0.153.4 で測定したところ、--profile <name> は $CODEX_HOME/<name>.config.toml をベース設定に重ねて適用します。また、config.toml 内に残された従来の [profiles.<name>] テーブルがあると、同じフラグで設定読み込みエラーが発生します。インストーラーは、そのテーブルがある状態での実行を拒否し、既存のプロファイルも上書きしません。

codex exec がヘッダーに表示する設定は次のとおりです。

approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR] (network access enabled)
reasoning effort: high

意図的にモデルは固定していません（-m を渡してください）。また、サンドボックスを完全に無効にする --dangerously-bypass-approvals-and-sandbox も使用しません。TOML ファイルでは表現できない次の2つの契約があるため、これらはコマンドラインで指定します。

• </dev/null。 プロンプト引数を指定しても、codex exec は標準入力を読み取ります。継承された開いたパイプがあると、タイムアウトもなく Reading additional input from stdin... と表示されたまま実行が停止します。

• Git ワークツリー内での --add-dir。 書き込み可能なルートは [workdir, /tmp, $TMPDIR] です。リンクされたワークツリーの Git 共通ディレクトリは作業ディレクトリの外にあるため、最初のコミットは index.lock で失敗します。次のように追加してください。

  codex exec --profile ork-mech \
    --add-dir "$(git rev-parse --path-format=absolute --git-common-dir)" \
    "<task>" </dev/null
  

インストールを最新の状態に保つ

マーケットプレースのソースにある ref main はキャッシュされたスナップショットであり、追跡対象ではありません。2026-09-08 の監査マシンでは、main が3リリース先行している一方で、codex plugin list は 10.0.0-beta.5 を表示していました。OrchestKit のリリース後に更新して確認します。

codex plugin update
codex plugin list | grep ork-codex          # installed version
jq -r .version plugins/ork-codex/.codex-plugin/plugin.json   # what main ships

ドキュメント検索（context7）

このプラグインは独自のマニフェスト（.codex-plugin/plugin.json 内の mcpServers、mcp.json で定義）に context7 MCP サーバーを同梱しているため、プラグインをインストールすると登録されます。codex mcp get context7 で確認してください。context7 が公開する2つのツール、resolve-library-id と query-docs のみが対象で、npx の stdio 子プロセスではなく、ホスト型の HTTP トランスポートを使用するため、Codex のセッションごとに追加のプロセスが起動することはありません。

Codex を起動する前にキーをエクスポートしてください。プラグインは変数名を参照するだけで、値を保存しないため、トークンが ~/.codex/config.toml に書き込まれることはありません。

export CONTEXT7_API_KEY_CODEX="<your-context7-api-key>"

Codex のすべてのセッションに継承されるよう、これをシェルプロファイルに記述してください。キーは自分の context7 アカウントから取得し、値をリポジトリに含めないでください。シークレットマネージャーに保存する場合は、独自の保管庫名とアイテム名に置き換えてください（1Password CLI の場合、参照先は op://<vault>/<item>/credential です）。また、シェルを起動するたびに保管庫を読み直すのではなく、解決した値をキャッシュしてください。生の値を読み取るたびに、別途ロック解除プロンプトが表示されます。

知っておくべき動作は次の2つです。

• ~/.codex/config.toml の [mcp_servers.context7] で独自に定義したサーバーがある場合は、そちらが優先され、プラグインの定義はツールのスコープ設定も含めて完全に無視されます。これは意図した動作です。独自の設定が上書きされることはありません。プラグインの定義を使うには、独自のエントリーを削除してください。
• 有効なキーがなくても、サーバーへの接続とツール一覧の取得は行われます。実際に呼び出した場合にのみ Invalid API key で失敗します。そのため、接続に成功しても認証が成功した証拠にはなりません。

pi

pi（0.85）は同じ SKILL.md 形式を読み込み、リポジトリに pi マニフェストが追加されたため、パッケージを直接インストールできます。

pi install git:github.com/yonatangross/orchestkit

これにより、すべてのスキルが登録されます。-l を追加すると、ユーザー設定ではなくプロジェクト内の .pi/settings.json に書き込みます。チェックアウトを pi に指定する方法も引き続き使え、インストールは不要です（pi --skill ./plugins/ork/skills）。

disable-model-invocation とマークされた 29 個のスキルは、引き続き /skill:<name> としてのみ利用できます。実測で確認された注意点が 2 つあります。--no-builtin-tools を指定するとすべてのスキルが非表示になります（pi がスキルを一覧表示するのは、ファイル読み取りツールが有効な場合のみです）。また、開いたままの stdin があると pi -p は処理を待ち続けるため、ヘッドレス実行では </dev/null が必要です。

pi の MCP サーバーは、.pi/mcp.json、.mcp.json、~/.config/mcp/mcp.json の順に読み込まれます。配布されているテンプレートをコピーすると、サーバーごとに読み取り専用の includeTools 許可リストが設定された推奨サーバーを利用できます。

cp .pi/mcp.json.example .pi/mcp.json

詳細と進捗を追跡するエピック： OrchestKit on pi, Codex and Cursor。

Devin

devin plugins install yonatangross/orchestkit

Devin はプラグインのルートで、次の順にマニフェストを確認します：.devin-plugin/plugin.json、 次に .claude-plugin/plugin.json、最後にルートの plugin.json （プラグインのリファレンス）。 リポジトリのルートにあったのは最後のものだけで、Agent Plugins のマニフェストはスキルをルートの skills/ ディレクトリに固定しますが、このリポジトリにはそのディレクトリがありません。 そのため、以前は何も指定せずにインストールすると、107 個のスキルのうち 0 個、フック 0 個、そして AGENTS.md ルールだけが表示されていました（GH-4146）。ルートレベルの .devin-plugin/plugin.json で skills を ./plugins/ork/skills にマッピングするようになりました。これは、Claude Code と Cursor がすでに読み込んでいるものと同じビルド済みツリーです。

この変更後、devin plugins info ork では107個中76個のスキルが表示されます（Devin CLI 3000.10.27 で計測）。 残りの31個、つまり auto、verify、help、brainstorm などのルーターまたはワークフロースキルは、 オブジェクト形式（keywords、examples、anti-triggers）のフロントマターキー triggers: を宣言しています。 Devin 独自の triggers フィールドが想定するのは、フラットな [user, model] リストです。形式が一致しないため、警告が出るのではなくスキル全体が読み込まれません。このキーの名前を変更すると、ほかの3つの読み込み処理（scripts/eval/eval-coverage.sh、tests/skills/triggering/test-trigger-keywords.sh、 および tests/plugins/test-command-frontmatter-passthrough.sh 内の SKILL_ONLY 許可リスト）に影響するため、この修正に含めず GH-4146 で引き続き追跡します。サブパスを直接指定して devin plugins install yonatangross/orchestkit#plugins/ork とインストールすると、同じ76個のスキルに加え、このプラグインの36個のカスタムサブエージェントもインストールされますが、どちらの方法でも devin plugins info には表示されません。このサブパスは、このリポジトリ独自の .claude-plugin/marketplace.json ですでに Claude Code の参照先として指定されています。

OrchestKit のプラグインフックは、現時点では Claude Code でのみ動作し、171個のフックはいずれも Devin では実行されません。理由は2つあります。配置：OrchestKit はフックを plugins/ork/hooks/hooks.json に配置しますが、Devin 独自のプラグイン形式では、プラグインのルートにある単体の hooks.json を読み込みます。形式とツール名：OrchestKit のファイルは Bash や Write|Edit などの Claude Code のツール名に対応し、コマンド引数内の ${CLAUDE_PLUGIN_ROOT} を展開します。どちらも Claude Code 固有の仕様です。Devin 独自の hooks.v1.json 形式では、代わりに exec、write、edit など、Devin 独自のツール名に対応します（ライフサイクルフックを参照）。その際、同じ {matcher, hooks:[{type, command}]} 形式のイベントマップを使用します。スキルが解決された後も、devin plugins info には Hooks (none) と表示されることが確認できます。PreToolUse と PostToolUse は、OrchestKit 独自の pretool フックと posttool フックが行う処理に最も近いため、ツール名の対応関係を推測ではなく意図的に記述したうえで、将来 Devin 用のフックマニフェストを作成する際の最初の候補です。

main を追跡するのではなく、リリースを固定してください。release-please は各リリースに v10.0.0-beta.N というタグを付けます。単一の引数 <source> を取る devin plugins install <source> コマンド自体には、参照先を固定する構文がありません。代わりに、requiredPlugins エントリー（このリポジトリ独自の .devin/config.json、または個人、組織、企業向けのマニフェスト）で固定してください：

{
  "requiredPlugins": [
    { "source": "github", "repo": "yonatangross/orchestkit", "ref": "v10.0.0-beta.30" }
  ]
}

Antigravity

npx skills add yonatangross/orchestkit -s devops-deployment -s responsive-patterns -s architecture-decision-record -s ui-components -s rag-retrieval -s agent-orchestration -s brainstorm -s expect -s auto -s review-pr -s fix-issue -s commit

Antigravity（agy、Google のエージェント型 CLI）は、ワークスペースの .agents/skills ディレクトリから Agent Skills を読み込むため、上記の共通 skills.sh の行がインストール先となり、Antigravity はすでにインストーラーの共通ターゲット一覧に含まれています （agy 1.2.6 で計測。詳しい根拠は docs/audits/agy-host-support-2026-09-18.md を参照）。リポジトリのルートから agy -p "/skills" --add-dir "$PWD" を実行して確認してください。print モードでは、絶対パスを指定した --add-dir でのみワークスペースが登録されます。一方、対話型 TUI では起動ディレクトリがワークスペースとして扱われるため、フラグは不要です。

正直なところ、2 つの不足があります。npx skills add -g のインストール先は ~/.agents/skills ですが、agy はここを読み込みません。ユーザースコープのインストール先は ~/.gemini/config/skills（または ~/.gemini/skills）です。また、ork の 171 個のフックはいずれも移植されません。agy の hooks.json は独自のイベント名とペイロード形式を使用しており、ork ではフックを hooks/hooks.json に置いているため、agy が参照するプラグインルートの hooks.json には見つかりません。agy plugin validate plugins/ork を実行すると、フックがスキップされたと報告されます。

より包括的なインストール方法もありますが、ローカルのチェックアウトが必要です。 agy plugin validate <checkout>/plugins/ork では、skills: 108 processed および agents: 36 processed と報告されます。また、agy plugin install <checkout>/plugins/ork を実行すると、それらが ~/.gemini/config/plugins/ork/ に ork:<name> の名前空間付きでコピーされます。これは /ork:<skill> という表記と一致します。プラグインにバンドルされた mcp_config.json も動作します（マーカーでエンドツーエンドの動作を確認済み）が、リポジトリレベルの .mcp.json は読み込まれません。

FAQ

/plugin list
/plugin uninstall ork && /plugin install ork

開発

npm run build      # Build plugins from src/
npm test           # Run all tests

src/ と manifests/ を編集し、生成物である plugins/ は編集しないでください。

詳しくは CONTRIBUTING.md を参照してください。

新着情報

v10.3.1 · 2026-10-26

• deps-dev: @biomejs/biome を更新（#4916）
• deps: npm-minor-patch グループを更新（#4920）
• deps: /docs/site の npm-minor-patch グループを更新（6 件）（#4917）
• deps: 1 ディレクトリにわたる remotion グループを更新（21 件）（#4919）
• traffic: 2026-10-19 の週のスナップショット（#4927）
• …ほか 1 件（CHANGELOG.md を参照）

v10.3.0 · 2026-10-26

• skills: ファイル内レビューを含む計画・調査アーティファクトのペア（#4897）
• ci: ワークフロー PR を無効化した状態で開く（#4930）
• plugin: フックの対象範囲を明示する平易な説明（#4759）
• tests: docs.yml の同等性テストで /dev/fd ではなく一時ファイルを比較（#4933）
• skills: json-render スキルを 0.21.3 に更新（#4929）

v10.2.2 · 2026-10-26

• hooks: プロンプトフックのプロセスを統合（#4909）
• hooks: --restricted のもとで制限のない claude を起動しないように修正（#4906）
• site: orank のサンドボックス、カード、見つけやすさに関する不足を解消（#4908）

v10.2.1 · 2026-10-25

• coderabbit: 無料の OSS レビューを慎重に利用し、組織の設定に合わせる（#4886）

v10.2.0 · 2026-10-25

• prompt-enhancer: スタックを考慮した短い書き換えと、プロンプトキャッシュ済みカタログ（#4857）
• secrets-veil: スキャン時のスケーリング上限を 31.6 倍に拡大（#4898）

v10.1.1 · 2026-10-24

• deps: 4 つのロックファイルで npm audit の勧告に対処（#4894）

v10.1.0 · 2026-10-23

• ci: ボットのレビューコメントに返信がない場合、PR を失敗させる（#4864）
• ci: docs の依存関係ステップで apt が dpkg ロックを待つようにする（#4879）
• hooks: advisor が説明を決定し、否定形の依頼を無視する（#4853）
• hooks: 自動承認フックと再試行フックを強化（#4858）
• hooks: 次の節が参照する停止条件を維持（#4853 の対応後）（#4880）
• …ほか 6 件（CHANGELOG.md を参照）

v10.0.2 · 2026-10-23

• release: release-please のコミットから .claude-plugin を除外（#4870）

全リリース履歴については CHANGELOG.md をご覧ください。

コミュニティ

AI 開発のヒント、OrchestKit のサポート、ほかのビルダーとの交流のために、Building with AI コミュニティに参加しましょう。

名称と対象者は yonyon.ai の表示内容と一致しているため、両方の掲載内容に食い違いが生じません。すべてのリンクは yonyon.ai/go/* を経由するため、招待リンクが変更されても README を更新する必要はなく、生の招待リンクがここに公開されることもありません。

誰が開発しているのか

OrchestKit は、AI コンサルティング事業の Yonyon AI を運営する Yonatan Gross が開発・保守しています。実際のクライアント業務から生まれたツールキットであり、サイドプロジェクトではありません。ここにあるパターンは、実際に提供して成果を上げてきたものです。

MIT ライセンスのもと、無料で利用できます。利用が制限されている機能はなく、以下の内容によって変わることもありません。

自社の業務に AI をどう活用できるか検討中ですか？ AI readiness audit は、ワークフローを分析し、優先順位を付けたレポートを返す無料の評価サービスです。コンサルティング契約の開始時に実施する診断と同じものです。

チームでツールキットを適切に使えるようにしたいですか？ セットアップ、設定、そしてチームの技術スタックに合わせた実用的なエージェントループの構築を、範囲を定めた契約で承っています。ディスカッションを開始するか、コミュニティからお問い合わせください。

セキュリティポリシーと報告については、SECURITY.mdをご覧ください。