failure-archaeology

What problem does it solve?

This Skill solves the common problem of teams wasting time re-investigating already-solved design decisions, re-proposing fixes that were previously rejected, or re-breaking hardened code because they lack context on past investigations, ADR rulings, and dead-end experiments.

Core Features & Use Cases

• Structured investigation records: Each entry follows a strict Symptom → Root cause → Evidence → Status → Lesson format, with cited PRs, issues, and file locations for full traceability.
• Rejected alternative tracking: Explicitly lists dead-end solutions and rejected fixes with their rationale, so developers and automated reviewers don't re-propose known-bad approaches.
• ADR and cross-skill integration: Includes alternatives tables from architecture decision records and cross-references to related skills (e.g., diagnostics-and-tooling, api-contract) for full context.
• Use Case: Before proposing a change to the app's state management, caching, or routing logic, use this Skill to check if the fix was already tried, if an ADR covers the decision, or if there are existing guardrails you might break.

Quick Start

Consult the failure-archaeology skill to review past investigation outcomes before proposing a new fix to the app's connectivity error handling logic.