kami-failure-archaeology

Indexes past incidents, rejected fixes, and deliberate oddities to prevent repeating settled engineering decisions.

1|Updated Jun 29, 2026
One-click install
npx skills add https://github.com/Raynos/kami-kakushi --skill kami-failure-archaeology-raynos
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kami-failure-archaeology
Source: https://github.com/Raynos/kami-kakushi/tree/main/.claude/skills/kami-failure-archaeology
Command: npx skills add https://github.com/Raynos/kami-kakushi --skill kami-failure-archaeology-raynos

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams repeatedly re-fight settled battles: re-proposing rejected fixes, "fixing" deliberate design oddities, or re-opening decisions that already cost real time. This Skill provides a searchable incident chronicle so an agent checks history before changing anything that looks odd. ## Core Features & Use Cases - Incident chronicle with statuses: Every major investigation, dead end, and revert is recorded with root cause, evidence (SHA/journal), and a status of settled, fenced-off, or still-open. - Deliberate oddities table: Documents counterintuitive configurations (hmr:false, muted SFX engine, cook-anywhere) that must not be "fixed". - Doctrine index: Maps each incident to the standing rule it minted and its enforcement rung (hook, gate, norm, or philosophy). - Use Case: Before proposing to re-enable HMR in a Vite dev server, consult the chronicle to learn that hmr:false plus an inert /@vite/client is the only complete fix for reload-yanking a live game, with the exact commit SHAs cited. ## Quick Start Ask the agent to check the failure chronicle for whether this issue or design question has happened before, citing the relevant incident and rule.

Frequently Asked Questions about kami-failure-archaeology

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

FAQPage Schema
How do I check if a bug or design question has been investigated before?

Consult the incident chronicle, which records every major investigation with root cause, evidence SHAs, journal references, and status. Search by symptom or subsystem, then follow the cited ADR or journal entry for full detail.

What should I do before proposing a process change or new gate?

Review the chronicle's process section first, since several ceremonies were proposed and reeled back as over-engineered. The Operating Model v2 reel-back entry is the template for recognizing process-for-its-own-sake proposals.

Why are some configurations deliberately odd, like hmr:false or a muted SFX engine?

The deliberate oddities table documents configurations that look wrong but are load-bearing decisions, each tied to a specific incident or human ruling. Changing them without reading the cited incident risks reintroducing a solved problem.

When should I not use an incident chronicle skill?

Do not use it for fixing a currently red gate, live-debugging a new symptom, or asking about change approval; those belong to verification, debugging, and change-control workflows. The chronicle answers history questions, not active diagnosis.

How are new incidents added to the chronicle?

Journal the incident first, then append an entry in the same shape with the journal and SHA cited. The chronicle is an index over the journal, not a substitute for the original journal entry.