refire

Enforce structured root cause analysis before code changes in development workflows.

65|5|Updated May 13, 2026
One-click install
npx skills add https://github.com/escoffier-labs/brigade --skill refire
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: refire
Source: https://github.com/escoffier-labs/brigade/tree/main/registry/skills/refire
Command: npx skills add https://github.com/escoffier-labs/brigade --skill refire

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

When software breaks—failing tests, production bugs, build breaks, or flaky behavior—teams often rush to quick fixes that mask the underlying issue, leading to repeat incidents, longer downtime, and compounded technical debt, especially under pressure like CI blocking deployments.

Core Features & Use Cases

  • Structured Root Cause Investigation: A step-by-step process to trace failures to their source, including reading full error details, reproducing the issue, auditing recent changes, checking documented contracts, and comparing against working examples.
  • Fix Guardrails: Requires a written hypothesis, a pinned failing test that asserts the broken contract before any fix, minimal single-variable changes, and automatic escalation after three failed fix attempts to avoid guesswork.
  • Common Pitfall Avoidance: Explicitly calls out and rejects common rationalizations for skipping process, like "quick fix now, investigate later" or "just try X and see", that lead to recurring bugs. Use case: If your CI pipeline is failing after a recent dependency update, use this skill to systematically trace the root cause instead of randomly tweaking configs to get a green build that breaks again later.

Quick Start

Use the refire skill to investigate the root cause of the failing end-to-end test suite in the current repository before proposing any code changes.

Frequently Asked Questions about refire

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

FAQPage Schema
How do I find the root cause of a failing CI pipeline instead of applying a quick fix?

To find the root cause of a failing CI pipeline, reproduce the issue, audit recent changes, validate documented contracts, and pin a failing test before making any code changes. This structured root cause analysis prevents quick fixes that mask underlying software failures.

What is the best way to debug flaky tests that keep failing after repeated fixes?

Debugging flaky tests requires a structured root cause investigation: reading full error details, reproducing the issue, auditing recent changes, and comparing against working examples. Fix guardrails enforce writing a hypothesis and pinning a failing test before applying minimal single-variable changes.

Why do my production incidents recur after applying emergency patches?

Production incidents recur because emergency patches often mask underlying issues without tracing the root cause. Applying structured root cause analysis with hypothesis testing and contract validation eliminates repeat failures caused by unrooted quick fixes during incident response.

Can I use a structured debugging process for test failures under deployment pressure?

Yes, structured debugging works under deployment pressure by enforcing guardrails against guesswork. It requires a written hypothesis, a pinned failing test asserting the broken contract, and automatic escalation after three failed fix attempts to prevent compounding technical debt.

When should I stop trying random fixes for build breaks and start a formal root cause analysis?

Stop trying random fixes for build breaks after three failed fix attempts, which triggers automatic escalation. A formal root cause analysis is needed to compare against working examples and check documented contracts instead of tweaking configs to force a green build.