jev-skill-select

Jev によるスキル選択

ウォーム接続では、2 回のラウンドトリップで約 0.5 秒です（接続をプールする前は約 1.2 秒でした。以前は呼び出しごとに新しい TLS セッションを開いていました）。最初のラウンドトリップでは、ターンに対してすべてのスキルをランク付けします。カタログは 120 件ずつのバッチに分割され、並行して問い合わせます。そのため、377 件のスキルを含むカタログなら 4 件、960 件なら 8 件のリクエストが同時に送られ、最も遅いリクエストと同じ時間で完了します。2 回目のラウンドトリップは 1 件のリクエストで、上位 5 件を詳しく読み込み、それぞれを個別に評価し、すべてを却下する場合もあります。実時間と請求対象のリクエスト数は同じではありません。料金が発生するのはリクエストです。Jev に到達するターンごとに ceil(skills / 120) + 1 件と見積もってください。カタログ内に該当するスキルがほとんどないターンは、最初のリクエストの後に終了します。雑談や通常のターンではスキルは返されません。スキルフォルダーの読み込みには別途時間がかかり、460 件のスキルで約 0.15 秒です。

プラグインでモデルのルーティングも実行する場合、両者は 1 件のリクエストを共有します。 Jev は質問数ではなく リクエスト ごとに課金するため、プラグインはルーティングの 3 つの質問と、このステージ 1 の質問を同じ呼び出し（jevkit/turn.py）で行い、それぞれの機能独自のしきい値に回答を渡します。両方の処理は接続レベルでもプールされます（client.py はキープアライブソケットを維持します。呼び出しごとに新しい TLS セッションを確立していたため、以前は判定にかかる約 520 ms のうち約 275 ms を消費していました）。この環境の 379 件のスキルを含むカタログを使って、2026-09-21/22 に実際の API で測定したところ、ウォーム接続で質問 1 件あたり約 180～250 ms、Hermes のターン全体（ルーティング＋スキル選択を統合し、接続をプール）は 1784 ms → 672 ms でした。リクエスト数は 3 件から 2 件に減りました。判定内容は変わりません。同じ回答、同じしきい値です。リリース前に実際のターンを 8 回実行したところ、8 回すべてで同じティアと同じスキルが選ばれました。/jev merge_requests off を実行すると、リクエストを再び分けられます。プライベートプロファイル、機微な内容と判断されるターン、または機能のみの状態に設定されたルーティングでは統合されないため、以前は送信されていなかったテキストが送信されることはありません。

確認の返答がマシンの外に送信されることはありません。「ok」「thanks, that worked」「got it」「never mind」「yes go ahead」、単独の「stop」、句読点または絵文字だけのターンには、ローカルで 0 ms で応答します。このゲートの対象は意図的に限定されています。実際の質問（純粋な next? の続きは除く）、どれほど短くても指示（「do it」「stop it」「do all of them now」など）、数字、またはゲートが読み取れない単語は Jev に送信されます。ラテン文字以外の文字で書かれたリクエストはすべてこれに含まれます。誤って問い合わせた場合のコストは 1 セント未満ですが、誤ってスキップすると、この機能は何もせず静かに処理を終えてしまいます。

この限定的なローカルゲートは、純粋な社交的な会話の切り出し（how are you doing today）と純粋な next? の続きも認識します。実際の質問や指示（all working?、next, fix the config）は引き続き Jev に送られます。using-superpowers など、選択専用のメタスキルは、ルーティングとスキル選択を統合したリクエストを含め、ランク付けの前に除外されるため、タスクの手順を押しのけることはありません。

Hermes について

Blender の作業では、jev-blender をデフォルトのドメインエントリーポイントとして読み込み、その後、関連するジオメトリ／制作スキルを読み込んでください。これによって常時推論が有効になったり、モデルのルーティングが変わったりすることはありません。コード優先のゲートが定型的な呼び出しをスキップし、実際のアーティファクトの検証をローカルに保ちます。

/jev skills on を設定すると、hermes-jev プラグインが新しいターンごとに一度、この処理を行います。スキルが明らかに適合する場合は、その名前を示す1行の提案がターンに添えられます。明らかに該当しない場合を除き、skill_view で読み込んでください。プラグインは、今回のセッションで実際に読み込まれるフォルダー、つまりプロファイルの skills フォルダーと、すべての skills.external_dirs フォルダーを Hermes に確認し、skills.disabled も尊重します。プロジェクトローカルのスキルフォルダーは読み込みません。

さらに /jev routing on を設定すると、ステージ1の質問はそれぞれ個別に送信されず、ルーティングのリクエストにまとめて含まれます（上記のコストに関する注記を参照）。2つの回答は、それぞれの判断を担当するコードによって読み取られ、ログに追加されるのは merged の行だけです。この共有リクエストが失敗した場合、スキルは提案されず、次のフックでルーティングが単独で質問します。これは、各機能が単独で動作するときと同じ挙動です。

提案は、表示される前に Hermes 独自のローダーで確認されます。今回のセッションで skill_view が開けない名前は決して提示されず、提示される名前はローダーが認識する名前です。そのため、利用できない手順に案内されることはありません。これは、JeV が順位付けしたカタログよりプロファイルのカタログのほうが小さい場合や、スキルが一度もインストールされていないマシンでは特に重要です。検証できない場合は何も表示しません。失敗する呼び出しをしてまで提案する価値はないためです。

提案を役立つものにするため、さらに2つのルールを設けています。

• セッションですでに読み込まれたスキルは、再度提案されません。
• エージェントが繰り返し辞退するスキルは、そのプロファイルでは提示を停止します。14日以内に、過去5回以上の提案のうち読み込まれた割合が10分の1未満の場合、そのスキルは抑制されます。ただし、6時間に1回は提示されるため、役立つようになったスキルが再び候補に戻ることがあります。

プラグインは提案を行うたびに記録します。プロファイルの jev/skill-feedback.json に保存されるのは、スキル名、時刻、エージェントがスキルを読み込んだかどうかだけです。2つ目のルールを無効にするには、jev/state.json で "skill_feedback": "off" を設定します。

実際の1週間分（提案1,188件）を再生して測定した結果です。

• 変更前： 403件が5分以内に読み込まれました（34%）。
• 両方のルール適用後： 提案771件、読み込み395件（51%）。

これにより、115件の重複提案と294件の辞退された提案が除かれ、読み込みは8件減りました。5分以内の読み込みは相関を示すものであり、提案が読み込みを引き起こした証明ではありません。

fail-open の診断

ローカルの skill 判定ログエントリーに、範囲を限定した reason_code が含まれるようになりました。値は no_skills、sensitive_turn、stage_one_incomplete、timeout や invalid_response などの認識済みの転送／検証コード、または other です。成功した記録では null が設定されます。任意の理由テキスト、プロンプト、生の例外メッセージは記録されません。予算やしきい値を変更する前に、意図的なプライバシー／カタログによるスキップとサービス障害を区別してください。このフィールドがない古い記録から、原因を遡って特定することはできません。推測せず、不明の分類に残してください。fail-open は引き続き、スキルに対する否定的な判定ではなく、何も表示しない動作です。

直接尋ねる（任意のエージェント）

jev pick-skill --turn "<the request>"            # searches Hermes, Claude Code, Codex and ./skills folders
jev pick-skill --turn "..." --root ~/my/skills   # or name the folders; repeat --root for each one

--root を指定するとデフォルトのフォルダーが置き換えられるため、検索対象にしたいフォルダーをすべて指定してください。Python からは、skillpick.discover_roots(hermes_home) が Hermes の読み込むフォルダー（共有フォルダーを含む）を返します。このフォルダーを skillpick.discover() に渡せます。

返信

{"status": "ok", "needs_skill": 0.78, "skills": [{"name": "xlsx", "path": ".../xlsx/SKILL.md", "match": 0.72}], "latency_ms": 1143}

needs_skill（0～1）と、最大3件の{name, path, match}が最適なものから順に返されます。matchが0.5以上のもののうち、最初のスキルを読み込みます。リストが空の場合はスキルなしで進めてください。スキルを探し回る必要はありません。

ほかに、skillsリストが空の形式が3種類あります。

返信	意味	対応
{"status": "ok", "needs_skill": 0.0, "skills": [], "latency_ms": 0, "skipped": "trivial"}	ローカルで回答しました。Jevには問い合わせていません	スキルなしで進めてください
{"status": "ok", "needs_skill": 0.0, "skills": [], "latency_ms": 663}	Jevがカタログを順位付けしましたが、該当するものがなかったため、2回目のリクエストはありませんでした	スキルなしで進めてください
{"status": "fail_open", "reason": "...", "skills": []}	Jevには問い合わせていないか、応答がありませんでした。原因は障害、スキルが見つからない、またはターンに秘密情報が含まれているように見えたことです	このスキルが存在しないものとして進めてください。これは「スキル不要」という判定ではありません

カタログが960スキルの上限を超えると、これらのいずれにもskills_droppedが表示されます。これは、最後に見つかったもののうち順位付けされなかったスキルの数です。そのため、「該当するスキルがない」という結果には、これらのスキルは含まれていません。上限以下に戻すには、使わないスキルを無効にしてください。

注意事項

• 各スキルのフロントマターからnameとdescriptionだけを読み取り、説明文の先頭200文字だけを参照するため、説明が曖昧だったり冗長だったりするとスキルは見つかりません。しきい値ではなく、説明文を修正してください。
• 同じ名前のスキルが複数のフォルダーにある場合、最初に検索されたフォルダーが優先されます。Hermesでは、プロファイル専用のフォルダーが最初です。
• 送信前にターンは編集されます。秘密情報が含まれているように見えるターンは送信されず、空のリストを含むfail_openが返されます。
• バッチが1つでも失敗すると、選定全体がフェイルオープンになります。部分的な順位付けでは、適切なスキルが失われたバッチにあった場合でも、自信を持って「スキルなし」と判断してしまうためです。
• 提案はあくまで参考です。読み込んだスキルがタスクに合わないと分かった場合は、そのスキルを外して作業を続けてください。