self-healing-ci

自己修復 CI

self-healing の CI 専用版です。プルリクエストおよびスケジュールされたワークフローのイベントに対して、診断 → パッチ適用 → 検証 → 記録のループをヘッドレスで実行します。

インストール

gh skill install pskoett/pskoett-skills self-healing-ci

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

npx skills add pskoett/pskoett-skills/skills/self-healing-ci

目的

対話型チャットのループを使わずに、CI で自己修復を実行します。

• 失敗した PR チェック（テスト／ビルド／Lint／スキャン／デプロイ）を調べ、ログから根本原因を解析します
• 検証済みの最小限のパッチを、PR コメントまたは後続のコミットとして提案します
• 検証の証拠とともに .learnings/HEALS.md に HEAL- エントリをコミットします（ワークフローを再実行してチェックできない場合は pending-verify とします）
• 新しいエントリを記録する前に、Pattern-Key を使って過去の HEAL エントリを検索し、再発を重複排除します
• Recurrence-Count >= 3 の場合は Handoff ブロックを追加し、self-improvement-ci による昇格に備えます

対話型／ローカルのセッションでは、self-healing を使用してください。

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

CI エージェントは、元の実装セッションで得られた最良のタスクコンテキストを利用できません。エージェントが読み取るのは CI ログとコードであり、集中して実装した後の最良のコンテキストを引き継ぐわけではありません。これにより、次の点に注意が必要です。

• 慎重に診断してください。不確かな場合は pending-verify として記録し、PR の作成者に知らせます
• verified とする前に、必ず検証してください。同じワークフロー実行内で失敗したチェックを再実行します
• 明示的な検証に合格していない限り、プロジェクトコードを変更しないでください。ワークフローが自動コミット用に設定されていない場合は、変更を PR コメントとして提案します
• 不確実な推奨事項や影響の大きい推奨事項は、対話型レビューに回します

前提条件

1. リポジトリで GitHub Actions が有効になっていること
2. ワークフロー内で GitHub CLI が認証されていること（gh auth status）
3. 作成／検証用に gh-aw がインストールされていること：

gh extension install github/gh-aw

4. .learnings/HEALS.md がリポジトリにコミットされていること（または初回実行時に作成されること。初期設定のパターンについては references/workflow-example.md を参照してください）

CI の契約

CI スキルでは、次のことを必ず実行します。

1. CI ログ、PR の差分、既存の .learnings/HEALS.md を読み取ります。PR 作成者のマシンから取得する情報はこれ以外にありません
2. 既定ではコードを直接変更しません。PR コメントまたはラベルで制御されたコミットを使って提案します
3. （可能な場合は）提案したパッチの適用後に失敗したチェックを再実行します。verified とするには再実行が必須です。再実行できない場合は、正直に pending-verify とします
4. 機械可読な YAML 出力を生成します（出力スキーマを参照）
5. 再実行に成功した場合にのみ、検証済みの HEAL- エントリをコミットします。中止された修復も記録しますが、別のコミットに分け、中止されたことが明確にわかるようにします

出力スキーマ

self_healing_ci:
  source:
    pr_number: 123
    commit_sha: "abc123def"
    failed_check: "test (node 20)"
    workflow_run_id: 4567891234
  heal:
    heal_id: "HEAL-20260524-001"
    status: "verified"            # verified | pending-verify | abandoned
    trigger: "tool-failure"       # free-form
    active_context: "ci"          # optional
    area: "tests"                 # free-form
    pattern_key: "env.lockfile_mismatch"
    diagnosis: "Project uses pnpm; CI workflow ran `npm ci`."
    fix:
      summary: "Switch the CI install step from `npm ci` to `pnpm install --frozen-lockfile`."
      diff_path: ".learnings/heals/HEAL-20260524-001/patch.diff"   # only if files generated
    verification:
      command: "pnpm install --frozen-lockfile"
      exit_code: 0
      output_excerpt: "Lockfile is up to date, resolution step is skipped"
    recurrence_count: 1
    promotion_ready: false        # true at recurrence_count >= 3
  summary:
    heals_filed: 1
    verified: 1
    pending_verify: 0
    abandoned: 0
    promotion_candidates: 0

CI での永続化前検証

CI では、検証ステップとして、提案したパッチを適用した後、同じワークフロー実行内で失敗したチェックを再実行することを必須とします。

元の失敗	CI での検証ステップ
pnpm test の失敗	パッチ適用後に pnpm test を再実行します
ビルド（tsc、cargo build）の失敗	ビルドステップを再実行します
Lint（eslint、ruff）の失敗	Lint ステップを再実行します
デプロイプレビューの失敗	（ワークフローで許可されている場合）デプロイステップを再実行します
スナップショットの差分	該当する場合は、決定論的なスタブを使用して再実行します

再実行が現実的でない場合（チェックに本番ワークフローでのみ利用できるシークレットが必要な場合、失敗が一時的な場合、またはコミット前にパッチを人間がレビューする必要がある場合）、HEAL は pending-verify として記録し、何を確認すれば検証できるかを明記します。

verified を偽装してはいけません。 偽装こそ、このスキルが防ごうとしている失敗そのものです。CI では、対話型セッションよりも影響が広がります。今後の PR が、未検証の「修正」を自動的に適用する可能性があるためです。

再発と昇格のルール

• 新しいヒールを登録する前に、Pattern-Key で .learnings/HEALS.md を検索します
• 一致した場合：Recurrence-Count を増やし、Last-Seen を更新して、新しい発生を See Also に追記します
• 昇格のしきい値（対話型と同じ）：
  • Recurrence-Count >= 3
  • 2 件以上の異なる PR／タスクで確認されている
  • 30 日以内
  • 修正が一般化可能である（プロジェクト固有ではない）
• 昇格時：既存の HEAL に Handoff ブロックを追記し、Promotion Target（CLAUDE.md / AGENTS.md / .github/copilot-instructions.md / new-skill）と 1 行の Distilled Rule を記載します
• self-improvement-ci は Handoff ブロックを読み込み、昇格を PR として提案します

推奨ワークフロートリガー

トリガー	ユースケース
workflow_run（completed、conclusion: failure）	最も一般的。他のワークフローの失敗に対応します
pull_request（チェック状態に対する if: ガード付き）	すべての PR で実行し、すべてのチェックが成功した場合はスキップします
schedule（夜間）	古いフレークを探し、PR ごとの実行で見逃したパターンを見つけます
workflow_dispatch	特定の PR またはコミットに対して手動で再実行します

作成パターンと .github/workflows/*.lock.yml の例は、references/workflow-example.md にあります。CI 自動化を有効にすると明示的に決めるまでは、サンプルのワークフローを .github/workflows に置かないでください。

CI におけるアンチパターン

対話型スキルのアンチパターンはすべて当てはまります。CI 固有の注意点は次のとおりです。

1. 未検証の修正を自動コミットする。 再実行チェックに合格していないパッチを、ブランチに自動で取り込んではいけません。代わりに PR のコメントで提案してください。
2. 再トリガーのループ。 ヒールが自身のワークフローをトリガーする場合は、無限ループを防ぐために if: github.actor != 'github-actions[bot]' で制御します。
3. 不安定なテストを黙って再試行する。 不安定なテストは、パッチが非決定性に実際に対処していない限り、ヒールの候補ではありません。同じ不安定なテストを成功するまで再実行するのは、修復ではなく隠蔽です。
4. PR 間での Pattern-Key の衝突。 2 件の PR で同じ Pattern-Key に異なる根本原因が該当する場合、キーの粒度が粗すぎます。統合するのではなく、キーを細分化してください。
5. 所有していないインフラへのヒール。 CI 内からサードパーティ製アクションのソースにパッチを適用しないでください。代わりに、バージョンの固定または設定の変更を提案してください。

相互参照

• self-healing — これを反映した対話型スキル。同じファイル形式、同じ検証方針です
• self-improvement-ci — ヒールの Handoff ブロックを受け取り、メモリファイルへの昇格を提案します
• simplify-and-harden-ci — ヒールによって PR が安定した後の品質確認です
• verify-gate — 対話型の検証ゲートです。self-healing-ci の検証は CI ワークフローの再実行です
• references/workflow-example.md — gh-aw ワークフローテンプレートと作成上の注意