happier-ci-stabilize

Diagnose and stabilize failing GitHub Actions CI runs and nightly releases.

1.6k|141|Updated Dec 16, 2025
One-click install
npx skills add https://github.com/happier-dev/happier --skill happier-ci-stabilize
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: happier-ci-stabilize
Source: https://github.com/happier-dev/happier/tree/main/skills/happier-ci-stabilize
Command: npx skills add https://github.com/happier-dev/happier --skill happier-ci-stabilize

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

Failing, flaky, or slow CI pipelines and nightly releases waste engineering time through repeated blind reruns and serial rediscovery of errors. This Skill collects every reachable failure from one exact GitHub Actions attempt, clusters root causes, and chooses the cheapest safe recovery path.

Core Features & Use Cases

  • Complete failure collection: Runs a Node.js collector script that downloads all failed job logs for an exact run/attempt via the GitHub CLI and produces a compact summary.json with failed steps and error excerpts.
  • Root-cause clustering and batched fixes: Collapses aggregator noise into canonical causes, classifies each cluster (product, test, harness, infrastructure), and corrects them in one batch with RED/GREEN evidence.
  • Cheapest safe recovery: Selects between native failed-job rerun, immutable-candidate resume, or a fresh nightly based on what bytes changed, preserving verified build and signing work.
  • Use Case: A nightly release fails across multiple jobs. Use this Skill to collect all failures from the exact run ID, fix the two real root causes locally, then resume the nightly with resume_run_id so already-verified candidates are reused instead of rebuilt.

Quick Start

Use the happier-ci-stabilize skill to collect all failures from GitHub Actions run 12345678, cluster the root causes, and recommend the cheapest safe recovery path.

Frequently Asked Questions about happier-ci-stabilize

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

FAQPage Schema
How do I collect all failures from a failed GitHub Actions run?

Run the collect-actions-failures.mjs script with the repository, run ID, and optional attempt number. It downloads complete logs for every failed, cancelled, or timed-out job and writes a summary.json with failed steps and error excerpts under /tmp.

How do I resume a failed nightly release without rebuilding everything?

Dispatch the nightly workflow with resume_run_id set to the completed origin run ID, but only when product source, packaging, and candidate bytes are unchanged. The resume path reuses individually verified immutable candidates while rerunning downstream validation gates.

When should I rerun failed CI jobs versus starting a fresh run?

Use a native failed-job rerun for transient runner, network, or external service failures on the same SHA. Start a fresh run when product source, build scripts, dependencies, or signing inputs changed, since old artifacts no longer prove the new code.

Does this workflow require the GitHub CLI?

Yes, the failure collection script invokes the gh api command to fetch run metadata, job lists, and job logs. You must have gh installed and authenticated with access to the target repository before running the collector.

Why should I not retry a failed release publication automatically?

A failed mutation such as a release PATCH or upload may have succeeded remotely, so blind retry can duplicate or overwrite publication. Reconcile the observed remote state first, and only retry operations proven idempotent.

When is it safe to remove or consolidate flaky CI tests?

Remove coverage only when evidence shows it duplicates the same observable contract, polices formatting or constants with no public contract, or duplicates a canonical testkit boundary. Strengthen the owner-level test first and preserve one discriminating test per real contract.