skill-benchmark

スキルベンチマーク

これはスキルのベンチマークシステムです。Claude Code のスキルが、ベースライン（スキルなし）と比較してパフォーマンスを向上させるかどうかを厳密に評価します。

業界のベストプラクティス（Anthropic と OpenAI の評価ガイダンス）に基づく方法論：

• 段階的な評価：まず決定論的なチェックを行い、その後 LLM を判定者として使用します
• セッションごとに分離されたサンドボックスを使用します — クリーンな状態を保ち、成果物を共有しません
• 非決定性を考慮して複数回実行します
• 偽陽性を検出するためにネガティブコントロールタスクを実施します
• 行動の兆候を把握するためにトランスクリプトを分析します

セキュリティに関する注意

このベンチマークは、ヘッドレスモードで動作するために昇格された権限が必要な、ネストされた claude -p セッションを起動します。以下のセキュリティ上重要なフラグを、緩和策とともに使用します。

フラグ／手法	必要な理由	緩和策
--dangerously-skip-permissions	ヘッドレスセッションにはツール呼び出しを承認する人間がいません。このフラグがないと、セッションは永久に停止します	各セッションは --allowedTools によって Read、Write、Edit、Bash、Grep、Glob のみに制限されます（スキル使用モードでは Skill も追加）。ネットワークツールや MCP へのアクセスはありません。
env -u CLAUDECODE -u CLAUDE_CODE_ENTRYPOINT	Claude Code は、これらの環境変数によってネストされた claude -p をブロックします。子セッションを起動するには、変数の設定を解除する必要があります。	env -u は子プロセスの環境にのみ影響します。親セッションは保護されたままです。
--append-system-prompt	公平に比較できるよう、スキル使用セッションで常にスキルが呼び出されるようにします。この指定がないと、モデルはスキルの使用を省略することがよくあります。	固定テンプレートを使用し、置き換えるのは <skill_name> のみです。外部コンテンツやユーザー提供のコンテンツは挿入されません。正確なプロンプトはステップ 1 の確認時に表示されます。
runs_without_error コマンド	タスクの検証では、生成されたコードが動作するか確認するために、python3 <file> のようなコマンドを実行する必要があります。	コマンドは安全な実行ファイルの許可リストと照合して検証され、シェルのメタ文字が含まれている場合は拒否されます。shell=True は使用しません。

信頼できるソースのタスクファイルとスキルのみを使ってベンチマークを実行してください。 ステップ 1 の確認を進めると、これらのセキュリティ上の影響を理解したものとみなされます。

実行フロー

以下の手順に正確に従ってください。

---

ステップ 1：入力の収集

このスキルは、次の 2 つの方法で実行できます。

オプション 1：カスタム設定 — ユーザーが config.yml を作成します：

cp .claude/skills/skill-benchmark/config.example.yml .claude/skills/skill-benchmark/config.yml
# edit config.yml
/skill-benchmark

オプション 2：デフォルト実行 — 設定は不要です：

/skill-benchmark

実施内容：

1. config.yml を確認 — 次の順に探します：（1）スキルディレクトリ内の config.yml、（2）~/.claude/skills/skill-benchmark/config.yml、（3）引数として渡されたパス。見つかった場合は、その値を読み込んで使用します。見つからない場合は、組み込みのデフォルト値を使用します：

   • runner_model: sonnet
   • judge_model: opus
   • task_count: 5
   • negative_controls: 1
   • difficulties: {easy: 2, medium: 2, hard: 1}
   • runs: 1
   • max_turns: 10
   • results_dir: ./skill-bench/results

2. ベンチマーク対象のスキル — config.yml に skill が設定されている場合は、それを使用します。設定されていない場合は、AskUserQuestion を通じてユーザーに尋ねます。一般的な場所を検索します：

   • .claude/skills/<name>/SKILL.md
   • ~/.claude/skills/<name>/SKILL.md
   • 直接指定されたファイルパス

3. タスクセット — カスタムのタスクセットディレクトリがあるか、スキルの領域に基づいてタスクを自動生成するかを尋ねます。

4. 設定の確認 — 読み込んだ設定またはデフォルト設定の最終内容をユーザーに示します。次のセキュリティに関する注意を含めます：「このベンチマークでは、--dangerously-skip-permissions と制限付きツール（--allowedTools）を指定して、ヘッドレスの claude -p セッションを実行します。セッションは分離されたサンドボックスディレクトリ内で実行されます。スキルを使用するセッションには、次のシステムプロンプトが追加されます：「重要：作業を始める前に、必ず最初に Skill ツールを skill="<skill_name>" と指定して呼び出し、関連するスキルの指示を読み込んでください。」」。開始前にユーザーの確認を求めます。

5. $RESULTS_DIR を設定 — スキル名とタイムスタンプを使って結果ディレクトリを作成します：

   RESULTS_DIR="<results_dir>/<skill_name>-$(date +%Y%m%d-%H%M%S)"
   mkdir -p "$RESULTS_DIR"
   

   以降のすべてのパス（tasks/、sandbox/、outputs/、grades/、report.md）は $RESULTS_DIR の下に配置します。ファイルをベースの results_dir に直接置いてはいけません。必ずタイムスタンプ付きのサブディレクトリを作成し、その中に配置します。

---

ステップ 2：対象スキルを読み込んで分析する

対象スキルの SKILL.md ファイルを最後まで読みます。次の内容を抽出します：

• 領域：このスキルが扱う分野（例：コードレビュー、テスト、デプロイ）
• 機能：このスキルは、Claude が実行するよう具体的にどのような内容を指示していますか？
• 起動条件：このスキルはどのような場合に使用すべきですか？
• 使用ツール：このスキルはどのツールに依存していますか？

簡潔な分析の要約を作成します。これは、関連するタスクを生成する際に使用します。

---

ステップ 3：ベンチマークタスクを生成する

カスタムのタスクセットが指定されていない場合は、タスクを自動生成します。評価のベストプラクティスに従ってタスクを設計します：

タスクカテゴリ（すべて必須）：

1. ポジティブタスク — スキルが役立つはずのタスク（大半を占めます）：

   • 簡単（2 タスク）：スキルの領域における単純明快なタスク
   • 中程度（2 タスク）：スキルの指針をより深く適用する必要があるタスク
   • 難しい（1 タスク）：スキルの専門知識が最も重要となる複雑なタスク

2. ネガティブコントロール（1 タスク）：スキルの領域外にあり、スキルが起動したり役立ったりするべきではないタスクです。誤検出を見つけるために使います。無関係なタスクでスキルがパフォーマンスを低下させる場合は、問題の兆候です。

タスクの形式

各タスクを $RESULTS_DIR/tasks/task-NN-<difficulty>.md に書き込みます：

# Task: <descriptive-name>
difficulty: easy|medium|hard
category: <domain>
type: positive|negative-control

## Prompt
<the exact prompt that will be sent to Claude via `claude -p`>

## Expected Outcome
<clear description of what a correct response looks like>

## Verification Checks
<deterministic checks to run BEFORE LLM grading>
- file_exists: <filename that should be created>
- file_contains: <pattern> in <filename>  (or just <pattern> to search all files)
- syntax_valid: <language — run syntax checker>
- runs_without_error: <command to execute, e.g., "python3 <filename>">

## Grading Rubric
- Correctness: <specific criteria for correctness>
- Completeness: <what must be included for full marks>
- Quality: <quality expectations — best practices, clarity, etc.>

## Tags
<comma-separated tags for grouping>

タスク設計のルール：

• プロンプトは自己完結型にします。各タスクは新しい claude -p セッションとして実行されるため、事前のコンテキストはありません。
• 具体的で決定的な検証項目（ファイルが存在する、コードが実行できる、出力が一致するなど）を含む Verification Checks を記載します。
• 分野の専門家 2 人が独立して同じ合否判定に至るようにします。タスクが曖昧な場合は書き直します。
• 各タスクは解決可能なものにします。期待される結果は実現可能でなければなりません。

タスクの検証（カスタムタスクセット向け）

ユーザーがカスタムタスクセットを指定した場合、実行前に各タスクファイルを検証します。

1. 構造チェック：ファイルに必須セクション（## Prompt、## Expected Outcome、## Verification Checks、## Grading Rubric）が含まれていることを確認します。必須セクションが欠けているファイルは拒否します。
2. コマンドチェック：各タスクに対して python3 scripts/run_checks.py --validate <task_file> を実行します。これにより、runs_without_error の項目がコマンド許可リストに照らして検証され、シェルのメタ文字を含むコマンドは拒否されます。
3. プロンプトの確認：タスクプロンプトに、外部コードのダウンロード、URLへのアクセス、不明なソースからのパッケージのインストールを指示する内容が含まれている場合は、ユーザーに警告し、明示的な確認を求めます。
4. 概要：実行前に、ユーザーに次の内容を提示します。「N 件のタスクが見つかりました。検証コマンド：[list]。続行しますか？」

警告： 信頼できないソースのベンチマークタスクは絶対に実行しないでください。タスクプロンプトは、ネストされたセッションでツールへのアクセス権を持つコード生成指示として実行されます。

---

ステップ 4：Eval セッションの実行

各タスクについて、claude -p を使用して 2 つのセッションを実行します。互いに干渉しないよう、各セッションはそれぞれ独立したサンドボックスディレクトリで実行する必要があります。

複数回実行のサポート

設定で runs > 1 の場合、各タスクを N 回実行します。実行ごとに、独立したサンドボックスと出力ディレクトリを用意します。これにより、LLM 出力の非決定性に対応できます。

• 複数回実行時のディレクトリ構造（runs: 3）：

  sandbox/task-01/run-1/with-skill/
  sandbox/task-01/run-1/baseline/
  sandbox/task-01/run-2/with-skill/
  sandbox/task-01/run-2/baseline/
  sandbox/task-01/run-3/with-skill/
  sandbox/task-01/run-3/baseline/
  outputs/task-01/run-1/with-skill/
  outputs/task-01/run-1/baseline/
  outputs/task-01/run-2/with-skill/
  outputs/task-01/run-2/baseline/
  ...
  grades/task-01/run-1/with-skill-grade.json
  grades/task-01/run-1/baseline-grade.json
  ...
  

• 単一実行時のディレクトリ構造（runs: 1、デフォルト）：

  sandbox/task-01/with-skill/
  sandbox/task-01/baseline/
  outputs/task-01/with-skill/
  outputs/task-01/baseline/
  grades/task-01/with-skill-grade.json
  grades/task-01/baseline-grade.json
  

  runs: 1 の場合は、出力をシンプルにするため、run-N/ サブディレクトリの階層を省略します。

• 複数回実行の集計：すべての実行の採点後、タスクごとに以下を算出します。

  • avg_score：すべての実行における weighted_total の平均
  • best_score：実行間の weighted_total の最大値
  • worst_score：実行間の weighted_total の最小値
  • pass@k：スコアが 70 以上の実行が少なくとも 1 回あること（タスクは「合格可能」と見なされます）
  • pass^k：すべての実行でスコアが 70 以上であること（タスクは一貫して合格しています）
  • std_dev：スコアの標準偏差（値が大きいほど挙動に一貫性がありません）

分離環境の設定

セッションを 1 つでも実行する前に、すべてのセッション用の独立した作業ディレクトリを作成します。

# For runs: 1 (default)
mkdir -p "$RESULTS_DIR/sandbox/task-NN/with-skill"
mkdir -p "$RESULTS_DIR/sandbox/task-NN/baseline"

# For runs: 3 (multi-run)
mkdir -p "$RESULTS_DIR/sandbox/task-NN/run-1/with-skill"
mkdir -p "$RESULTS_DIR/sandbox/task-NN/run-1/baseline"
mkdir -p "$RESULTS_DIR/sandbox/task-NN/run-2/with-skill"
# ... etc

各 claude -p 呼び出しでは、まず自身のサンドボックスディレクトリに cd する必要があります。これにより、以下を防止できます。

• ファイルの競合（両方のセッションが同じ場所に fibonacci.py を書き込むなど）
• 一方のセッションが他方のセッションで作成されたファイルを読み込むこと
• スキルありの実行とベースライン実行との間で状態が共有されること
• 同じタスクの異なる実行間で状態が共有されること

ネストされたセッションの修正

重要： Claude Code は、再帰的な claude -p 呼び出しを防ぐために CLAUDECODE=1 と CLAUDE_CODE_ENTRYPOINT=cli を設定します。ベンチマークで子セッションを起動するには、env -u CLAUDECODE -u CLAUDE_CODE_ENTRYPOINT を使って、これらの設定を解除する必要があります。

安全である理由： env -u が変更するのは子プロセスの環境のみであり、親セッションの環境変数は変更されません。子セッションは、制限付きツール（--allowedTools）を使用して、独立したサンドボックスディレクトリ内で実行されます。

セッションコマンド

すべての claude -p 呼び出しには、必ず --dangerously-skip-permissions を含めてください。これを指定しないと、ヘッドレスセッションはツールの使用を人間が承認するのを待ち続け、永久に停止します。

セッション A — スキルあり：

# For runs: 1 → sandbox/task-NN/with-skill, outputs/task-NN/with-skill
# For runs: 3 → sandbox/task-NN/run-R/with-skill, outputs/task-NN/run-R/with-skill
cd "$SANDBOX_DIR" && \
env -u CLAUDECODE -u CLAUDE_CODE_ENTRYPOINT \
  claude -p "<task_prompt>" \
  --output-format stream-json \
  --verbose \
  --dangerously-skip-permissions \
  --allowedTools "Skill(<skill_name>),Read,Edit,Bash,Grep,Glob,Write" \
  --append-system-prompt "IMPORTANT: Before starting any work, you MUST first call the Skill tool with skill=\"<skill_name>\" to load the relevant skill instructions. Follow whatever instructions the skill provides throughout your work." \
  --model <runner_model> \
  --max-turns <max_turns> \
  > "$OUTPUT_DIR/raw_stream.jsonl" 2>&1

--append-system-prompt を使う理由： これを指定しない場合、スキルはツールとして利用可能になるだけで、モデルが呼び出すかどうかを選ぶ必要があります。単純なタスクでは、モデルはスキルを完全にスキップして、コードを直接書くことがよくあります。システムプロンプトを追加することで、スキルが必ず呼び出されるようになり、「スキルの指示あり」と「指示なし」を公平に比較できます。

セッション B — ベースライン（スキルなし）：

cd "$SANDBOX_DIR" && \
env -u CLAUDECODE -u CLAUDE_CODE_ENTRYPOINT \
  claude -p "<task_prompt>" \
  --output-format stream-json \
  --verbose \
  --dangerously-skip-permissions \
  --allowedTools "Read,Edit,Bash,Grep,Glob,Write" \
  --disallowedTools "Skill" \
  --model <runner_model> \
  --max-turns <max_turns> \
  > "$OUTPUT_DIR/raw_stream.jsonl" 2>&1

--disallowedTools "Skill" を使う理由： Skill ツールは組み込み機能であり、--allowedTools だけでは制限できません。明示的に使用を禁止しないと、ベースラインのモデルがスキルを呼び出してしまい、比較に影響する可能性があります。

$SANDBOX_DIR と $OUTPUT_DIR は実行回数によって異なります。

• runs: 1 → $RESULTS_DIR/sandbox/task-NN/<mode> および $RESULTS_DIR/outputs/task-NN/<mode>
• runs: N → $RESULTS_DIR/sandbox/task-NN/run-R/<mode> および $RESULTS_DIR/outputs/task-NN/run-R/<mode>

重要：

• --dangerously-skip-permissions は必須です。これを指定しないと、claude -p は「Allow」をクリックする人間がいない状態で、権限の承認を待って停止します。
• <skill_name> は、ステップ 1 で確認した実際のスキル名（例：code-commenter）に置き換えてください。Skill() を空のままにしないでください。スキルが読み込まれず、両方のセッションが同一になります。
• claude -p を実行する前に、必ずサンドボックスに cd してください。これが分離の仕組みです。
• cd してから実行するため、出力のリダイレクトには絶対パス（> .../raw_stream.jsonl）を使用してください。

実行戦略

• 同じタスクと実行回のセッション A とセッション B は並列で実行します（バックグラウンドの Bash コマンドを使用）。
• システムに過剰な負荷をかけないよう、タスクは順番に処理します。
• 複数回実行する場合は、task-02 を開始する前に task-01 のすべての実行を完了させます。
• 1 つのタスク内では、システムリソースに余裕があれば、複数の実行を並列で実行してもかまいません。
• 各セッションの完了後、raw_stream.jsonl を解析し、出力ディレクトリに次の 3 つのファイルを作成します。

response.json — JSONL ストリームから最後の type: "result" イベントを抽出します。

transcript.json — すべてのストリームイベントを JSON 配列にまとめます。

meta.json — response.json から抽出したセッションのメタデータです。次の情報が含まれます：session_id、model（modelUsage のキーから取得）、skill_name、mode、stop_reason、duration_ms、duration_api_ms、num_turns、total_cost_usd、および usage（入力／出力／キャッシュのトークン数）。scripts/parse_stream.py スクリプトで抽出できます。フィールド一覧は --help で確認してください。

セッションが失敗またはタイムアウトした場合は、エラーを meta.json に記録し、失敗した実行として扱います（スコア：0）。

---

ステップ 5：出力を採点する（段階的な採点）

2 層の採点方法を使用します。まず決定論的なチェックを行い、次に LLM を審査員として使用します。これにより、明確な失敗をすばやく検出し、微妙な評価にはモデルを活用できます。

レイヤー 1：決定論的なチェック

各セッションの出力に対して、決定論的チェックのスクリプトを実行します。

# For runs: 1 → sandbox/task-NN/<mode>, grades/task-NN/<mode>-checks.json
# For runs: N → sandbox/task-NN/run-R/<mode>, grades/task-NN/run-R/<mode>-checks.json
python3 "scripts/run_checks.py" \
  "$RESULTS_DIR/tasks/task-NN-<difficulty>.md" \
  "$SANDBOX_DIR" \
  "$GRADES_DIR/<mode>-checks.json"

このスクリプトは、タスクファイルの ## Verification Checks セクションを読み取り、サンドボックスディレクトリ内で各チェック（file_exists、syntax_valid、runs_without_error、file_contains）を実行します。

結果を $RESULTS_DIR/grades/task-NN/<mode>-checks.json に保存します。

{
  "file_exists": true,
  "syntax_valid": true,
  "runs_without_error": true,
  "file_contains": {"def add": true, "def subtract": true},
  "all_passed": true
}

決定論的なチェックに失敗した場合（ファイルがない、構文エラー、実行時クラッシュ）、LLM による採点にかかわらず、そのタスクの正確性スコアの上限は 50 です。コードが動作していないためです。

レイヤー 2：LLM-as-Judge

各タスクについて、採点サブエージェントを起動します（Agent ツールを使用し、subagent_type: "general-purpose"、modelには判定モデルを設定します）。

採点担当へのプロンプトには、次の内容を必ず含めてください。

1. 元のタスクプロンプト
2. タスクファイルに記載されている期待される成果
3. タスクファイルに記載されている採点ルーブリック
4. 採点対象の実際の出力（response.json の result フィールド）
5. レイヤー 1 の決定論的チェックの結果
6. 各評価基準を 0〜100 点で採点し、根拠を示すよう指示すること

また、採点担当にはサンドボックスディレクトリ（$RESULTS_DIR/sandbox/task-NN/<mode>/）にセッションが作成した実ファイルを読み、正しさを確認するよう伝えてください。テキスト出力だけを採点するのではなく、コードが実際に存在し、正しいことを検証してください。

各出力は個別に採点してください（両方の出力を採点担当に見せないでください。これにより比較バイアスを防げます）。

採点基準とデフォルトの重み：

• 正確性（40%）：出力はタスクを正しく解決していますか？決定論的チェックに失敗した場合は、最大でも 50 点としてください。
• 完全性（25%）：すべての要件に対応していますか？
• 品質（20%）：コードの品質、ベストプラクティス、説明の明瞭さ
• 効率性（15%）：解決策は直接的かつ効率的でしたか？（トークン使用量も考慮してください）

採点担当は、構造化された回答を必ず返さなければなりません。JSON を出力するよう指示してください。

{
  "deterministic_checks_passed": true|false,
  "correctness": { "score": 0-100, "justification": "..." },
  "completeness": { "score": 0-100, "justification": "..." },
  "quality": { "score": 0-100, "justification": "..." },
  "efficiency": { "score": 0-100, "justification": "..." },
  "weighted_total": 0-100,
  "summary": "..."
}

採点結果は、対応する grades ディレクトリに保存します。

• runs: 1 → $RESULTS_DIR/grades/task-NN/with-skill-grade.json および baseline-grade.json
• runs: N → $RESULTS_DIR/grades/task-NN/run-R/with-skill-grade.json および baseline-grade.json

バックグラウンドエージェントを使って、異なるタスクや実行回の採点を並行して行うことができます。

---

ステップ 6：トランスクリプトを分析する

レポートを作成する前に、行動に関するシグナルを確認するため、transcript.json ファイルを分析してください。これは重要です。スコアだけでは全体像を把握できません。

各セッションについて、分析スクリプトを実行します。

# For runs: 1 → outputs/task-NN/<mode>/
# For runs: N → outputs/task-NN/run-R/<mode>/
python3 "scripts/analyze_transcript.py" \
  "$OUTPUT_DIR/transcript.json" \
  "$OUTPUT_DIR/behavior.json"

このスクリプトは transcript.json から次の情報を抽出します。

• ツール呼び出し回数：各ツール（Read、Write、Edit、Bash など）が使用された回数
• 堂々巡りの検出：セッションで同じ操作のループや再試行が発生しましたか？（同じツールが連続で 3 回以上呼び出された場合）
• エラーからの回復：セッションでエラーが発生した後に回復しましたか、それとも何も報告せずに失敗しましたか？

出力（behavior.json）：

{
  "tool_calls": {"Read": 2, "Write": 1, "Bash": 3, "Edit": 0},
  "total_tool_calls": 6,
  "thrashing_detected": false,
  "errors_encountered": 0,
  "errors_recovered": 0
}

---

ステップ 7：比較レポートを生成する

採点と分析がすべて完了したら、最終レポートを生成します。

すべての採点ファイル、メタファイル、行動ファイルを読み込み、次の項目を算出します。

1. タスクごとのスコア：スキルとベースラインの加重合計
2. タスクごとの差分：skill_score - baseline_score
3. 集計スコア：全タスクの平均
4. 評価基準ごとの集計：各条件の正確性、完全性、品質、効率性の平均
5. 決定論的チェックの合格率：すべての決定論的チェックに合格したタスクの割合（スキル対ベースライン）
6. ネガティブコントロールの結果：対象領域外のタスクでスキルはどのような成績でしたか？
7. トークン使用量とコストの比較：meta.json の total_cost_usd フィールドと usage フィールドから取得
8. 行動の比較：behavior.json に基づくツール使用パターン、堂々巡り、ターン効率
9. 判定ロジック：
   • Delta >= +10%：使用する — スキルは大きな効果があります
   • Delta が +3% から +10%：使用を推奨 — スキルには中程度のメリットがあります
   • Delta が -3% から +3%：中立 — スキルの効果はわずかです
   • Delta が -10% から -3%：使用しないことを推奨 — スキルが悪影響を及ぼす可能性があります
   • Delta <= -10%：使用しない — スキルは大きな悪影響を及ぼします

次の形式を使用して、レポートを $RESULTS_DIR/report.md に書き込みます。

# Skill Benchmark Report: <skill-name>
Date: <YYYY-MM-DD HH:MM>
Runner Model: <model> | Judge Model: <model> | Tasks: <N> | Runs: <R>

## Verdict: <emoji> <VERDICT>
**Skill scores <X>% <higher/lower> than baseline on average.**

## Summary
| Metric | With Skill | Baseline | Delta |
|--------|-----------|----------|-------|
| Avg Score | X% | Y% | +/-Z% |
| Correctness | X% | Y% | +/-Z% |
| Completeness | X% | Y% | +/-Z% |
| Quality | X% | Y% | +/-Z% |
| Efficiency | X% | Y% | +/-Z% |

## Deterministic Check Pass Rate
| Condition | Pass Rate |
|-----------|-----------|
| With Skill | X/N tasks (Y%) |
| Baseline | X/N tasks (Y%) |

## Per-Task Breakdown
| # | Task | Type | Difficulty | Skill | Baseline | Delta | Winner |
|---|------|------|-----------|-------|----------|-------|--------|
| 1 | ... | positive | easy | X% | Y% | +/-Z% | Skill/Baseline |
| N | ... | negative | - | X% | Y% | +/-Z% | ... |

## Negative Control Results
<How did the skill perform on out-of-domain tasks? If it hurt performance, flag this.>

## Where Skill Helps
- <identified patterns where skill outperformed baseline>

## Where Skill Hurts
- <identified patterns where baseline outperformed skill>

## Behavioral Analysis
| Metric | With Skill | Baseline | Delta |
|--------|-----------|----------|-------|
| Avg Tool Calls | X | Y | +/-Z |
| Avg Turns | X | Y | +/-Z |
| Thrashing Detected | X/N | Y/N | |
| Avg Duration (s) | X | Y | +/-Z |
| Avg Cost | $X | $Y | +/-$Z |
| Total Cost | $X | $Y | +/-$Z |

## Recommendations
- <actionable suggestions based on the results>
- <suggestions for improving the skill if it underperformed>
- <flag if skill hurts negative control tasks>

レポートをユーザーに提示し、完全な結果の保存場所を伝えてください。

---

参考資料

• 出力ディレクトリ構造 — 単一実行モードと複数実行モードの完全なツリー
• 設定 — 設定形式、変数、解析方法

利用可能なスクリプト

• scripts/parse_stream.py — raw_stream.jsonl を解析し、response.json、transcript.json、meta.json を生成します
• scripts/analyze_transcript.py — transcript.json を解析し、behavior.json（ツールの使用回数、無駄な試行、エラー）を生成します
• scripts/run_checks.py — タスクファイルに基づいて、サンドボックスに対する決定的な検証チェックを実行します

各スクリプトの詳しい使い方を確認するには、--help を指定して実行してください。

エラー処理

• claude -p セッションが失敗した場合：エラーを記録し、スコアを 0 として、残りのタスクを続行します
• 採点エージェントが失敗した場合：1 回再試行し、その後は「採点対象外」として、平均から除外します
• 対象のスキルファイルが見つからない場合：利用可能なスキルを一覧表示し、ユーザーに選択を求めます
• 2 件未満のタスクしか正常に完了しなかった場合：処理を中止し、データが不十分であることを報告します
• 決定的なチェックがクラッシュした場合（例：python3 が利用できない）：警告を記録し、LLM による採点に進みます