run

run skill の概要

run skill でできること

run は、Claude 向けの AgentHub オーケストレーション skill で、/hub:run コマンドを提供します。1 回のリクエストで、タスクの初期化、ベースラインの取得、複数エージェントの起動、出力の評価、勝者の結果のマージまで、コンペ形式の一連のライフサイクルを実行します。1 つの直接回答を求めるのではなく、複数の解決案をエージェントに競わせて比較したいときに使う run skill です。

AgentHub ユーザーに向いているケース

run skill は、すでに AgentHub のコマンドパターンを使っていて、マルチエージェント実行のための高レベルな入口を 1 つにまとめたいチームに適しています。パフォーマンス最適化、リファクタリング、テスト生成、バグ修正、測定可能なコード改善といったエンジニアリングタスクに向いています。また、judge mode を使えば、複数候補の中から最適なマーケティングコピーを選ぶような、コード以外のクリエイティブ選定にも対応できます。

インストール前の主な判断ポイント

/hub:init、ベースライン取得、エージェント起動、評価、マージを手動で呼び出すことなく、AgentHub のライフサイクルをつなげる再現可能なコマンドが欲しい場合は、run をインストールする価値があります。一方で、汎用的な自動化ランナーとして扱うべきではありません。価値を発揮するには、評価または判定が可能なタスクであることに加え、関連コマンドを利用できる AgentHub 環境が必要です。

主な差別化ポイント

Claude に「いくつかの方法を試して」と頼む通常のプロンプトとは異なり、/hub:run は、task、agents 数、任意の eval command、metric、最適化方向、template といった明示的なパラメータを持つ構造化されたライフサイクルをエージェントに与えます。この構造により、結果の比較、監査、マージがしやすくなります。

run skill の使い方

run のインストールとリポジトリ確認

skill manager を使って、たとえば次のようにリポジトリから skill をインストールします。

npx skills add alirezarezvani/claude-skills --skill run

そのうえで、まず upstream のファイルを確認してください。

engineering/agenthub/skills/run/SKILL.md

このリポジトリパスには、中核となる動作と例が含まれています。提供されているツリー上では、この skill 用の関連 scripts/、resources/、references/、rules/ フォルダは確認できません。そのため導入の成否は、主に SKILL.md にあるコマンド契約を理解していることと、より広い AgentHub コマンドセットを利用できる環境があることに依存します。

基本的な run の利用パターン

コマンド形式は次のとおりです。

/hub:run --task "..." --agents 3 --eval "..." --metric metric_name --direction lower --template optimizer

重要なパラメータは次のとおりです。

• --task: 必須。エージェントが競うべき具体的な作業内容。
• --agents: 任意。ソース例ではデフォルトが 3。
• --eval: 任意。結果を測定するために使うコマンド。
• --metric: --eval を使う場合は必須。比較対象となる値。
• --direction: metric を比較する場合は必須。lower または higher を指定します。
• --template: 任意。例として optimizer、refactorer、test-writer、bug-fixer があります。
• --judge: 決定的な metric がなく、LLM judge に出力を比較させたい場合に便利です。

あいまいな目標を強いコマンドに変える

弱い依頼の例は次のとおりです。

/hub:run --task "make it faster"

より良い run の使い方は次のようになります。

/hub:run --task "Reduce p50 latency in the product search endpoint without changing response schema" --agents 3 --eval "pytest bench.py --json" --metric p50_ms --direction lower --template optimizer

この形にすると、対象範囲を定義し、制約を守らせ、測定可能なベンチマークをエージェントに与え、metric 名を指定し、どの方向が勝ちかを明示できるため、出力品質が上がります。カバレッジ改善では、値が高いほど良い metric を使います。

/hub:run --task "Add tests for untested utils without modifying production behavior" --agents 3 --eval "pytest --cov=utils --cov-report=json" --metric coverage_pct --direction higher --template test-writer

マージ前に推奨されるワークフロー

重要なコードに run skill を使う前に、リポジトリがクリーンであること、テストが再現可能であること、eval command が機械判読可能、または一貫してパースできる出力を返すことを確認してください。コストと速度を抑えるため、最初は 2〜3 agents から始めるのがおすすめです。コードには可能な限り決定的な eval を使い、--judge はコピーライティングやデザイン案のような主観的な出力に限定するとよいでしょう。勝者がマージされた後も、diff は必ず手動で確認してください。この skill は選定をオーケストレーションしますが、コードオーナーシップの代わりにはなりません。

run skill FAQ

run は Agent Orchestration 用ですか、それとも単純なプロンプト用ですか？

run は Agent Orchestration 用です。複数のエージェントをライフサイクルに沿って調整し、勝者を選ぶために設計されています。1 つの説明、1 つのリファクタリング案、1 つのドラフトだけが必要なら、通常のプロンプトのほうがシンプルです。比較、評価、マージの規律が重要なときに run skill を使ってください。

run をうまく動かすには何が事前に必要ですか？

/hub:run と関連するライフサイクルコマンドを認識できる、AgentHub 互換のセットアップが必要です。測定可能なソフトウェアタスクでは、信頼できる eval command、明確な metric 名、既知の最適化方向も必要です。それらがない場合でも judge mode で実行できることはありますが、結果の客観性は下がります。

この skill を避けるべき場面は？

受け入れ条件のないあいまいなタスク、ロールバック計画のない破壊的変更、テストやベンチマークが不安定なプロジェクトでは、run の利用を避けてください。また、デフォルトで agents 数を増やしすぎるのも避けるべきです。タスク定義が弱い場合、agents を増やしても品質が上がらず、コストとレビュー負荷だけが増える可能性があります。

run skill は初心者にも使いやすいですか？

コマンド形式の Claude skills と AgentHub の基本概念をすでに理解していれば、比較的取り組みやすい skill です。初心者は特に --metric と --direction などの eval パラメータでつまずく可能性があります。パフォーマンス改善、リファクタリング、マージが多いワークフローに進む前に、低リスクなクリエイティブタスクで judge mode から始めるか、シンプルな test command を使うとよいでしょう。

run skill を改善する方法

タスク境界を明確にして run の結果を改善する

run skill は、エージェントが独立して完了できる程度にタスクが絞られているときに最もよく機能します。対象ファイル、期待される挙動、制約、変更してはいけないものを含めてください。たとえば「Refactor auth module」でも意味は通りますが、「Refactor src/auth/session.ts to reduce duplication while preserving public function signatures and existing tests」のほうが、エージェントにとって安全な作業範囲を与えられます。

eval と metric を強化する

コードタスクでは、eval command が品質を左右する最も重要なレバーです。明確に失敗し、安定した metric を出力するコマンドを優先してください。metric には正しい方向を組み合わせます。レイテンシやエラー数は通常 lower、カバレッジ、スループット、スコアは通常 higher を使います。eval output があいまいだと、エージェントが有用な作業をしていても、マージ判断が信頼しにくくなることがあります。

よくある失敗パターンに注意する

よくある失敗パターンには、広すぎるタスク、metric の不足、不安定なテストスイート、測定すべきタスクでの judge-mode 判定、作業内容に合っていない template などがあります。測定可能なパフォーマンス改善には optimizer、カバレッジには test-writer、構造を保ったクリーンアップには refactorer、不具合修正には bug-fixer を使ってください。template が合っていないと、エージェントが誤った種類の解決策へ誘導されることがあります。

最初の出力の後に反復する

最初の /hub:run が終わったら、勝者の diff と不採用になったアプローチを確認します。どれも受け入れられない場合、同じコマンドをそのまま再実行しないでください。タスクを絞り込み、制約を追加し、eval を改善し、またはスコープを小さくします。勝者が惜しいものの未完了な場合は、ライフサイクル全体をやり直すのではなく、不足している問題だけに絞った follow-up command を実行してください。