Build Failure and Regression Repair
Trace failing builds and bug reports to a proven cause, apply a focused fix, and verify it with regression coverage.
Before & after
Same prompt, same agent — the only difference is the skill.
Let me help you fix the failing build. I'll need to understand what's failing first. Common causes of a red build on main: - A merge that passed CI on the branch but conflicts semantically with another merge - A flaky test - A dependency that updated - An environment difference between local and CI I'd suggest checking the CI logs to see which step failed and what the error message says. If it's a test failure, look at what changed recently in that area. Can you share the CI output?
Read the CI log. One failure, and it's real — not flaky.
FAILURE
api/billing/invoice.test.ts:88
Expected 2 invoice line items, received 3.
First red build: commit 4f2c9a1, merged 40 minutes ago.
CAUSE
4f2c9a1 added a proration line item to invoice generation. Correct
change. The test asserted an exact count and predates proration
existing, so it was always going to break the first time anyone added
a line type.
It passed on the branch because the branch forked before 7bd3e02,
which enabled proration by default. Neither commit is wrong; the
combination is. Standard semantic conflict — CI on each branch
couldn't have caught it.
MINIMAL FIX
The assertion is testing the wrong thing. It should assert the
subscription line is present and correct, not that exactly two lines
exist — the count is incidental and will break again next time.
- expect(invoice.lineItems).toHaveLength(2)
+ expect(invoice.lineItems).toContainEqual(
+ expect.objectContaining({ type: 'subscription', amount: 4900 })
+ )
TEST ADDED — covers the gap that let this through
A case asserting the proration line appears when a mid-cycle plan
change occurred. That behavior shipped in 4f2c9a1 with no test, which
is why the only signal was an unrelated assertion breaking.
SCOPE — deliberately not touched
The other 11 exact-length assertions in this file have the same
latent fragility. Not fixing them here: unrelated to the red build,
and a 12-assertion refactor on a hot main is how one red build
becomes two. Worth a follow-up.
VERIFY
Suite green locally, 3 consecutive runs. Ready to push.About this skill
“The build is red, but I can't tell which error matters.” “The bug disappeared locally and came back in CI.” This skill turns failing output or a bug report into a reproducible failure, an evidence-backed cause, and a focused repair with regression coverage.
What it does
- Separates application defects from dependency, configuration, environment, and flaky-test failures.
- Traces downstream error cascades back to the first actionable cause.
- Uses targeted checks to distinguish competing explanations before changing code.
- Repairs the responsible boundary without hiding errors or weakening valid checks.
- Verifies that the regression check catches the original defect and that the relevant build and tests pass afterward.
What you get
A focused code change when repository access is available, or a concrete proposed patch when it is not. The handoff includes the causal explanation, regression coverage, exact verification commands and results, and any checks that remain unrun.
Best for
Developers maintaining existing applications, libraries, and CI pipelines who need a failing build or reported regression resolved without an unrelated refactor.
SKILL.md preview
---
name: build-failure-and-regression-repair
description: Diagnose failing builds and bug reports by reproducing the symptom, distinguishing code defects from environment and dependency failures, and testing a specific causal hypothesis. Apply the smallest correct repair and verify it with regression coverage. Use when the user says "fix this failing build", "my tests keep failing in CI", "this worked before the last change", "track down this regression", "this bug only happens sometimes", "here is the error log", or "fix this without refactoring everything".
---
# Build Failure and Regression Repair
… (sign up to view the full skill)More development skills
View all Development skills →Performance Bottleneck Profiling: Node, Python, Go
Classifies a slowdown, gives exact profiler commands, reads the output, and proves the fix with same-conditions p95/p99 numbers.
Feature Scaffolding with Working Tests
Turn a short feature spec into code, runnable tests, and integration wiring that match your existing project.
Feature Flag Rollouts and Kill Switches
Design staged flag rollouts, verify rollback paths, and audit flag debt with explicit defaults, gates, and retirement plans.
Microcontroller Firmware and RTOS Engineering
Build and debug MCU firmware with bounded ISR/RTOS timing, safe DMA ownership, and measured power budgets.