check-workflows_skill

Overview

This skill checks GitHub Actions workflow runs from the past day (or a configurable lookback) to detect severe or recurring failures and files a GitHub issue when actionable problems are found. It focuses on separating expected noise from real incidents, triaging failures, and creating a concise, outcome-oriented issue to drive remediation.

How this skill works

The skill lists recent workflow runs and groups them by workflow name. It classifies each failure as expected or actionable using a set of explicit rules, then investigates actionable failures by fetching failed logs and identifying error patterns. If findings are SEVERE or MODERATE and not already reported, it files a structured GitHub issue with examples, severity, and suggested fixes.

When to use it

• Daily automated health check of repository CI and scheduled workflows.
• After noticing an uptick in failing workflows to determine systemic vs. expected noise.
• When main-branch CI appears unstable across multiple pushes.
• To detect permission, runner, or rate-limiting issues early.
• Before opening an incident to ensure duplicates are avoided.

Best practices

• Ignore known non-actionable workflows (nightly runner cleanup, CLA bot, contributor PR CI on non-main branches).
• Require at least two consecutive failures on main for CI-consistency alerts to avoid false positives.
• Fetch the first 100 recent runs and clamp to the configured lookback window for performance.
• Search existing issues with a workflow-health label before filing a new one to prevent duplicates.
• Include log snippets, run links, severity, and a suggested fix in every filed issue.

Example use cases

• Detecting a missing GITHUB_TOKEN causing 401/403 errors across scheduled workflows and filing a SEVERE issue.
• Noticing the main CI fails on two successive pushes with the same test error and opening a consistency incident.
• Identifying repeated GitHub API rate-limit errors across runs and creating a MODERATE issue recommending retries or backoff.
• Skipping noise like Playwright report upload failures that cascade from CI and only reporting the root CI failure.
• Spotting self-hosted runner disk-space or availability problems and reporting an infrastructure outage.