MCPInstall

self-healing-ci

by pskoettDevOps & Cloud

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.

Installs
43
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/pskoett/pskoett-ai-skills --skill self-healing-ci
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads self-healing-ci automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Self-Healing CI

CI-only variant of self-healing. 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 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
  1. .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 failureVerify step in CI
pnpm test failedRe-run pnpm test after the patch
Build (tsc, cargo build) failedRe-run the build step
Lint (eslint, ruff) failedRe-run the lint step
Deploy preview failedRe-run the deploy step (if the workflow allows)
Snapshot diffRe-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 threshold (same as interactive):
    • Recurrence-Count >= 3
    • Seen across at least 2 distinct PRs/tasks
    • Within a 30-day window
    • The fix is generalizable (not project-specific)
  • On promotion: append a Handoff block to the existing HEAL with a Promotion Target (CLAUDE.md / AGENTS.md / .github/copilot-instructions.md / new-skill) and a one-line Distilled Rule
  • self-improvement-ci consumes the Handoff blocks and proposes the promotion as a PR

Suggested Workflow Triggers

TriggerUse case
workflow_run (completed, conclusion: failure)Most common — react to other workflows failing
pull_request (with if: guard on check status)Run on every PR but skip if all checks passed
schedule (nightly)Look for stale flakes, surface patterns the per-PR runs missed
workflow_dispatchManual replay against a specific PR or commit

Authoring patterns and example .github/workflows/*.lock.yml files live in references/workflow-example.md. Keep example workflows out of .github/workflows until you've explicitly decided to enable CI automation.

Anti-Patterns in CI

The interactive skill's anti-patterns all apply. CI-specific ones to watch:

  1. Auto-commit unverified fixes. A patch that hasn't passed the re-run check should never land on the branch automatically. Propose via PR comment instead.
  2. Re-trigger loops. If the heal triggers its own workflow, gate with if: github.actor != 'github-actions[bot]' to prevent infinite loops.
  3. Silent retry of flaky tests. A flaky test is not a heal candidate unless the patch actually addresses the non-determinism. Re-running the same flaky test until green is hiding, not healing.
  4. Cross-PR Pattern-Key collisions. If two PRs hit the same Pattern-Key with different root causes, the keys are too coarse — refine them rather than letting them merge.
  5. Heals on infra you don't own. Don't patch a third-party action's source from inside CI — propose a version pin or a configuration change instead.

Cross-references

  • self-healing — the interactive skill this mirrors; same file format, same verify discipline
  • self-improvement-ci — receives heal Handoff blocks; proposes promotion to memory files
  • simplify-and-harden-ci — quality pass after heals stabilize the PR
  • verify-gate — the interactive verify gate; self-healing-ci's verify is the CI workflow re-run
  • references/workflow-example.md — gh-aw workflow templates and authoring notes

FAQ

What does the self-healing-ci skill do?

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.

How do I install self-healing-ci?

Run npx skills add https://github.com/pskoett/pskoett-ai-skills --skill self-healing-ci in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/self-healing-ci/ (personal) or .claude/skills/self-healing-ci/ (project).

Which AI agents can use self-healing-ci?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is self-healing-ci safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains self-healing-ci?

It is published by pskoett in pskoett/pskoett-ai-skills. It has 43 recorded installs.

More from pskoett/pskoett-ai-skills

View all →

self-improvement

pskoett/pskoett-ai-skills

Captures learnings, errors, corrections, and feature requests to enable continuous improvement. Use when: (1) User corrects Claude ('No, that's wrong...', 'Actually...'), (2) User requests a capability that doesn't exist, (3) Claude realizes its knowledge is outdated or incorrect, (4) A better approach is discovered for a recurring task, (5) Receiving a Handoff block from self-healing (a recurring verified heal with Recurrence-Count at least 3) to distill into a memory file or new skill. For ACTIVE runtime failures where the agent needs to apply and verify a fix mid-task, use self-healing instead (it files HEAL- entries with proof; self-improvement promotes accumulated patterns). Also review learnings before major tasks. For CI-only/headless learning capture, use self-improvement-ci.

DevOps & Cloud2K installs

self-improvement-ci

pskoett/pskoett-ai-skills

CI-only self-improvement workflow using gh-aw (GitHub Agentic Workflows). Captures recurring failure patterns and quality signals from pull request checks, emits structured learning candidates, and proposes durable prevention rules without interactive prompts. Use when: you want automated learning capture in CI/headless pipelines.

DevOps & Cloud545 installs

simplify-and-harden

pskoett/pskoett-ai-skills

Post-completion self-review for coding agents that runs simplify, harden, re-verification, and micro-documentation passes on non-trivial code or high-impact configuration changes. Use when a task is complete in a general agent session and you want a bounded quality and security sweep before signaling done. For CI pipeline execution, use simplify-and-harden-ci.

DevOps & Cloud535 installs

agent-teams-simplify-and-harden

pskoett/pskoett-ai-skills

Implementation + audit loop using parallel agent teams with structured simplify, harden, and document passes. Spawns implementation agents to do the work, then audit agents to find complexity, security gaps, and spec deviations, then loops until code compiles cleanly, all tests pass, and auditors find zero issues or the loop cap is reached. Use when: implementing features from a spec or plan, hardening existing code, fixing a batch of issues, or any multi-file task that benefits from a build-verify-fix cycle.

Code Quality & Workflow513 installs

plan-interview

pskoett/pskoett-ai-skills

Ensures alignment between user and Claude during feature/spec planning through a structured interview process. Use this skill when the user invokes /plan-interview before implementing a new feature, refactoring, or any non-trivial implementation task. The skill runs an upfront interview to gather requirements across technical constraints, scope boundaries, risk tolerance, and success criteria before any codebase exploration. Do NOT use this skill for: pure research/exploration tasks, simple bug fixes, or when the user just wants standard planning without the interview process.

Code Quality & Workflow485 installs

intent-framed-agent

pskoett/pskoett-ai-skills

Frames coding-agent work sessions with explicit intent capture and drift monitoring. Use when a session transitions from planning/Q&A to implementation for coding tasks, refactors, feature builds, bug fixes, or other multi-step execution where scope drift is a risk.

Code Quality & Workflow435 installs

Popular devops & cloud skills

View category →

microsoft-foundry

microsoft/azure-skills

Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure

OfficialDevOps & Cloud579.1K installs

azure-diagnostics

microsoft/azure-skills

Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.

OfficialDevOps & Cloud569.8K installs

azure-prepare

microsoft/azure-skills

Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.

OfficialDevOps & Cloud569K installs

azure-ai

microsoft/azure-skills

Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.

OfficialDevOps & Cloud568.8K installs

azure-deploy

microsoft/azure-skills

Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.

OfficialDevOps & Cloud568.6K installs

azure-validate

microsoft/azure-skills

Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.

OfficialDevOps & Cloud568K installs