evals-analyze

evals-analyze

このスキルの機能

EDD Principle VIII（本番環境のループを閉じる）に基づき、失敗した軌跡のトレースを詳細に分析し、適切な解決経路に振り分けることで、部門横断的なチームの能力向上とクローズドループのフィードバックを実現します。

出力：

1. 軌跡の分析 - ツール呼び出しとコンテキストの保持を含む、複数ターンにわたるトレースの完全な分析（EDD Principle V）
2. 失敗の振り分け：
   • 仕様の不備（エージェントのロジックが不足または曖昧）→ 詳細に分類（EVAL-010）：
     • 機械的な不備（固定され、チェック可能なパターン）→ 既存のグレーダーを修正・拡張するか、ユニットテストを追加します。これは決定論的なチェックであり、CDRではありません
     • 判断の不足（意図の欠如、曖昧さ、コンテキストが必要）→ adlc branch drafts/cdr/ に新しいコンテキストルールを提案するため、team-levelup のローカル呼び出しを自動的に実行し、エージェントの動作を修正します
   • 汎化の不備（グレーダーに不備がある、またはエッジケースの網羅性が不足）→ 継続的な監視のため、評価者のバックログ項目をプロジェクトのバックログに追加します。
3. 部門横断的な PR - インサイトとルールの更新を含む team-ai-directives の PR を作成します（EDD Principle X）

適用する主な EDD 原則：

• Principle VIII：本番環境のループを閉じる - 仕様の不備 → ディレクティブを修正、汎化の不備 → 評価者のバックログに追加
• Principle V：軌跡の可観測性 - 出力だけでなく、複数ターンにわたるトレースを完全に確認
• Principle X：部門横断的な可観測性 - PM、ドメインエキスパート、AI エンジニアが協力

使用するタイミング

• /evals-validate の後：失敗を分析して解決します
• 開発ループを閉じるとき：評価の失敗から得られたインサイトをルールまたは評価者の修正に反映します
• ステークホルダーに報告するとき：PM やドメインエキスパート向けに、読みやすい要約を作成します

使用しないタイミング

• 評価がまだ実行されていない場合：まず /evals-validate を実行して、evals/results/ に結果を生成します
• 単純なタスクの場合：単純な機能では、クローズドループ分析は余分な作業になります

プロセス

ユーザー入力

$ARGUMENTS

• --focus AREA — 特定の領域（セキュリティ、品質、パフォーマンスなど）に分析対象を絞ります
• --dry-run — 結果を分析してレポートを出力しますが、PR の作成とローカルスキルの実行はスキップします

実行手順

フェーズ 1：評価結果の読み込み

• evals/results/ から結果 JSON を読み込みます。
• 失敗ケースと、ツール呼び出しを含む複数ターンの会話トレース全体を抽出します。

フェーズ 2：失敗の分類

各失敗トレースを分類します。

• 仕様の不備：エージェントはコンテキストに照らして正しく動作しましたが、ルールやディレクティブが不足していた、曖昧だった、または誤っていました。詳細に分類します（EVAL-010）：
  • 機械的な不備：固定され、チェック可能なパターン（禁止 API、インポート形式、ファイルの配置場所、構文形式）に関する不足 → 決定論的なチェックで対処
  • 判断の不足：不足を解消するには、意図、コンテキスト、またはファイル横断的な判断が必要 → コンテキストルールで対処
• 汎化の不備：ルールは正しかったものの、エージェントが誤りを犯しました（ハルシネーション、制約の見落とし、またはグレーダーによるエッジケースの網羅性不足）。

フェーズ 3：対応の振り分け（ループを閉じる）

• 機械的な仕様の不備の場合：既存の二値グレーダーを修正・拡張するか、そのパターンを適用するユニットテストを追加します。機械的にチェック可能な不足に対して CDR を提案してはいけません。セッションごとに再導出するのではなく、チェックに一度だけコストをかけます。
• 判断の不足による仕様の不備の場合：失敗トレースを入力として、ローカルスキル /team-levelup を自動的に実行します。これにより、エージェントの動作を修正するための新しいルール、ペルソナ、例の CDR が adlc branch drafts/cdr/ に作成されます。
• 汎化の不備の場合：必要なグレーダーのエッジケース更新の詳細を記載した評価者のバックログ項目を evals/results/evaluator_backlog.md に追加します。

フェーズ 4：部門横断的な分析と PR

• ステークホルダーごとに調整されたレポートを evals/results/team_insights.md に生成します（PM、ドメインエキスパート、AI エンジニア向け）。
• git remote と gh CLI が利用可能な場合、team-ai-directives 内のルール／評価の変更をコミットし、ドラフト PR を作成します（内部では team-levelup のロジックを使用します）。

検証

• 軌跡の失敗トレースを分析し、分類しました
• 機械的な仕様の失敗はグレーダー／ユニットテストの修正に割り当て（決定論的なチェック）、判断のギャップによる失敗は /team-levelup に割り当て（adlc branch drafts/cdr/ に CDR を提案）
• 汎化の失敗を evals/results/evaluator_backlog.md に記録しました
• ステークホルダーレポート evals/results/team_insights.md を生成しました
• ドラフト PR を team-ai-directives に作成しました（該当する場合）
• PR リンクとバックログの詳細を含む最終レポートの概要を提示しました