ci-self-heal

Diagnose failing GitHub PR checks and apply root-cause fixes.

Updated May 17, 2022
One-click install
npx skills add https://github.com/kanade0404/dotfiles --skill ci-self-heal
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ci-self-heal
Source: https://github.com/kanade0404/dotfiles/tree/main/.opencode/skills/ci-self-heal
Command: npx skills add https://github.com/kanade0404/dotfiles --skill ci-self-heal

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you recover failing pull request CI by finding the actual root cause instead of wasting time on blind reruns or guesswork.

Core Features & Use Cases

  • CI Failure Triage: Watches PR checks, inspects failed runs, and identifies which job or step actually broke.
  • Root-Cause-First Repair Loop: Classifies failures as code, flaky, environment, dependency, or infrastructure issues before suggesting a fix.
  • Guardrailed Recovery: Stops after repeated failure, escalates when architecture is the likely issue, and avoids retry-only behavior.
  • Use Case: A GitHub pull request turns red after push, and this Skill tracks the failing check, reads the logs, applies the smallest valid fix, and repeats until the checks are green or escalation is required.

Quick Start

Use the ci-self-heal skill to inspect the failing PR checks, identify the root cause from CI logs, apply the smallest fix, and push a new commit.

Frequently Asked Questions about ci-self-heal

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix failing GitHub Actions PR checks without blindly rerunning workflows?

Fix failing GitHub Actions PR checks by tracing each failure to a root cause through log-driven investigation. This process classifies failures as code, flaky, environment, dependency, or infrastructure issues before applying the smallest valid single-hypothesis fix.

What is the best way to perform root cause analysis on a failing CI build after a push?

Root cause analysis on a failing CI build involves inspecting failed workflow runs to identify the exact broken job or step. This technique categorizes the failure type and applies a targeted fix rather than relying on guesswork or retry-only behavior.

How do I stop CI recovery loops on pull requests from repeatedly failing?

Stop CI recovery loops by implementing a three-failure stop gate before escalation. This guardrailed recovery approach monitors the pull request non-blocking, halting automated repair attempts after repeated failures when architecture is the likely issue.

Does this CI recovery approach work for flaky tests and environment failures?

This CI recovery approach works for flaky tests, environment issues, dependency problems, and infrastructure failures. It categorizes each failure type during the triage phase to determine the correct repair strategy before pushing a new commit.

When should I escalate a broken pull request workflow instead of applying another fix?

Escalate a broken pull request workflow after three consecutive fix failures or when the root cause analysis indicates an architecture issue. The guardrailed recovery loop stops applying fixes to prevent endless workflow recovery cycles.

How do I triage failing GitHub pull request checks from CI logs?

Triage failing GitHub pull request checks by reading the CI logs to track the failing check and identify the exact broken job or step. This log-driven investigation isolates the failure trigger before suggesting a targeted repair.