ワークフローを新しいツールではなくHermesスキルとするべきタイミングはいつでしょうか？

ワークフローが指示とシェルコマンド、既存のHermesツールで構成される場合はスキルを、組み込み認証、厳格なバイナリ処理、ストリーミング、または毎回完全に同一の動作が必要なカスタムPythonを使用する場合はツールを優先してください。

HermesのSKILL.mdファイルの先頭に必要なYAMLフィールドは何か？

有効なYAML frontmatterには、名前と説明を含める必要があります。名前は指定された長さの制限内で小文字およびハイフンを使用し、説明はスキルインデックスが完全なコンテンツを読み込む前に表示する内容です。

Hermesは、コンテキストトークンを無駄に消費せずに、どのようにスキルコンテンツをロードするのでしょうか？

Hermesはプログレッシブ・ディスクロージャーを採用しています。エージェントはまず名前と短い説明を含むコンパクトな一覧を表示し、必要に応じて完全なSKILL.mdを読み込み、タスクに必要な最小限のスライスとして参照ファイルをオープンします。

Hermesスキルにおけるシークレットと非シークレットのプリファレンスの保存場所

APIキーやトークンは required_environment_variables に設定し、プロファイルの環境変数ファイルにルーティングされてサンドボックスに安全に渡されるようにします。パスや設定は metadata.hermes.config に設定し、 config.yaml の skills.config 以下に保持され、設定マイグレーション時に適用されるようにします。

「Hermesスキルがスラッシュコマンドやスキル一覧から消える理由は何でしょうか？」

OSの不一致、ツールが存在するか欠けている場合にスキルを非表示にするrequiresまたはfallbackルール、外部ディレクトリをローカルコピーがシャドウイングしている重複名、および発見をブロックするフォルダ構成のミスについてプラットフォームを確認してください。

Hermesエージェントスキル作成 — SKILL.mdの構造とベストプラクティス

高速に読み込み、安定した動作を実現する著者ヘルメスのスキル

Hermes Agentは、スキルを反復可能なワークフローを教えるデフォルトの方法として扱います。公式ドキュメントでは、それらはオープンな agentskills.io 仕様に準拠したオンデマンドのナレッジドキュメントとして説明されており、**プログレッシブディスクロージャー（段階的開示）**を通じて読み込まれます。これにより、モデルはまず小さなインデックスを見て、タスクが実際に必要とする場合にのみ完全な指示を取得します。

作成作業は、cleverな言葉遣いというよりもパッケージングに重点を置きます。ランタイムにいつ手順を読み込むか、どの順序の手順が「完了」とみなされるか、そして成功と沈黙した失敗をどのように区別するかを伝えます。この記事では、SKILL.md の構造、サポートフォルダ、可視性ルール、およびシークレット（秘密情報）と非シークレット設定の分割に焦点を当てます。これらは、スキルが /slash コマンドに表示されるかどうか、ハブのインストールで生存するか、またはCI環境で静かに消えてなくなるかを決定する詳細事項です。

Hermesは、アシスタントを単なるチャットインターフェースではなく、推論、検索、メモリ、ツールから構築されるシステムとして扱うより広範な AIシステム：セルフホスト型アシスタント、RAG、およびローカルインフラ クラスタ内に位置しています。インストールパス、プロバイダーの接続、ゲートウェイの動作、および ~/.hermes のレイアウトはすべて Hermes AIアシスタント - インストール、セットアップ、ワークフロー、およびトラブルシューティング ガイドで説明されています。日常のシェルでの使いやすさ（hermes skills、プロファイル、ゲートウェイ、メモリ）については、 Hermes Agent CLIチートシート — コマンド、フラグ、およびスラッシュショートカット の方がスキャンしやすいでしょう。実際のデプロイでは、スキルは プロファイル（個別の設定、シークレット、メモリ、スキルツリー）から分離性を継承します。 Hermes AIアシスタントのスキル：本番環境でのセットアップ では、個々のマークダウンファイルではなく、これらのプロファイルを所有の単位として扱うことを提唱しています。スキルに名前を付け、共有 external_dirs と単一のプロファイルのどちらに含めるべきかを決定する際には、これを念頭に置いてください。

Hermes Agentスキル作成の抽象的なカバー画像

スキルか、ツールか？

公式のガイダンスは明確です。スキルを使用するのは、その機能性が主に文章の指示とHermesが既に公開しているシェルコマンドやツール（CLIのラップ、git の操作、curl の呼び出し、または構造化された取得のための web_extract の使用など）に依存している場合です。ツールを使用するのは、APIキーや認証フロー、決定論的なバイナリ処理、ストリーミング、または毎回同じ方法で実行される必要があるPythonの緊密な統合が必要な場合です。

この境界線は実際には重要です。なぜなら、スキルはエージェントコードを変更せずに提供されるのに対し、ツールはレビューとリリースのオーバーヘッドを伴うからです。ほとんどのチームは、スキルから始めて、失敗モード（認証のリフレッシュループ、バイナリパーサー、厳格な冪等性）が明確になった時点で、脆いコア部分のみをツールに昇格させることで恩恵を受けます。

手順とキュレーションされたメモリ

スキルはワークフローをどのように実行するかを答え、Hermesのバウンデッドコアメモリはユーザーとプロジェクトについて何が既に合意されているかを答えます。タスクがその記述と一致する場合、スキルは読み込まれます。一方、MEMORY.md と USER.md は、小さくキュレーションされた事実層としてプロンプトに保持されます。これらの2つのメカニズムは競合するのではなく積み重ねられ、スナップショット、制限、外部プロバイダーの全体像は Hermes Agentメモリシステム：永続的なAIメモリが実際にどのように機能するか で説明されています。

スキルディレクトリの解剖

ディスク上では、各スキルは ~/.hermes/skills/ 内のフォルダであり、通常 devops/ や research/ などのカテゴリの下にネストされています。Hermesは 末端に SKILL.md を期待しています。それ以外は、指示が散らばってしまう場合に追加するオプションの構造です。一般的なパターンは、長文のテーブルやベンダードキュメント用の references/、出力の骨格用の templates/、決定論的なヘルパー用の scripts/、およびエージェントが再取得してはいけない静的ファイル用の assets/ です。

このレイアウトは、実際におけるプログレッシブディスクロージャーの動作と一致しています。エージェントは、本当に深い付録が必要になるまでメインファイルにとどまることができます。「ハッピーパス（正常系）」の文章を SKILL.md に保持し、まれに使用される詳細を references/ に押しやることは、トークン予算を保護する最もコストのかからない方法の一つです。

Hermesは、config.yaml の skills.external_dirs を通じて 外部スキルディレクトリ をマージすることもできます。これらのパスは発見のためにスキャンされますが、エージェントは依然として skill_manage を介してプライマリの ~/.hermes/skills/ ツリーに書き込みます。ローカル名は外部名をシャドウ（上書き）しますので、ホームディレクトリで共有スキルを「修正」した場合、同じ外部リポジトリをプルするチームメイトは、ローカルコピーを削除またはrenameするまで、あなたの編集を見ることはありません。これは「私のマシンでは動く」という混乱の一般的な原因です。

レビューに耐えるSKILL.mdのフロントマター

SKILL.md の本文はMarkdownですが、最初のブロックは --- デリミタ間の有効なYAMLである必要があります。実際のスキルは長いフェンス付きの例を蓄積するため、 Markdownコードブロック：構文、言語、および例の完全ガイド からの小さな習慣（一貫した言語タグ、読みやすい抜粋、緊密なフェンス）は、大きなファイルを人間にとって保守可能にし、モデルにとってスキャンしやすくします。

必須フィールド は name と description です。name はスラッシュルートとインデックスキーになり、ハイフンを含む小文字のままにする必要があり、ドキュメントに記載された長さの上限を尊重する必要があります。description は、レベル0 で多くのセッションが支払う唯一の文章であるため、ブログ記事の最初の段落ではなく、検索結果やルーティング文字列のように読まれるべきです（「バックアップが古くなっているように見える場合、最新のアーカイブとチェックサムを確認する」など）。

version、author、license などのオプションのトップレベルキーは、ハブのパッケージングと監査に役立ちます。platforms リスト（macos、linux、windows）は、見かけよりも鋭敏です。設定されると、Hermesは一致しないホストでスキルを完全に省略します。これが、「私のMacでは動く」スキルが、短いスキルリストというエラーメッセージもなくLinux CIで消えてしまう理由です。

Hermes固有のノブは metadata.hermes の下に存在します：tags、related_skills、および次のセクションの条件付き可視性フィールド。required_environment_variables は .env に配置され、サンドボックスに渡されるべきシークレットを宣言します。required_credential_files は、DockerまたはModalにマウントする必要があるOAuthトークンファイルや他のディスク上の認証情報をカバーします。metadata.hermes.config は、config.yaml の skills.config の下に保存される非シークレットのプリファレンスを宣言します。

公式ドキュメントが サイズの規律 を強調するのには理由があります。description をその予算に切り詰め、手順を優先し、歴史的な注釈や巨大なオプションマトリクスを references/ へ押しやって、部分的な skill_view でもエージェントに実行可能なものを提供してください。

以下は、~/.hermes/skills/devops/backup-check/SKILL.md（または任意のカテゴリフォルダ）にドロップして、そこから反復できる 最小限の SKILL.md です。

---
name: backup-check
description: 毎晩のバックアップアーカイブが存在し、空でないこと、および最新ファイルのクイックチェックサムスポットチェックに合格することを確認します。
version: 1.0.0
metadata:
  hermes:
    tags: [devops, backups, shell]
    requires_toolsets: [terminal]
    config:
      - key: backup_check.archive_dir
        description: バックアップアーカイブを保持するディレクトリの絶対パス
        default: "/var/backups"
        prompt: バックアップアーカイブディレクトリ（絶対パス）
---

# バックアップアーカイブのスポットチェック

## 使用時期

ユーザーがバックアップが実行されたことを確認するために依頼した場合、ディスク上の最新のアーカイブを監査する場合、または復元ドリルの前に空または古くなったバックアップファイルをキャッチするために使用します。

## クイックリファレンス

- 最新のアーカイブディレクトリは `skills.config.backup_check.archive_dir` で設定されています（メタデータで宣言されている場合、`hermes config migrate` を介して設定）。
- デフォルトのチェックは、mtimeによる `ls` と、空でないファイルのための `test -s` を使用します。

## 手順

1. スキルの設定からアーカイブディレクトリを解決するか、未設定の場合は一度ユーザーに尋ねます。
2. 期待されるパターン（例：`*.tar.zst`）に一致する最も最近変更されたファイルを一覧表示します。
3. ファイルが存在し、空でないことを確認し、応答のためにそのパスとサイズを記録します。
4. アーカイブの横にチェックサムファイルが存在する場合、ドキュメント化されたツール（例：`sha256sum -c`）でそれを検証します。

## 落とし穴

- 失敗したジョブがパスに触れた場合、空のファイルでも最近のmtimeを持つことがあります。常にサイズを確認してください。
- 相対パスは、ターミナルのcwdがバックアップホストではない場合に壊れます。設定で絶対パスを使用してください。

## 検証

ユーザーは、最新のアーカイブパス、バイトサイズ、およびチェックサムのOK行または `.sha256` サイドカーが見つからなかったという明示的な注記を表示するはずです。

実践におけるプログレッシブディスクロージャー

プログレッシブディスクロージャーは、スナップだと感じるスキルライブラリと、最初のユーザーメッセージの前に数千のトークンを燃やすものの違いです。Hermesは3つの概念的ステップを歩みます：コンパクトなカタログ（名前と短い記述）、タスクが一致した場合の完全な SKILL.md、そして—必要であれば—skill_view パスを介したリファレンスファイルのスライス。レベル0がモデルが明示的にコミットするまで読む唯一のものと仮定してください。description と本文の最初の画面の各文は、ストーリーテリングではなくルーティングを助けるべきです。

部分的な読み込みで生存する実用的なアウトラインは、When to use（平易な言語でのトリガー）、Quick reference（コマンド、環境変数、ファイルパス）、Procedure（エージェントが即興で作り出してはいけない順序立てられた手順）、Pitfalls（既知の失敗モード）、および Verification（「グリーン」の状態がどのようなものか）です。物語的な歴史、ベンダーのチェンジログダンプ、20行のオプションテーブルは、エージェントが単一のセクションをプルできるように、安定した見出し付きで references/ に属します。

スキルがアクティブになると、Hermesは本文の ${HERMES_SKILL_DIR} と ${HERMES_SESSION_ID} を書き換えることができ、シェル行が手動で構築されたパスなしでインストールされたフォルダを指すようになります。オプションの インラインシェル スニペット（!cmd``）は、新鮮なコンテキスト（現在のブランチ、ディスク空き容量）を注入できますが、それらはホストで実行され、skills.inline_shell がオンでない限り無効のままです。このフラグは、便利トグルではなく、スキルソース全体の信頼境界として扱ってください。

条件付きアクティベーションとプロンプトの衛生

スキルは、現在のセッションにどのツールセットやツールが存在するかに基づいて 表示または非表示 にすることができます。requires_toolsets / requires_tools は、存在しなければならない機能の背後でスキルをゲートします。fallback_for_toolsets / fallback_for_tools は、プレミアム統合が存在しない場合に、より安価またはローカルなパスを表示します—有料のウェブ検索APIが構成されていない場合のDuckDuckGoフォールバックが典型的な例です。

これらの述語は プロンプトノイズ を直接的に形成します。過度に厳格な requires_* ルールは、hermes tools のセットアップをまだ完了していない新規ユーザーからスキルを隠します。過度に緩い fallback_for_* ルールは、誰かがAPIキーを省略するたびに、ライブラリの半分を複製します。有用な中間地は、実際の前提条件を名付け、hermes chat --toolsets skills でテストし、スキルリストが期待どおりに呼吸するかどうかを見ながら、キーやツールセットを意図的にトグルすることです。

シークレット、設定、および認証情報ファイル

シークレット は required_environment_variables で宣言されるべきです。Hermesは、ローカルCLIでスキルが読み込まれたときにプロンプトを表示し、値を .env に永続化し、生のシークレットをモデルのトランスクリプトにストリーミングせずに terminal と execute_code サンドボックスに渡すことができます。リモートチャットサーフェスは、インラインでキーを収集することを拒否し、代わりに hermes setup または手動の .env 編集を人々に指し示します—スキルテキストをその動作に一致するように作成してください（ユーザーにキーが必要であることを伝え、Telegramに貼り付けるように 言わない でください）。

非シークレットのプリファレンス—デフォルトパス、組織名、機能トグル—は metadata.hermes.config に属します。値は config.yaml 内の skills.config に解決され、hermes config show に表示され、モデルがタスク中に設定ファイルを開く必要がないように、解決された事実としてスキルメッセージに届きます。

ファイル形式の認証情報（OAuthトークンJSON、サービスアカウントキー）は required_credential_files にマッピングされます。これらのファイルが存在する場合、HermesはそれらをDockerにバインドマウントするか、Modalジョブに同期することができます。事前に宣言することで、ローカルではスクリプトが動作するが、サンドボックスで死亡するという典型的なギャップを回避できます。

サポートスクリプトと依存関係

アップストリームガイドは、作成者を 退屈な依存関係（標準ライブラリPython、curl、およびHermes自身のツール（web_extract、read_file、terminal））に向けることを推進します。これは純粋さよりも再現性に関するものです—エージェントがクリーンなコンテナで実行されるたびに、追加の pip install のたびに、静かな失敗が増えるからです。

JSONまたはXMLのパーシングが面倒な場合、scripts/ 下の短いスクリプトと ${HERMES_SKILL_DIR} パスは、モデルに各実行でパーサーを再導出させるよりも優れています。パッケージを本当に必要とする場合、Procedure でインストールコマンドを記述し、Pitfalls で失敗の症状を繰り返し、依存関係が欠落しているときに大きく失敗する Verification コマンドを提供してください。

公開、ハブインストール、および信頼

コミュニティスキルは、スキルハブとユーザーガイドがリストする他の発見パス（公式のオプションスキル、GitHubスラッグ、skills.sh エントリ、.well-known インデックス、および生の SKILL.md URL）を通って移動します。インストールは、明らかな漏洩、注入、破壊的なパターンに対してスキャンされます。信頼ティアは 組み込み から コミュニティ まであり、一部の発見は --force でしかクリアされず、最も深刻なケースは完全にブロックされます。

SKILL.md ファイルの形状はHermes固有ではありません。IDE中心のアシスタントは、異なる発見とトリガーを使用して、同じプログレッシブロードのアイデアを使用します。 Claudeスキルと開発者向けSKILL.md：VS Code、JetBrains、Cursor は有用な対比読書です—フロントマターの規律と「関連する場合のみ読み込む」は、インストーラーとスラッシュコマンドの配線が異なる場合でも継承されます。

組織全体のロールアウトは、通常、読み取り専用の共有のための external_dirs と プライベートタップまたは共有Gitリポジトリ をペアにし、skill_manage がスキルをインプレースで変異することを許可されている場合、各プロファイルの下にエージェント書き込み可能なコピーを保持します。

トラブルシューティングと最適化

スキルが誤動作する場合、文章を書き直す前にこのチェックリストを歩いてください。

可視性 — platforms、requires_*、および fallback_for_* 述語を確認します。「私のMacでは動く」がLinux CIでは動かないスキルは、よくプラットフォームガードです。
名前衝突 — ローカルと外部ディレクトリにまたがる重複名は ローカル優先 を-followsします。積極的に入れ替えまたは名前空間化してください。
発見レイアウト — 誤配置された SKILL.md または間違ったカテゴリフォルダは、スキルをインデックスから完全にドロップさせる可能性があります。
トークン負荷 — セッションが遅く感じる場合、レベル0の記述を短くし、深さを references/ へ移動し、巨大なテーブルを重複排除します。
エージェント編集 — Hermesは skill_manage を介してスキルを作成、パッチ、または削除できます。貴重なスキルをコードのように扱ってください：差分をレビューし、スナップショットをエクスポートし、アップグレードが逸脱した際にバンドルされたスキルを意図的にリセットします。

全体を再読するよりも、緊密な回帰ループが優れています：hermes chat --toolsets skills -q "Use the <skill> workflow to <concrete task>" は、エージェントがフリースタイルに入る前に、適切な開示レベルをプルしていることを示すはずです。skill_view を呼び出さない場合、When to use テキストまたは description は、人々がリクエストを表現する方法と一致していない可能性があります。

公式の参照は、動作変更に対して権威があります—ランタイムセマンティクスに関する スキルシステム ユーザーガイド、作成者向けのルールに関する スキルの作成、コピー＆ペースト例のための バンドルスキルカタログ、およびHermesが準拠する共有ファイル形式に関する agentskills.io仕様。