canary-failure-impact

Canary: Failure Impact

Answers "what actually breaks if this code fails and no test catches it?" Produces a severity label and a concrete description of downstream effects to help prioritise where to invest test coverage.

When to Use

• Before deciding which gap to close first: "which of these matters most?"

• When a test fails and you need to understand the blast radius

• As Phase 3 of /canary-test-pipeline

• When asked "what's the impact if this breaks?"

This skill vs. canary guardian analyze

This skill discovers downstream dependents with harness's compute_blast_radius primitive when the MCP is present (degrading to plain grep -r when it is not), then applies a domain-keyword heuristic (Steps 3–4 below) to turn that dependent set into a severity label. The severity labeling is the heuristic part — keyword matching over dependent file and function names. canary guardian analyze (ts/src/guardian/, wired to canary guardian analyze in ts/src/cli.ts) is a real OpenAPI-diff blast-radius engine — it diffs two OpenAPI specs (--spec-before / --spec-after), extracts the actual added/removed/changed endpoints, and maps each to coverage gaps against a coverage-report.json. For the class of change it covers, guardian is strictly higher-fidelity than the heuristics here.

• Use canary guardian analyze when the change is an API/schema change and you have (or can generate) before/after OpenAPI specs — it gives exact endpoint-level impact and coverage-gap data instead of a keyword guess.
• Use this skill for everything guardian doesn't cover: non-API code paths (services, UI components, internal functions), impact tracing where no OpenAPI spec exists, or when you need the broader billing/auth/compliance domain-severity labeling in Step 3 rather than a strict API diff.

They are complementary, not competing — do not duplicate guardian's spec-diff logic here if an OpenAPI change is in scope; delegate to canary guardian analyze instead.