eval-creator-ci

Eval Creator CI

インストール

gh skill install pskoett/pskoett-skills eval-creator-ci

対話型セッションでは、次を使用します。

gh skill install pskoett/pskoett-skills eval-creator

Agent Skills CLI を使用する場合の代替手段：

npx skills add pskoett/pskoett-skills/skills/eval-creator-ci
npx skills add pskoett/pskoett-skills/skills/eval-creator

目的

CI で外側のループの回帰テストステップを実行します。.evals/ 内のすべての評価ケースを実行し、合格／不合格の結果を報告します。また、回帰があった場合にマージをブロックするよう設定することもできます。learning-aggregator-ci によってフラグが付けられた昇格候補から、新しい評価ケースを作成することもできます。

対話型の eval-creator スキルは、ユーザーがセッション中に評価を作成し、すぐにフィードバックを得ながら実行するために設計されています。この CI 版は、スケジュールまたは PR ごとに実行され、チェック注釈として結果を投稿します。

コンテキストの制限（重要）

CI エージェントには実装のコンテキストがありません。評価ケースファイルで定義された機械的な検証方法（grep チェック、コマンドチェック、ファイルチェック、ルールチェック）を実行します。結果について合格／不合格を超える解釈は行わず、細かな判断は投稿されたレポートを確認する人間に委ねられます。

前提条件

• リポジトリで GitHub Actions が有効になっていること
• gh CLI がリポジトリへのアクセス権を持つアカウントで認証されていること
• gh-aw 拡張機能がインストールされていること（gh extension install github/gh-aw、v0.40.1 以降）
• 評価ケースが入った .evals/ ディレクトリがあること（eval-creator または eval-creator-ci で作成）
• 評価ケースのインデックスである .evals/EVAL_INDEX.md があること

CI の契約

ヘッドレス実行に関する厳守事項：

1. 評価の実行はコードに対して読み取り専用 — 評価ケースはファイルを読み取り、チェックコマンドを実行しますが、ソースコードは変更しません
2. 評価ケースの作成先は .evals/ のみ — 昇格候補から新しい評価を作成する場合
3. ヘッドレス — 対話型プロンプトや承認ゲートはありません
4. 構造化出力 — eval_creator_ci キーの下に YAML 形式で結果を出力します
5. ゲートポリシー — 評価の回帰があった場合にチェック実行を失敗させることができます（設定可能）
6. 単一コメント — 実行ごとに結果をまとめたコメントを 1 つ投稿します

作成ワークフロー（gh-aw）

1. references/workflow-example.md を .github/workflows/eval-creator-ci.md にコピーします
2. トリガーとゲートポリシーをカスタマイズします
3. 検証します：gh aw compile（セキュリティスキャンを行うには --actionlint --zizmor を追加します）
4. プッシュして有効にします

永続化と連携

• cache-memory: は、評価の実行履歴（最終実行日、結果の推移）を実行間で保持します。変更されていない評価の再実行を避けられます。
• workflow_call: は作成モードで、learning-aggregator-ci から call-workflow を介してトリガーされます。ワークフロー入力として昇格候補を受け取ります。
• upload-artifact: は、後続処理で利用できるよう評価結果の YAML を保持します。

ワークフロールール

CI エージェントは、次のルールに順番に従います。

モード：評価の実行（デフォルト）

1. .evals/EVAL_INDEX.md を読み、すべての評価ケースの一覧を取得します
2. .evals/cases/ 内の各評価ケースファイルについて： a. 評価ケースのメタデータと検証方法を読みます b. 前提条件を確認します — 満たされていない場合は skip として記録します c. 検証方法を実行します：
   • grep-check：対象ファイルをパターン検索し、期待値（found/not_found）と比較します
   • command-check：コマンドを実行し、終了コードや出力を確認します
   • file-check：ファイルまたはセクションが存在することを確認します
   • rule-check：対象ファイルを読み、期待される内容を検索します d. 結果を期待される結果と比較します e. 合格／不合格／スキップを記録します
3. 各ケースの last-run 日付と last-result で .evals/EVAL_INDEX.md を更新します
4. eval_creator_ci キーの下に構造化 YAML を出力します
5. 結果の概要を PR コメントまたはチェック注釈として投稿します
6. ゲートポリシーが有効で、評価が 1 つでも失敗した場合：チェック実行を失敗させます

モード：評価の作成（昇格候補から）

1. 最新の learning-aggregator-ci 実行による learning_aggregator_ci アーティファクトまたはギャップレポートを読みます
2. eval_candidate: true となっている、昇格可能な各パターンについて： a. パターンの種類に基づいて適切な検証方法を決定します b. 適切なフロントマターを付けて、.evals/cases/ に評価ケースファイルを作成します c. .evals/EVAL_INDEX.md にエントリーを追加します
3. （書き込み権限で実行している場合）新しい評価ケースをコミットします
4. 作成した評価を出力で報告します

出力スキーマ

eval_creator_ci:
  version: "0.1.0"
  source:
    run_id: "<workflow run ID>"
    trigger: "pull_request | schedule | workflow_dispatch"
    run_date: "YYYY-MM-DD"
  mode: "run | create | both"
  run_results:
    total: 12
    passed: 10
    failed: 1
    skipped: 1
    failures:
      - id: "eval-20260301-001"
        pattern_key: "harden.input_validation"
        rule_summary: "Always validate external inputs"
        expected: "not_found"
        actual: "found"
        target: "src/api/handler.ts"
        recovery_action: "Add input validation to new handler endpoint"
    skips:
      - id: "eval-20260315-003"
        reason: "Precondition not met: project does not use TypeScript"
  create_results:
    created: 2
    cases:
      - id: "eval-20260411-001"
        pattern_key: "simplify.dead_code"
        verification_method: "grep-check"
        source_learning: "LRN-20260301-001"
      - id: "eval-20260411-002"
        pattern_key: "harden.authorization"
        verification_method: "rule-check"
        source_learning: "LRN-20260315-003"
  summary:
    regressions: 1
    new_evals_created: 2
    gate_result: "fail"
    followup_required: true

推奨される出力

出力	配置先	内容
評価結果	PR コメントまたはチェック注釈	失敗の詳細を含む合格／不合格の概要
YAML アーティファクト	ワークフローアーティファクト	機械可読な eval_creator_ci ペイロード
チェックステータス	チェック実行	ゲートポリシーに基づく合格または不合格
新しい評価ファイル	.evals/cases/（作成モードの場合）	評価ケースの Markdown ファイル

ゲートポリシー

ブロック動作を設定します。

ポリシー	動作
strict	評価の失敗が1つでもあれば、チェック実行をブロックします
advisory	失敗を報告しますが、ブロックはしません
critical-only	critical または high の重大度パターンに該当する評価のみブロックします

デフォルト：advisory（報告しますが、ブロックはしません）。評価カバレッジが安定したら、チームは strict に引き上げることを推奨します。

トリガーの設定

推奨：PR ごと＋週次スケジュール

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
  schedule:
    - cron: '0 10 * * 1'  # Monday 10am UTC (after learning-aggregator-ci)
  workflow_dispatch:

PR ごとの実行で、マージ前にリグレッションを検出できます。週次実行では、ハーネス自体のドリフトを検出できます。プロモーションによる新しい評価を利用できるよう、learning-aggregator-ci の後にスケジュールします。

他のスキルとの連携

上流（入力元）

• eval-creator（対話型）— 評価ケースを手動で作成します
• learning-aggregator-ci — eval_candidate: true を含むプロモーション候補を生成します
• self-improvement（対話型）— 人による承認を受けたプロモーションの後、評価候補にフラグを付けます

下流（出力先）

• self-improvement / self-improvement-ci — リグレッションの失敗は .learnings/ の新しいエラーエントリになります
• 人によるレビュー — チームでのトリアージ用に失敗レポートを投稿します
• PR マージゲート — リグレッション時にマージをブロックできます（設定可能）

データフロー

learning-aggregator-ci → promotion candidates (eval_candidate: true)
                              ↓
                    eval-creator-ci (create mode)
                              ↓
                         .evals/cases/
                              ↓
                    eval-creator-ci (run mode, per-PR)
                              ↓
                    pass/fail report → PR comment + check annotation
                              ↓
                    regression failures → self-improvement-ci → .learnings/

対話型バージョンとの違い

項目	対話型（eval-creator）	CI（eval-creator-ci）
トリガー	手動で実行	PR イベント、cron スケジュール、workflow_dispatch
評価の作成	ユーザー主導で、すぐにフィードバックを取得	learning-aggregator-ci の候補から自動作成
評価の実行	セッション内でインライン結果を表示	ヘッドレスで実行し、PR コメントに出力
人とのやり取り	ユーザーが結果をインラインでレビュー	GitHub 経由で非同期レビュー
ゲートの動作	ブロックなし — 情報提供のみ	設定可能：advisory、critical-only、strict
ファイルの変更	評価ケースのメタデータを更新	評価インデックスを更新し、新しいケースを作成（作成モードの場合）