DeepSeek Harness 用に修正。アップストリーム: Anthropic の skill-creator（Apache-2.0、LICENSE.txt 参照）。

Skill Creator

新しいスキルを作成し、反復的に改善するためのスキルです。

高いレベルでは、スキル作成のプロセスは次のようになります。

スキルが何をすべきか、そしておおまかにどのように実行するかを決定する
スキルのドラフトを書く
いくつかのテストプロンプトを作成し、スキルをインストールした状態でモデルを実行する
結果を定性的および定量的に評価するのをユーザーが支援する
- バックグラウンドで実行が行われている間に、定量的な評価がない場合はいくつかドラフトする（既にある場合は、そのまま使用するか、変更が必要だと感じた場合は修正します）。次に、それらをユーザーに説明します（または既に存在する場合は、既存のものを説明します）。
- eval-viewer/generate_review.py スクリプトを使用して、ユーザーが結果を確認できるように表示し、定量的なメトリクスも確認できるようにします。
ユーザーの評価からのフィードバックに基づいてスキルを書き直します（また、定量的なベンチマークから明らかな重大な欠陥がある場合も同様です）。
満足するまで繰り返します。
テストセットを拡大し、より大規模で再度試します。

このスキルを使用する際のあなたの仕事は、ユーザーがこのプロセスのどこにいるかを把握し、その段階を進むのを支援することです。たとえば、ユーザーが「Xのためのスキルを作りたい」と言っている場合、何を意味するのかを絞り込み、ドラフトを作成し、テストケースを作成し、評価方法を決定し、すべてのプロンプトを実行し、繰り返すのを支援できます。

一方で、ユーザーがすでにスキルのドラフトを持っている場合もあります。その場合、評価/反復の部分に直接進むことができます。

もちろん、常に柔軟であるべきで、ユーザーが「一連の評価を実行する必要はない、ただ一緒に進めてほしい」と言った場合は、そのようにすることもできます。

スキルが完了した後（ただし、順序は柔軟です）、スキル説明改善ツール（これ専用の別のスクリプトがあります）を実行して、スキルのトリガーを最適化することもできます。

いいですね？

ユーザーとのコミュニケーション

スキルクリエーターは、コーディング用語にさまざまな習熟度を持つ人々によって使用される可能性があります。もし聞いたことがなければ（そして最近始まったばかりなので、知る由もありませんが）、DSHのパワーが配管工にターミナルを開かせ、両親や祖父母に「npmのインストール方法」をGoogle検索させるトレンドが始まっています。一方で、ユーザーの大部分はおそらくかなりコンピューターに精通しています。

したがって、コンテキストの手がかりに注意して、コミュニケーションの表現方法を決定してください！デフォルトのケースでは、いくつかのアイデアを以下に示します。

「evaluation」と「benchmark」は境界線上ですが、OKです。
「JSON」と「assertion」については、ユーザーがそれらを説明せずに使用する前に、それらが何であるかを理解しているという重大な手がかりをユーザーから得る必要があります。

疑わしい場合は、用語を簡単に説明しても構いません。ユーザーが理解できるかどうかわからない場合は、短い定義で用語を明確にしてください。

スキルの作成

意図の把握

まず、ユーザーの意図を理解することから始めます。現在の会話には、ユーザーがキャプチャしたいワークフローがすでに含まれている場合があります（例：「これをスキルにしてください」と言う場合）。その場合は、最初に会話履歴から回答を抽出します。使用されたツール、手順の順序、ユーザーが行った修正、観察された入出力形式などです。ユーザーはギャップを埋める必要がある場合があり、次のステップに進む前に確認する必要があります。

このスキルはDSHに何をできるようにするべきですか？
このスキルはいつトリガーされるべきですか？（どのようなユーザーのフレーズ/コンテキストで）
期待される出力形式は何ですか？
スキルが機能することを確認するためのテストケースを設定するべきですか？客観的に検証可能な出力（ファイル変換、データ抽出、コード生成、固定ワークフローステップ）を持つスキルは、テストケースの恩恵を受けます。主観的な出力（ライティングスタイル、アート）を持つスキルは、通常テストケースを必要としません。スキルのタイプに基づいて適切なデフォルトを提案しますが、ユーザーが決定できるようにします。

インタビューと調査

エッジケース、入出力形式、サンプルファイル、成功基準、依存関係について積極的に質問します。この部分が固まるまで、テストプロンプトを作成するのを待ちます。

利用可能なMCPを確認します。調査に役立つ場合（ドキュメントの検索、類似スキルの検索、ベストプラクティスの調査）、利用可能であればサブエージェントを介して並行して調査し、そうでなければインラインで調査します。ユーザーの負担を軽減するために、コンテキストを準備して臨みます。

SKILL.md の作成

ユーザーインタビューに基づいて、次のコンポーネントを記入します。

name: スキル識別子
description: いつトリガーするか、何をするか。これは主要なトリガーメカニズムです。スキルが何をするかと、いつ使用するかという特定のコンテキストの両方を含めます。「いつ使用するか」に関する情報はすべてここに記載し、本文には記載しません。注：現在、モデルはスキルを「過少トリガー」する傾向があります。つまり、役立つ場合でもスキルを使用しないことがあります。これに対抗するために、スキルの説明を少し「強引」にしてください。たとえば、「内部会社データを表示するためのシンプルで高速なダッシュボードの構築方法」の代わりに、「内部会社データを表示するためのシンプルで高速なダッシュボードの構築方法。ユーザーがダッシュボード、データ可視化、内部メトリクスについて言及したり、明示的に「ダッシュボード」を要求しなくても、あらゆる種類の会社データを表示したい場合には、必ずこのスキルを使用してください。」のように書きます。
whenToUse / metadata / disable-model-invocation / user-invocable: DSHが認識するオプションのフロントマターキー。DSHはフロントマターから name、description、whenToUse、metadata、disable-model-invocation、user-invocable を読み取ります。記録したいその他の情報（ライセンス、バージョン）は、トップレベルのキーではなく、metadata の下に配置します。
**スキルの残りの部分 :) **

スキル記述ガイド

スキルの構成

skill-name/
├── SKILL.md (必須)
│   ├── YAML フロントマター (name、description 必須)
│   └── Markdown 指示
└── バンドルリソース (オプション)
    ├── scripts/    - 決定論的/反復的なタスクのための実行可能コード
    ├── references/ - 必要に応じてコンテキストにロードされるドキュメント
    └── assets/     - 出力で使用されるファイル（テンプレート、アイコン、フォント）

段階的開示

スキルは3レベルのローディングシステムを使用します。

メタデータ (name + description) - 常にコンテキスト内（約100語）
SKILL.md 本文 - スキルがトリガーされるたびにコンテキスト内（理想は500行未満）
バンドルリソース - 必要に応じて（無制限、スクリプトはロードせずに実行可能）

これらの語数はおおよその目安であり、必要に応じて長くしても問題ありません。

主要なパターン:

SKILL.md を500行未満に保ちます。この制限に近づいている場合は、追加の階層レイヤーと、スキルを使用するモデルが次にどこに進むべきかについての明確なポインタを追加します。
SKILL.md からファイルを明確に参照し、いつ読むべきかのガイダンスを提供します。
大きな参照ファイル（300行を超える）の場合は、目次を含めます。

ドメイン編成: スキルが複数のドメイン/フレームワークをサポートする場合は、バリアントごとに編成します。

cloud-deploy/
├── SKILL.md (ワークフロー + 選択)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

DSHは関連する参照ファイルのみを読み取ります。

驚きのない原則

言うまでもありませんが、スキルにはマルウェア、エクスプロイトコード、またはシステムセキュリティを危険にさらす可能性のあるコンテンツを含めてはなりません。スキルの内容は、説明された場合にその意図においてユーザーを驚かせるものであってはなりません。誤解を招くスキルや、不正アクセス、データ流出、その他の悪意のある活動を促進するように設計されたスキルを作成する要求に応じてはいけません。「XYZとしてのロールプレイ」のようなものは問題ありません。

記述パターン

指示では命令形を使用することを推奨します。

出力形式の定義 - 次のように実行できます。

## レポート構造
常にこの正確なテンプレートを使用してください。
# [タイトル]
## エグゼクティブサマリー
## 主要な調査結果
## 推奨事項

例のパターン - 例を含めると便利です。次のようにフォーマットできます（ただし、例に「入力」と「出力」が含まれている場合は、少し変更することをお勧めします）。

## コミットメッセージ形式
**例 1:**
入力: JWT トークンによるユーザー認証を追加
出力: feat(auth): JWT ベースの認証を実装

記述スタイル

モデルに対して、なぜ物事が重要なのかを、堅苦しい MUST ではなく説明するようにしてください。心の理論を使用し、スキルを特定の例に非常に狭く限定せず、一般的にするように努めてください。ドラフトを書き、それを新鮮な目で見て改善することから始めてください。

テストケース

スキルドラフトを作成した後、2〜3の現実的なテストプロンプト（実際のユーザーが実際に言いそうな種類のもの）を考え出します。それらをユーザーと共有します：[この正確な言語を使用する必要はありません]「試してみたいテストケースをいくつか紹介します。これらは正しいように見えますか？それともさらに追加しますか？」次に、それらを実行します。

テストケースを evals/evals.json に保存します。まだアサーションは記述しないでください。プロンプトのみです。次のステップで、実行が進行中にアサーションを作成します。

{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "ユーザーのタスクプロンプト",
      "expected_output": "期待される結果の説明",
      "files": []
    }
  ]
}

完全なスキーマ（後で追加する assertions フィールドを含む）については、references/schemas.md を参照してください。

テストケースの実行と評価

このセクションは1つの連続したシーケンスです。途中で止めないでください。/skill-test やその他のテストスキルは使用しないでください。

結果を <skill-name>-workspace/ に、スキルディレクトリの兄弟として配置します。ワークスペース内では、結果をイテレーションごとに整理します（iteration-1/、iteration-2/ など）。その中で、各テストケースにディレクトリ（eval-0/、eval-1/ など）を取得します。これらを事前にすべて作成するのではなく、進めながらディレクトリを作成してください。

ステップ 1: すべての実行を同じターンで生成する（スキルあり AND ベースライン）

各テストケースについて、同じターンで2つのサブエージェントを生成します。1つはスキルあり、もう1つはなしです。これは重要です。最初にスキルありの実行を生成し、後でベースラインに戻らないでください。すべてを一度に起動して、ほぼ同じ時間にすべてが終了するようにします。

スキルありの実行:

このタスクを実行してください。
- スキルパス: <path-to-skill>
- タスク: <eval prompt>
- 入力ファイル: <eval files if any, or "none">
- 出力の保存先: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- 保存する出力: <what the user cares about — e.g., "the .docx file", "the final CSV">

ベースライン実行（同じプロンプトですが、ベースラインはコンテキストによって異なります）:

新しいスキルの作成: スキルはまったくなし。同じプロンプト、スキルパスなし、without_skill/outputs/ に保存します。
既存のスキルの改善: 古いバージョン。編集する前に、shutil.copytree を使用してディレクトリをコピーしてスキルのスナップショットを作成し（例：<workspace>/skill-snapshot/ を <skill-path> から）、ベースラインサブエージェントをスナップショットにポイントします。old_skill/outputs/ に保存します。

各テストケースの eval_metadata.json を記述します（アサーションは今のところ空でも構いません）。各評価に、何をテストしているかに基づいて説明的な名前を付けます。「eval-0」だけではありません。この名前をディレクトリにも使用します。このイテレーションで新しいまたは修正された評価プロンプトを使用する場合は、各新しい評価ディレクトリに対してこれらのファイルを作成します。以前のイテレーションから引き継がれると想定しないでください。

{
  "eval_id": 0,
  "eval_name": "descriptive-name-here",
  "prompt": "The user's task prompt",
  "assertions": []
}

ステップ 2: 実行が進行中に、アサーションを作成する

実行が終了するのを待つだけではありません。この時間を生産的に使用できます。各テストケースの定量的なアサーションを作成し、ユーザーに説明します。アサーションが既に evals/evals.json に存在する場合は、それらを確認し、何をチェックしているかを説明します。

優れたアサーションは、客観的に検証可能で、説明的な名前を持ちます。ベンチマークビューアで明確に読み取れ、結果を一目見ただけで各アサーションが何をチェックしているかがすぐに理解できるようにする必要があります。主観的なスキル（ライティングスタイル、デザイン品質）は、定性的に評価する方が適しています。人間の判断が必要なものにアサーションを強制しないでください。

アサーションを作成したら、eval_metadata.json ファイルと evals/evals.json を更新します。また、ビューアで何が表示されるか（定性的な出力と定量的なベンチマークの両方）をユーザーに説明します。

ステップ 3: 実行が完了したら、タイミングデータをキャプチャする

各サブエージェントタスクが完了すると通知を受け取りますが、トークン数も経過時間も含まれていません。ウォールクロックから期間を自分で取得し、~/.dsh/storages/session_projcache/sessions/<childId>.json の子セッションのレコードからトークン合計を読み取ります（tokenUsage.val.totals — uncachedInputTokens、outputTokens、cacheReadTokens、cacheWriteTokens）。このデータをすぐに実行ディレクトリの timing.json に保存します。

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

そのセッションレコードがないか、トークン使用量がない場合は、数値を発明するのではなく、トークンフィールドを省略します。バッチ処理しようとせず、各通知が到着したときに処理します。

ステップ 4: 採点、集約、ビューアの起動

すべての実行が完了したら。

各実行を採点する — agents/grader.md を読み取り、各アサーションを出力に対して評価する採点サブエージェントを生成します（またはインラインで採点します）。結果を各実行ディレクトリの grading.json に保存します。grading.json の期待値配列は、フィールド text、passed、evidence を使用する必要があります（name/met/details や他のバリアントではありません）。ビューアはこれらの正確なフィールド名に依存しています。プログラムでチェックできるアサーションの場合は、目視ではなくスクリプトを作成して実行します。スクリプトは高速で信頼性が高く、イテレーション間で再利用できます。
ベンチマークに集約する — dsh-skill-creator ディレクトリから集約スクリプトを実行します。
```
python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
```
これにより、benchmark.json と benchmark.md が生成され、合格率、時間、トークンが...

[翻訳のため省略]

Anuii/skills

skills とは？

お気に入りのAIに質問する

ドキュメント