heyeddi-ci-config

HeyEddi CI Config

HeyEddi Reviewer／任意の Spot ランナー向けに、正しい eddi-ci.yaml を作成します。記憶を頼りに設定項目をでっち上げないでください。

安全性

• 現在のターンでマージを承認していない PR は、決してマージしないでください。auto_merge は決して記述しないでください
• 課金対象の設定項目と、封印された Spot pipeline ジョブには明示的なオプトインが必要です
• 作成前に必ず load_policy_contract を実行してください
• Spot は提供中です。ワークスペースが利用資格を持つ場合、ジョブを実行できます。Check／Spot の証拠（@heyeddi-ci-runners）なしに、ジョブが実行されたと決して断言しないでください
• .github/workflows/ がすでに CI を管理している場合は、封印された pipeline: よりも GHA ＋ワークスペースランナーモードを優先してください。二重実行を避けるため、pipeline: {} にしてください

ナレッジルール（必須）

スキルパッケージには設定項目の完全な一覧は含まれていません。実行のたびに：

1. load_policy_contract（または python …/scripts/load_policy_contract.py）を実行します。
2. 返された guide、knobs、rules、minimal_example を権威ある情報として扱います。
3. 説明文には、人間向けドキュメントの docs_url（既定値 https://ci.heyeddi.com/docs#policy）を優先します。
4. 古くならない恒久的な安全ルールについては、context/ANTI_PATTERNS.md を読みます。

契約フィード（本番環境）：https://cihook.heyeddi.com/api/public/eddi-ci-policy

スクリプト内のフォールバック順：ローカルの heyeddi-ci チェックアウト → HEYEDDI_CI_POLICY_URL／本番 API → ドキュメントページのテキスト。

判断ゲート：ファイルを追加するかどうか（必須）

eddi-ci.yaml がないことは不具合ではありません。安全な既定値がすでに適用されています（ランナーはオフ、on_ci_failure はオフ）。何かを書く前に判断してください。

次のいずれかに該当する場合に限り、eddi-ci.yaml を書く／作成する

• ユーザーが eddi-ci.yaml の作成、追加、設定を明示的に依頼している
• inspect_repo が heyeddi_product.uses_heyeddi_product: true を返す — リポジトリがすでに HeyEddi 製品を使用しています（以下のシグナルを参照）。その場合、ユーザーが断らない限り、Reviewer のみを対象とした安全なファイル（課金対象の設定項目はオフ、pipeline: {}）を追加します
• ユーザーが既定値を超える Reviewer ポリシー（例：allow_external_prs、より大きな validation_max_attempts、チームルールの文書化）を求めている
• ユーザーが封印された Spot pipeline: ジョブ（GHA なし／最小限の GHA、または特定用途のチェック）を求め、実際のコマンドとパスフィルターを了承している — @heyeddi-ci-runners を参照
• ユーザーがSpot 上の GHAを求めている — それでも Reviewer のみを対象とする YAML（pipeline: {}）を記述し、HEYEDDI_RUNS_ON フックとワークスペースの Runners モードを案内します（@heyeddi-ci-runners）
• ユーザーが HeyEddi の PR CTA に従っており、今すぐ設定したいと確認している（CTA だけでは自動的に作成しません。意図が不明な場合は一度確認してください）

HeyEddi 製品のシグナル（inspect_repo → heyeddi_product.evidence から取得）：

• .heyeddi/ ワークスペースが存在する
• .agents/skills/heyeddi-* がインストールされている
• skills-lock.json に HeyEddi-com/heyeddi-skills が固定されている（旧形式の HeyEddi-com/skills も該当します）
• PRODUCT.md／.heyeddi/product.md／README.md／パッケージの識別情報に HeyEddi の記載がある

次の場合はファイルを作成しない

• 唯一のシグナルが「ファイルがない」ことであり、HeyEddi 製品を示すマーカーもない
• ユーザーが通常のコードレビューだけを求めており、設定を選択していない／HeyEddi プロジェクトではない
• 既定値はすでに安全であると説明した後に、ユーザーが断っている
• pipeline を埋めるためにテストコマンドやパスフィルターをでっち上げる必要がある（それでも、pipeline ジョブなしの Reviewer のみを対象とした YAML を追加するのは問題ありません）

追加しない場合

簡潔に説明します。HeyEddi はすでに安全な既定値で動作しており、ポリシーやランナーが必要になったときに @heyeddi-ci-config を呼び出せます。ここで終了してください。ファイルは書かないでください。

既存ファイルを更新する場合

ユーザーがポリシー／ランナーの変更を依頼した場合、またはコミット済みの無効な YAML を修正する場合に限り編集します。ユーザーに求められていないのに、変更されていない有効な設定を「改善」しないでください。

このスキルを使用する場合

• 上記の「書く／作成する」条件のいずれかに該当する場合
• ユーザーが eddi-ci.yaml の仕組みを尋ねた場合（契約を読み込んで説明し、その後ユーザーがオプトインした場合に限り作成します）

使用しない場合

ファイルがないという理由だけで、設定の追加作業をでっち上げないでください。

手順

1. inspect_repo を実行し、判定ゲート（heyeddi_product を含む）を適用します。追加しない場合は、その理由を説明して終了します。
2. HeyEddi 製品が検出されたために追加する場合は、安全な YAML として Reviewer 専用をデフォルトにします。シールされた pipeline または on_ci_failure を有効にする前に確認してください。
3. それ以外の理由で追加または更新する場合は、意図を確認します。Reviewer 専用ポリシー、GHA-on-Spot、シールされた pipeline、または両方（Reviewer ＋シールされたもの）のいずれかを確認してください。
4. load_policy_contract を使って、最新のコントラクトを読み込みます。
5. .github/workflows/ が存在し、ユーザーが Spot での CI を希望する場合は、pipeline: {} を維持し、HEYEDDI_RUNS_ON フックを確実に設定し、モードの設定は @heyeddi-ci-runners ／ワークスペースの Settings に委ねます。
6. シールされた pipeline が対象となる場合は、リポジトリの調査を完了し、言語と実際のテストコマンドを確認します。根拠なしに pytest ／ npm test を指定しないでください。
7. コントラクトに照らして課金対象の設定を確認します。ユーザーが明示的に有効化を選択しない限り、ai_review.on_ci_failure は false のままにします。シールされたランナーを使用する意図があり、コマンドが判明していて、GHA と重複しない場合に限り、pipeline ジョブを追加します。
8. コントラクトの knobs にあるキーのみを使って、リポジトリのルートに eddi-ci.yaml を書き込みます。
9. シールされたランナーが要求され、パスフィルターが判明している場合を除き、空の pipeline: {} を優先します。
10. ユーザーにコミットとプッシュを促します。PR でファイルが変更されると、HeyEddi App がそのファイルを lint します。実行に関する主張には、後で Check の証拠が必要です。

ツール

ツール	用途
load_policy_contract	最新の knobs ／ガイド／ルール／例を取得します
inspect_repo	HeyEddi 製品の検出と、言語／テストコマンド候補の確認

例

Reviewer 専用（安全／GHA リポジトリ）

コントラクトを読み込んだ後、課金対象の knobs をオフにし、pipeline: {} を指定したコントラクトの minimal_example（または同等のもの）を記述します。

要求された場合のシールされたランナー（GHA なし）

inspect_repo で実際のコマンドとパスのプレフィックスが確認できた場合に限り、filter.paths を指定して pipeline ジョブを追加します。明示的なオプトインなしに on_ci_failure を有効にしないでください。既存のワークフロージョブをミラーリングしないでください。

注意事項

• トップレベルの不明なキーは、スキーマで拒否されます（extra=forbid）。
• 無効な YAML の場合、App はファイルを無視し、安全なデフォルトを使用します。
• 形式については context/EXAMPLES.md を参照してください。knobs は必ず load_policy_contract で再確認してください。
• GHA のオーバーフローとシールされた pipeline のどちらを選ぶかについては、@heyeddi-ci-runners に確認してください。