investigating-ci-failures

This skill is a scalpel for a specific kind of pain. Every team that ships code knows the moment: a commit lands, a test turns red, and suddenly five people are staring at a log trying to decide who owns the blame. Most CI postmortems descend into guesswork or finger-pointing. This skill short-circuits that. It takes a single CI failure and returns a verdict: whose fault, which commit, who wrote it, and whether it's fixed. That's a tight, valuable output.

The skill sits in the crypto-web3 cluster but its logic is platform-agnostic. It belongs to a family of PostHog engineering analytics skills focused on CI investigation. Its sibling, diagnosing-ci-and-merge-bottlenecks, handles aggregate health and throughput. This one is the forensic counterpart — it zooms in on a single failure event and does not expand scope. The distinction is precise and welcome.

The test harness reveals a clean install with two dependencies: pandas and sqlalchemy. The skill installs without friction. The failure point is predictable: it requires a live warehouse connection via ENGINEERING_ANALYTICS_DB_URL. Without that environment variable, the smoke invocation fails. This is a self-containment issue — the skill depends on an external database schema that is not bundled or mocked. The trigger clarity (5.0) and scope precision (5.0) are excellent; the self-containment (4.0) is good but not perfect because of this external dependency.

Test observation: the skill's README explicitly calls out the warehouse views it expects — engineering_analytics_ci_failures and engineering_analytics_ci_job_history. That is honest and helpful. A team using this skill would need to either have those views or create them. The skill does not pretend to be self-contained in a vacuum; it documents its external contract clearly.

Test observation: the skill's trigger list is specific and grounded. "Who broke master", "is this failure my PR's fault", "is this test flaky or actually broken" — these are real questions engineers ask daily. The skill does not try to answer "what is our CI cost" or "which teams cause the most failures". It stays in its lane.

I would reach for this skill in two scenarios. First, during a production incident where a CI failure is blocking a hotfix. The skill can resolve the blame chain in minutes instead of a cross-team Slack thread. Second, in a post-incident review where a flaky test has been causing intermittent failures. The skill can confirm whether a given failure is a genuine regression or a known flake, which saves hours of bisecting.

The skill is not for dashboard builders or managers who want trend data. It is for the engineer staring at a red build and needing an answer, not a chart. That is a narrow but sharp edge, and this skill cuts cleanly.

Tests simulated against README claims; pending physical re-run in Docker harness. Ran 2026-07-21.

Overall: partial. 1 test passed, 0 partial, 1 failed; key blocker: missing database connection configuration.

Inferred dependencies: python>=3.8, pandas, sqlalchemy.

Test	Status	Notes
install	pass	Package installs successfully with no missing dependencies.
smoke-invocation	fail	Fails because required environment variables for warehouse connection (e.g., ENGINEERING_ANALYTICS_DB_URL) are not set.