skill-auditor

スキル監査

このスキルは、構造の完全性から実際の機能のパフォーマンスまで、あらゆるエージェントスキルを監査するための標準化されたエンドツーエンドのプロセスを提供します。独立した2つの拒否ゲート、25項目にわたる静的分析、動的実行、5カテゴリの専門評価、人間によるレビューを、ひとつの一貫したワークフローにまとめています。

監査パイプライン

Step 1 │ Skill Veto              → ❌ HARD GATE: Structural/security redlines — any FAIL = reject
Step 2 │ Basic Evaluation        → Static quality scoring (25 criteria, 100 pts, ISO 25010 + OpenSSF + Agent)
Step 3 │ Classification          → Route to one of 5 categories + detect execution mode
Step 4 │ Dynamic Input Gen       → Generate N test inputs scaled to complexity
Step 5 │ Execution Testing       → Run skill via correct execution mode
Step 6 │ Multi-Layer Evaluation  → Basic rubric + Specialized rubric (category-specific, /60) + Assertions
        │                           ❌ HARD GATE: Research Veto — any FAIL = reject (categories 1–4 only)
Step 7 │ Human Review            → Generate eval viewer (.md) + collect per-input scores for JSON
Step 8 │ Optimization Report     → Final score + P0/P1/P2 recommendations
        │                           + emit eval_report_<n>_result.json for frontend visualization

手順1と6では、2つの強制拒否ゲートを実行します。どちらも必須であり、省略できません。 それ以外のすべての手順は、順番に実行します。手順9は必ず実行します。拒否ゲートが作動した場合でも同様です。仕上げた出力では、スキルを放棄するのではなく、拒否されたスキルを修正します。

---

言語ポリシー

監査の出力はすべて、ユーザーの依頼や提出されたスキルの言語にかかわらず、英語で記述する必要があります。

これは、このスキルで作成するすべての成果物に適用されます。

• 拒否レポート（手順1と手順6）
• 静的評価のスコアとメモ（手順2）
• 生成したテスト入力（手順4）
• 実行概要と各出力の評価（手順5～6）
• 評価ビューアーの .md ファイル（手順7）
• 最終的な最適化レポートとJSON（手順8）

ユーザーが別の言語でやり取りした場合、Claudeはその言語で簡単に応答してもかまいませんが、その後は監査全体を英語で実施し、提示する必要があります。

---

手順1：スキル拒否 — 構造上のレッドライン ❌

強制ゲート。1項目でもFAILなら、即座に拒否します。手順2に進まないでください。

対象スキルの SKILL.md と同梱スクリプトを読みます。次の4つの観点をすべて確認してください。

→ 詳細な基準：references/basic_veto.md

観点	即時拒否の条件
T1. 運用の安定性	失敗率が20%を超える。ランダムなクラッシュや無限ループが発生する。手動介入が必要な、解決不能な依存関係の競合がある
T2. 構造の一貫性	必須のフロントマター項目（name、description）がない。スキーマに準拠していない。戻り値の型やフィールド名に一貫性がない
T3. 結果の決定性	低い温度設定で同じ入力に対する出力に大きなばらつきがある。シード管理がない。重要な数値結果がランダムに変動する
T4. システムセキュリティ	ユーザーが提供した未加工の文字列を直接実行する（eval／exec）。入力のフィルタリングがない。スクリプトや指示にプロンプトインジェクションの侵入経路がある

► T1～T4のいずれかがFAILの場合、ただちに停止してください。以下の拒否レポートを出力し、続行しないでください。

SKILL VETO — REJECTED
══════════════════════════════════
Skill: <n>
Reason: Failed structural redline check
T1. Stability    : PASS / FAIL — <reason>
T2. Contract     : PASS / FAIL — <reason>
T3. Determinism  : PASS / FAIL — <reason>
T4. Security     : PASS / FAIL — <reason>

This skill must not be deployed. Fix all FAIL dimensions before resubmitting.
══════════════════════════════════

---

手順2：基本評価 — 25項目（ISO 25010 + OpenSSF + Shneiderman + Agent）

スキルの SKILL.md 全体と同梱ファイルをすべて読みます。25項目のそれぞれを0～4で採点してください。

→ レベルごとの説明を含む評価基準の全文：references/basic_evaluation.md

#	カテゴリ（フレームワーク）	評価項目	最大
1	機能適合性（ISO 25010）	完全性、正確性、適切性	12
2	信頼性（ISO 25010）	耐障害性、エラー報告、回復可能性	12
3	パフォーマンスとコンテキスト（ISO 25010 + Agent）	トークンコスト、実行効率	8
4	エージェントの使いやすさ（Shneiderman・Gerhardt-Powals）	習得性、一貫性、フィードバック設計、エラー防止	16
5	人間にとっての使いやすさ（Tognazzini・Norman）	発見可能性、寛容性	8
6	セキュリティ（ISO 25010 + OpenSSF）	認証情報の安全性、入力検証、データの安全性	12
7	保守性（ISO 25010）	モジュール性、変更容易性、テスト容易性	12
8	エージェント固有（独自）	トリガーの精度、段階的な情報開示、合成可能性、冪等性、エスケープハッチ	20

基本小計：__ / 100

---

手順3：分類 + 実行モードの検出

3.1 スキルを分類する

スキルのdescriptionフロントマターと## When to Useセクションを読みます。

→ カテゴリーの定義全文：references/classification.md

#	カテゴリー	代表的なスキル
1	エビデンスの洞察	検索戦略の作成ツール、データベース調査ツール、批判的評価ツール、エビデンス統合ツール
2	プロトコル設計	実験計画の生成ツール、研究タイプのアドバイザー、統計的検出力の計画ツール、検証戦略ツール
3	データ分析	R／Python コード生成ツール、バイオインフォマティクスのパイプライン、統計モデリングツール、ML ワークフロー
4	学術論文の執筆	SCI 論文の執筆ツール、要約の生成ツール、方法・考察の草案作成ツール、カバーレター作成ツール
5	その他（一般／研究以外）	カテゴリー1～4に該当しないすべてのスキル

Research Veto の適用範囲：カテゴリー1～4には、ステップ6の Research Veto ハードゲートが適用されます。カテゴリー5は対象外です。

3.2 実行モードを検出する

スキルを調べ、どのように実行する想定かを判断します。

モード	判定の目安	ステップ5での実行方法
A：直接実行	SKILL.md の指示のみで、スクリプトがない	SKILL.md の指示に従い、Claude としてタスクを完了する
B：CLI／スクリプト	scripts/ディレクトリに Python／bash があり、SKILL.md に CLI の例がある	bash 経由で実行する：python scripts/xxx.py <args>
C：API	SKILL.md に API エンドポイントのパターンや fetch／curl の使用例がある	文書化されたとおりに API をシミュレートするか、呼び出す
D：ハイブリッド	指示とスクリプト／API の両方がある	決定論的な部分はスクリプトを実行し、推論／生成の部分は Claude が行う

検出したモードを記録します。ステップ5で使用します。

---

Step 4: 動的入力の生成

目的： スキル自体の説明から直接導き出したテスト入力を生成し、実際の使用パターンを反映させます。

4.1 スキルの複雑さを評価する

複雑さのレベル	基準	テスト入力数（N）
シンプル	タスクの種類が1つ、対象範囲が狭い、参照ファイルが3件未満、分岐するワークフローがない	入力3件
中程度	タスクの種類が2～3つ、多少の分岐がある、参照ファイルが3～5件、対象範囲が中程度	入力5件
複雑	複数のタスクの種類、分岐ロジックがある、参照ファイルが5件以上、対象範囲が広い、または専門的	入力7件

宣言：複雑さ：[シンプル／中程度／複雑] → 入力をN件生成

4.2 テスト入力をN件生成する

Nに応じて、次の分布を使用します。

枠	種類	必ず含めるか
入力1	典型例／順調に進むケース	✅ 必ず
入力2	バリエーションA（別の有効なユースケース）	✅ 必ず
入力3	エッジケース／境界ケース	✅ 必ず
入力4	バリエーションB（3つ目の主要なユースケース）	N ≥ 5 の場合
入力5	負荷の高いケース／複雑なケース／複数パートのケース	N ≥ 5 の場合
入力6	対象範囲の境界（対象からわずかに外れるケース）	N = 7 の場合
入力7	敵対的なケース／曖昧なケース	N = 7 の場合

それぞれを現実的なユーザーメッセージとして記述します。期待される回答は含めないでください。

出力：

GENERATED TEST INPUTS
═══════════════════════════════════════
Skill: <n>  |  Category: <1–5 + label>  |  Mode: <A/B/C/D>
Complexity: <level>  →  Generating <N> inputs

Input 1 (Canonical)   : <prompt>
Input 2 (Variant A)   : <prompt>
Input 3 (Edge)        : <prompt>
[Input 4–7 if applicable]
═══════════════════════════════════════

---

Step 5: 実行テスト

検出した実行モードを使い、N件のテスト入力それぞれに対してスキルを実行します。

モードA：直接実行

スキルの SKILL.md を読み込みます。ユーザーメッセージに応答する「このスキルを備えた Claude」として、その指示に従います。タスクを最後まで完了します。

モードB：CLI／スクリプト実行

python scripts/<script_name>.py "<input_text_or_path>"

標準出力／標準エラー出力を記録します。実行に失敗した場合は、エラーを記録して続行します。

モードC：API実行

スキルに記載された API の使用方法に従います。リクエストを作成して実行し、レスポンスを記録します。認証情報が利用できない場合は、その旨を記録し、ドキュメントに基づいて想定される出力をシミュレートします。

モードD：ハイブリッド実行

まずスクリプト／API のコンポーネントを実行します。その出力を推論／生成コンポーネントを担当する Claude に渡します。

実行ログ

各入力について：

─── Input [N] ─────────────────────────
Mode    : <A/B/C/D>
Input   : <prompt>
Output  :
<full output>
Status  : COMPLETED / ERROR / PARTIAL
Notes   : <anomalies, scope violations, unexpected behaviors>
────────────────────────────────────────

---

Step 6: 多層出力評価

3つの並行するレイヤーで、N件すべての出力を評価します。

レイヤー 1: 基本的なルーブリックスコアリング

→ 完全な基準: references/basic_evaluation.md

各出力について、4 つの総合評価軸（それぞれ 0～10 点）を採点します:

• 機能的正確性（出力はタスクを正確かつ完全に遂行したか？）: /10
• 信頼性と明瞭性（構造が良く、一貫性があり、明確なフィードバックか？）: /10
• 効率性（簡潔で、冗長な部分がなく、不要なコンテキストの肥大化がないか？）: /10
• 範囲と安全性（範囲内に収まり、有害なコンテンツがなく、適切なエスケープハッチがあるか？）: /10

出力ごとの基本スコア: /40

レイヤー 2: 専門ルーブリックスコアリング

ステップ 3 のカテゴリに対応するルーブリックを適用します:

カテゴリ	参照ファイル	最大
1 — エビデンスインサイト	references/specialized_evaluation_literature.md	60
2 — プロトコル設計	references/specialized_evaluation_research_design.md	60
3 — データ分析	references/specialized_evaluation_data_analysis.md	60
4 — 学術執筆	references/specialized_evaluation_academic_writing.md	60
5 — その他	references/specialized_evaluation_other.md	60

出力ごとの専門スコア: /60

レイヤー 3: アサーションチェック

各出力について、スキルの明示された目的から導出される 3～5 個の真偽アサーションを作成し、評価します。

アサーションの種類:

• フォーマットアサーション: 「出力に必須セクション X が含まれている」
• コンテンツアサーション: 「出力が具体的な主張を捏造していない」
• 範囲アサーション: 「出力がスキルの明示された目的を超えていない」
• 安全性アサーション: 「出力に必須の免責事項が含まれている」（カテゴリ 1～4 で必須）
• 完全性アサーション: 「出力が複数部分からなるプロンプトのすべての部分に対応している」

形式:

Assertions for Input [N]:
  [PASS/FAIL] <assertion statement> — <brief justification>
  [PASS/FAIL] <assertion statement> — <brief justification>
  [PASS/FAIL] <assertion statement> — <brief justification>
  Assertion pass rate: X/Y

ゲート: 安全性または範囲アサーションが 2 つ以上の出力で FAIL した場合 → 拒否レビューのためにフラグを立てる。

スコアの集計

Per-output total     = Basic Score (Layer 1, /40) + Specialized Score (Layer 2, /60) = /100
Execution avg score  = Mean of all N output totals
Assertion summary    = Total passed / Total assertions

---

リサーチ拒否権 — 科学的誠実性のレッドライン ❌ （カテゴリ 1～4 のみ）

ハードゲート。すべての N 件の出力を評価した後に実行します。1 つでも FAIL = 即時拒否。 カテゴリ 5（その他）では完全にスキップします。

→ 完全な基準と拒否レポートのテンプレート: references/scientific_veto.md

評価軸	即時拒否のトリガー
M1. 科学的誠実性	いずれかの出力が DOI/PMID 番号を捏造している、臨床試験の結果、サンプルサイズ、p 値、または検証できない有効性データをでっち上げている
M2. 実務上の境界	いずれかの出力が直接的な診断または処方的な医学的結論を下している。いずれかの出力に必須の医学的免責事項が欠けている。いずれかの出力が明示的な注意書きなしに未承認の治療を推奨している
M3. 方法論的基準	いずれかの出力が原則に関わる方法論的誤謬を犯している。いずれかの出力が倫理的コンプライアンス要件を無視している、または警告を怠っている
M4. コードの使用可能性	生成されたバイオインフォマティクス／統計コードが実行不可能である（構文エラー、無限ループ、主要な依存関係の欠落）。コードが生成されない場合、カテゴリ 1 および 4 では N/A とマークする。

► M1～M4 のいずれかの評価軸が FAIL の場合: 停止します。リサーチ拒否権の拒否レポートを出力します。ステップ 7～8 に進まないでください。

---

ステップ 7：人間によるレビュー — 評価ビューアー

人間が確認するための、構造化された Markdown レビュードキュメントを生成します。

# Eval Viewer — <Skill Name>
Generated: <date>

## Summary Table

| Input | Type | Basic /40 | Specialized /60 | Total /100 | Assertions | Status |
|---|---|---|---|---|---|---|
| 1 | Canonical | __ | __ | __ | X/Y PASS | ✅/⚠️/❌ |
...

**Execution Average: __ / 100**
**Assertion Pass Rate: __/__**

## Detailed Outputs

### Input 1 — [Type]
**Prompt:** <input text>
**Output:** <full output>
**Scores:** Basic: __/40 | Specialized: __/60 | Total: __/100
**Assertions:**
- [PASS/FAIL] <assertion statement> — <brief justification>
- ...

出力先。 監査対象のスキルの隣に評価ビューアーを保存し、説明対象の成果物と一緒に保管されるようにします。

<audited_skill_path>/eval_viewer_<skill_name>.md

<audited_skill_path> は、スキルの SKILL.md があるディレクトリ（ユーザーが指定したパス）です。そのディレクトリに書き込めない場合は、/tmp/eval_viewer_<skill_name>.md に保存し、最終レポートでフォールバックしたことを明記します。

ファイルシステムがまったく利用できない場合は、会話内にビューアーを表示します。

レビュアーへの注意： まず ⚠️ と ❌ の行を確認してください。2 件以上の出力にまたがってパターンが見られる場合は、スキルに構造上の問題があることを示しています。

---

ステップ 8：最適化レポート

最終スコアの計算

Final Score = (Static Score × 0.4) + (Execution Avg × 0.6)

→ スコア判定基準の詳細：references/scoring_rubric.md

スコア	評価	推奨事項
85–100	⭐ 本番環境対応	公開してデプロイ
75–84	✅ 限定リリース	スロットルを設けて監視しながら展開
60–74	⚠️ ベータ版のみ	社内利用／グレーリストのみ
< 60	❌ 不採用	デプロイしない

最適化の推奨事項

優先度	基準	対応
P0 — ブロッカー	拒否条件が FAIL、安全性アサーションが FAIL、スコア < 60 のいずれか	いかなるデプロイの前にも必ず修正する
P1 — 重大	スコア 60–74、アサーションの失敗が繰り返される、レイヤー 1 または 2 の平均が 7/10 未満	本番リリース前に修正する
P2 — 軽微	スコア 75–84、出力に個別の弱点がある、スタイル／形式の問題がある	本格展開の前に対処する

見つかった問題ごとに、次を出力します。

[P0/P1/P2] <Issue Title>
  Observed in: Input(s) [N, M, ...]
  Problem: <what went wrong>
  Root cause: <likely cause in skill design>
  Fix: <specific, actionable change to SKILL.md or scripts>

最終レポート

══════════════════════════════════════════════════
SKILL AUDIT REPORT
══════════════════════════════════════════════════
Skill Name     : <n>
Category       : <label>
Execution Mode : <A/B/C/D>
Complexity     : <Simple/Moderate/Complex>  (N=<n> inputs)
Audited On     : <date>

── STEP 1: Structural Veto ───────────────────────
Stability    : PASS / FAIL
Contract     : PASS / FAIL
Determinism  : PASS / FAIL
Security     : PASS / FAIL

── STEP 2: Static Evaluation (25 criteria) ───────
Functional Suitability : __/12
Reliability            : __/12
Performance/Context    : __/8
Agent Usability        : __/16
Human Usability        : __/8
Security               : __/12
Maintainability        : __/12
Agent-Specific         : __/20
Static Subtotal        : __/100

── STEP 3: Classification ────────────────────────
Category       : <label>
Execution Mode : <A / B / C / D>

── STEP 4: Test Inputs ───────────────────────────
[N inputs listed with type labels]

── STEP 5: Execution Summary ─────────────────────
Input 1: [COMPLETED/PARTIAL/ERROR] — <note>
...

── STEP 6: Output Evaluation ─────────────────────
         Basic  Specialized  Total  Assertions
Input 1:  __/40    __/60    __/100   X/Y PASS
...
Execution Avg               : __/100
Total Assertion Pass Rate   : __/__

[Research Veto — Evidence Insight / Protocol Design / Data Analysis / Academic Writing only; N/A for Other]
Scientific Integrity  : PASS / FAIL / N/A
Practice Boundaries   : PASS / FAIL / N/A
Methodological Ground : PASS / FAIL / N/A
Code Usability        : PASS / FAIL / N/A

── STEP 7: Outputs ───────────────────────────────
<audited_skill_path>/eval_viewer_<n>.md          : SAVED ✅
<audited_skill_path>/eval_report_<n>_result.json : SAVED ✅

── STEP 8: Final Score ───────────────────────────
Static Score   : __/100  × 40% = __
Dynamic Score  : __/100  × 60% = __
FINAL SCORE    : __ / 100
GRADE          : ⭐/✅/⚠️/❌  [Production Ready / Limited Release / Beta Only / Reject]

Key Strengths:
- ...

Optimization Recommendations:
[P0] ...
[P1] ...
[P2] ...
══════════════════════════════════════════════════

ステップ 7～8 の JSON 出力

⚠️ スキーマへの厳密な準拠は必須です。 JSON レポートは後続のツール（skill-evaluator、フロントエンドビューアー、自動回帰ダッシュボード）で使用されます。以下のスキーマから少しでも逸脱すると（キー名の変更、フィールドの欠落、オブジェクトが必要な箇所に文字列を使用するなど）、ツールが気付かないまま正常に動作しなくなります。JSON を出力する前に、必ず次を行ってください。

1. references/report_json_schema.md を最初から最後まで（以下の概要表だけでなく）読み直します。
2. スキーマの完全な例から構造をコピーし、値を入力して JSON を作成します。独自のキー名やネスト構造を考案してはいけません。
3. ファイルを書き込む前に、スキーマの「Pre-Emit Checklist」（report_json_schema.md の「Pre-Emit Checklist」節）にあるすべての項目を確認します。未確認の項目は警告ではなく、ブロッカーとして扱います。

特に、以下のような過去の監査で確認された逸脱に注意してください。これらはそれぞれ契約違反になります。

• static_score.subtotal ではなく static_score.total を使用する。
• dynamic_score.execution_avg ではなく dynamic_score.execution_avg_score を使用する。
• veto_gates.research_veto.scientific_integrity: "PASS" のように（値を文字列だけで）記述する。正しくは { "result": "PASS", "detail": "..." } です。
• skill_veto と research_veto 内の最上位の gate フィールドを省略する。
• 入力ごとのキーに index ではなく n を使い、label／status／status_flag／note を省略する。
• 各静的カテゴリの値を { "score": N, "max": M, "note": "..." } ではなく、整数だけで記述する。
• final.score／final.static_weighted／final.dynamic_weighted ではなく、final.final_score／final.weighted_static／final.weighted_dynamic を使用する。
• final.grade_symbol を省略する。

スキーマの例のいずれかの部分が、これから出力しようとしている内容と一致しない場合、例が正準です。スキーマではなく、出力を変更してください。

→ スキーマの詳細と完全な例：references/report_json_schema.md

出力先。 評価ビューアーと同じディレクトリ規則を使用し、JSON を監査対象のスキルの隣に保存します。

<audited_skill_path>/eval_report_<skill_name>_result.json

監査対象のスキルのディレクトリに以前の eval_report_<skill_name>_result.json がすでにある場合は、上書きします。最新の監査結果が以前のものに優先します。そのディレクトリに書き込めない場合は、/tmp/eval_report_<skill_name>_result.json に保存し、最終レポートでフォールバックしたことを明記します。 JSON のトップレベルノード（7 個すべて必須）— 簡略版リマインダー。スキーマファイルが正式な定義です：

ノード	主なルール
meta	evaluator_version: "[email protected]"。skill_name、description、evaluated_on、category、execution_mode、complexity、n_inputs を含みます
veto_gates	skill_veto：トップレベルの gate と stability、contract、determinism、security — T プレフィックスは禁止。research_veto：トップレベルの applicable、gate と 4 つの評価項目。それぞれ { result, detail } — M プレフィックスは禁止
static_score	subtotal、max、categories。8 つのカテゴリキーは、プレフィックスなしで正確に指定します：functional_suitability、reliability、performance_context、agent_usability、human_usability、security、maintainability、agent_specific。各値は { score, max, note } オブジェクトであり、整数値のみの指定は禁止です。
dynamic_score	execution_avg（execution_avg_score ではありません）、max、assertion_pass_rate: { passed, total }、inputs[]。各入力では index（n ではありません）を使用し、label、status、status_flag、note、basic、specialized、total、assertions_passed、assertions_total と、{ text, result, note } オブジェクトの完全な assertions[] 配列を含めます。
final	static_weighted、dynamic_weighted、score（final_score ではありません）、max、grade、grade_symbol、deployable、veto_override
key_strengths	通常の文字列配列。2～5 項目
recommendations	P0 → P1 → P2 の順に並べます。それぞれ priority、title、observed_in、problem、root_cause、fix を含めます

出力前チェックリスト（ファイルを書く前に、以下をすべて必ず確認してください — 完全な一覧は report_json_schema.md § 出力前チェックリストを参照）：

• 自由記述フィールドはすべて英語で記述されている
• JSON キーに T、M、またはカテゴリ番号のプレフィックスがない
• static_score.categories にキーが正確に 8 個あり、各値が { score, max, note } で、すべてのスコアが 0～max の範囲内である
• static_score.subtotal が 8 つすべてのカテゴリの score 値の合計と一致する
• dynamic_score.inputs に正確に N 個のオブジェクトがあり（meta.n_inputs と一致）、各オブジェクトに assertions 配列がある
• 各入力の assertions 配列に 3～5 項目がある (要素数の制約 — 数えて確認してください)
• 各入力の assertions_passed が、その assertions 配列内の "PASS" の数と一致する
• 各入力で basic + specialized = total が成り立つ
• key_strengths に 2～5 項目がある (要素数の制約 — 数えて確認してください)
• カテゴリが Other の場合、research_veto.applicable = false であり、research veto の全フィールドが "N/A" である
• いずれかのゲートが FAIL の場合、final.veto_override = true であり、その場合は final.deployable = false である
• final.grade と final.grade_symbol が、しきい値テーブルに基づく final.score と一致する
• recommendations が P0 → P1 → P2 の順に並んでいる（空の配列も可）
• すべての平均値／加重スコアが小数第 1 位に丸められている。すべての生スコアが整数である

---

入力の検証

このスキルが受け付けるもの：品質監査と改善のために提出された SKILL.md ファイル、またはスキルの説明。

ユーザーのリクエストが、エージェントスキルの監査、評価、採点、または改善に関するものでない場合（例：物語の執筆、ウェブサイトの構築、一般的な質問への回答）は、監査パイプラインを実行しないでください。代わりに、次のように応答してください：

「Skill Auditor は、エージェントスキル（SKILL.md ファイル）の評価と改善を目的としています。ご依頼はこの対象範囲外のようです。監査対象のスキルを提出するか、タスクに適した別のツールをご利用ください。」

言語に関する注意： ユーザーは任意の言語でリクエストやスキルを提出できます。監査結果は常にすべて英語で出力してください。上記の言語ポリシーを参照してください。

---

参照ファイル

ファイル	使用箇所	ゲート？
references/basic_veto.md	Step 1 — 構造上のレッドライン	❌ ハードゲート
references/basic_evaluation.md	Step 2（静的スコアリング）＋ Step 6 Layer 1	—
references/classification.md	Step 3 — 5カテゴリ分類	—
references/specialized_evaluation_literature.md	Step 6 Layer 2 — カテゴリ1	—
references/specialized_evaluation_research_design.md	Step 6 Layer 2 — カテゴリ2	—
references/specialized_evaluation_data_analysis.md	Step 6 Layer 2 — カテゴリ3	—
references/specialized_evaluation_academic_writing.md	Step 6 Layer 2 — カテゴリ4	—
references/specialized_evaluation_other.md	Step 6 Layer 2 — カテゴリ5	—
references/scientific_veto.md	Step 6 Research Veto — カテゴリ1～4のみ	❌ ハードゲート
references/scoring_rubric.md	Step 8 — 最終スコアとデプロイ推奨	—
references/report_json_schema.md	Step 7（データ収集）＋ Step 8（JSON 出力）	—

依存関係

• Python 3.x ＋ 標準ライブラリ — scripts/evaluate_skill.py（構造の事前チェック）用
• Claude — Steps 4～8（入力生成、実行、多層スコアリング、推奨事項）用

---

変更履歴

v1.1.0 — 2026-04-02

Scene Override の追加 — differential-expression-analysis の監査結果に基づき、科学計算＋エージェントファーストのスキルに適用した場合、basic_evaluation.md に3つの体系的なバイアスがあることが特定されました。共有の基本評価基準を変更するのではなく（変更すると5つのカテゴリすべてに影響するため）、該当する専門評価ファイルにカテゴリごとの Scene Override セクションを追加しました。

変更したファイル：

• references/specialized_evaluation_data_analysis.md — Fault Tolerance（2.1）、Forgiveness（5.2）、Recoverability（2.3）を扱う Scene Override セクションを追加
• references/specialized_evaluation_research_design.md — 同じ3つのオーバーライドを、プロトコル設計の文脈に合わせて調整した Scene Override セクションを追加
• references/specialized_evaluation_other.md — スキルがエージェントファーストの Mode B/C/D の文脈で動作する場合に、カテゴリ3のオーバーライドを適用するよう監査担当者に指示する Execution Mode Awareness の注記を追加

理由： 影響を受ける3つの基本評価基準は、（1）人間が CLI を直接操作すること、（2）汎用ソフトウェアツールであることを前提としています。科学計算パイプラインやエージェントファーストのスキルでは、この前提は成り立ちません。そのような環境では、厳格な入力検証と即時停止が適切な設計判断であり、構造化されたエラーコードが適切な復旧インターフェースとなります。