# Debugging Ci Failures

Debugs failing GitHub Actions CI runs for PostHog PRs, commits, and branches, and...

- Repository: https://github.com/amplifthq/openmeld (1404 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add amplifthq/openmeld --skill debugging-ci-failures -g -a claude-code -y`
Codex: `npx skills add amplifthq/openmeld --skill debugging-ci-failures -g -a codex -y`
Cursor: `npx skills add amplifthq/openmeld --skill debugging-ci-failures -g -a cursor -y`
Gemini CLI: `npx skills add amplifthq/openmeld --skill debugging-ci-failures -g -a gemini-cli -y`

## Description

Debugs failing GitHub Actions CI runs for PostHog PRs, commits, and branches, and answers broad CI-health questions ("is CI red?", "is master green today?", "what's broken right now?"). Use when the user asks why CI is red, asks for the current CI or master status, or mentions a failing check, GitHub Actions run, Depot runner, workflow, job, shard, merge queue kick, flaky test, lint failure, typecheck failure, snapshot diff, migration check, generated types drift, or skills build failure. Start with the `hogli ci:insights` digest (cross-run CI history from engineering analytics), then guides read-only inspection, failure classification, smallest local reproduction with hogli, and safe reporting without rerunning CI or posting to GitHub. Running unattended as the "Master-red diagnosis" workflow: see references/master-red-incident.md.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Debugging PostHog CI failures

Before you propose a change to CI, check [things already tried](../../../docs/internal/ci-things-already-tried.md) for the idea. It records what was measured, and why some good-sounding changes were reverted or rejected.

Find the first meaningful failure, classify it, reproduce the smallest useful
case locally when appropriate, and report the result. Avoid public-visible or
irreversible actions unless the user explicitly asks.

Always start with the `hogli ci:insights` digest. It aggregates across runs and
branches, which `gh` cannot do cheaply, and tells you whether a failure is
likely trunk-borne, gate-only, or isolated to a small set of branches. `gh` is
authoritative for one run's current state and attribution. Use the digest to
decide _what_ to inspect; use `gh` to confirm _whose_ failure it is and exactly
what failed in a given run.

This skill triages and classifies. Once a failure is confirmed flaky, hand off
to the `fixing-flaky-tests` skill, which owns local reproduction, root-cause
fixing, and N-run validation. For "who broke master", the culprit commit and
the commit that fixed it, hand off to the `investigating-ci-failures` skill,
which owns the green/red boundary analysis. For aggregate pipeline health (is CI
getting slower, which workflow is the long pole, how long PRs take to merge),
read `diagnosing-ci-and-merge-bottlenecks`. Both are product skills under
`products/engineering_analytics/skills/`, not invocable here: read the
`SKILL.md` at that path.

## Rule out a platform outage first

GitHub Actions goes down often enough that it belongs before any log reading, and
a platform incident makes every other signal a symptom. It costs two page loads:
<https://www.githubstatus.com/> for GitHub, <https://status.depot.dev/> for the
runners. Check them whenever failures are broad, several workflows at once, a
burst of runs failing together, jobs dying before `Checkout`, or anything red
across unrelated PRs.

The rest: https://github.com/amplifthq/openmeld/blob/HEAD/.agents/skills/debugging-ci-failures/SKILL.md