/self-healing-ci

name: self-healing-ci
description: "CI-only self-healing workflow using gh-aw (GitHub Agentic Workflows) for active runtime recovery on pull requests and scheduled runs. When a CI check fails (test, build, lint, deploy, scan), this skill diagnoses the failure from CI logs, proposes a verified patch as a PR comment or follow-up commit, and commits a HEAL entry to `.learnings/HEALS.md`. Verify-before-persist discipline preserved: a HEAL is only `verified` if a re-run check passes in the same workflow; otherwise it ships as `pending-verify` for human follow-up. Recurrent heal patterns across PRs accumulate `Recurrence-Count` and append a `Handoff` block at ≥3 to flag promotion via self-improvement-ci. Use this skill when: you want headless heal-loop execution in CI/scheduled pipelines, you want recurring failure patterns captured automatically, or you want PRs that surface non-obvious environmental / tooling fixes without human triage. For interactive/local sessions, use `self-healing` instead."

Self-Healing CI

CI-only variant of [`self-healing`](../self-healing/SKILL.md). Runs the diagnose → patch → verify → file loop headlessly against pull-request and scheduled workflow events.

Install

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

Fallback using the Agent Skills CLI:

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

Purpose

Run self-healing in CI without interactive chat loops:

• Inspect failed PR checks (test/build/lint/scan/deploy) and parse logs for root cause
• Propose a minimal verified patch as a PR comment or follow-up commit
• Commit a `HEAL-` entry to `.learnings/HEALS.md` with verification proof (or `pending-verify` if the workflow can't re-run the check)
• Search prior HEAL entries by `Pattern-Key` before filing new ones — deduplicate recurrences
• Append a `Handoff` block at `Recurrence-Count >= 3` for promotion via `self-improvement-ci`

Use [`self-healing`](../self-healing/SKILL.md) for interactive/local sessions.

Context Limitation (Important)

CI agents do **not** have peak task context from the original implementation session. The agent is reading CI logs and code, not riding peak context after a focused implementation. Implications:

• Favor **conservative diagnoses** — when uncertain, file `pending-verify` and surface to the PR author
• Require **mandatory verify** before claiming `verified` — re-run the failing check in the same workflow run
• Never modify project code without an explicit verify pass; propose changes as PR comments unless the workflow is configured for auto-commit
• Route uncertain or high-impact recommendations to interactive review

Prerequisites

1. GitHub Actions enabled for the repository 2. GitHub CLI authenticated in the workflow (`gh auth status`) 3. `gh-aw` installed for authoring/validation:

gh extension install github/gh-aw

4. `.learnings/HEALS.md` committed to the repo (or created on first run; see `references/workflow-example.md` for the bootstrap pattern)

CI Contract

The CI skill must:

1. Read CI logs, PR diff, and existing `.learnings/HEALS.md` — nothing else from the PR author's machine 2. Avoid direct code modifications by default — propose via PR comment or label-gated commit 3. Re-run the failing check after applying the proposed patch (when feasible) — `verified` requires this; `pending-verify` is honest if it cannot 4. Emit a machine-readable YAML output (see Output Schema) 5. Commit the verified `HEAL-` entry only on a successful re-run — abandoned heals are still filed, but in a separate commit clearly labeled

Output Schema

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

Verify-Before-Persist in CI

In CI the verify step is operationalized as **re-running the failed check inside the same workflow run** after applying the proposed patch:

| Original failure | Verify step in CI | |------------------|-------------------| | `pnpm test` failed | Re-run `pnpm test` after the patch | | Build (`tsc`, `cargo build`) failed | Re-run the build step | | Lint (`eslint`, `ruff`) failed | Re-run the lint step | | Deploy preview failed | Re-run the deploy step (if the workflow allows) | | Snapshot diff | Re-run with deterministic stubs if applicable |

If the re-run isn't feasible (the check requires secrets only available in production workflows; the failure is transient; the patch needs human review before commit), the HEAL ships as `pending-verify` with explicit notes on what would prove it.

**Never fake `verified`.** Faking is the exact failure mode this skill exists to prevent — and in CI, the consequences propagate further than in interactive sessions because future PRs may apply the unverified "fix" automatically.

Recurrence and Promotion Rules

• Search `.learnings/HEALS.md` by `Pattern-Key` before filing new heals
• On match: increment `Recurrence-Count`, update `Last-Seen`, append the new occurrence to See Also
• Promotion th