decision-archaeology

Reconstruct past design rationale by tracing time-ordered artifacts like commits, PRs, and design docs. This process extracts the reasoning chain and constraints that shaped the original choice, helping you understand why a team chose one path over another.

Tracing rejected alternatives from git history involves ordering relevant artifacts chronologically to extract the rationale chain. It records what was rejected, why it was rejected, and performs a revival check to see if changed constraints make a previously rejected option viable.

Design docs and chat logs provide the dated evidence needed to understand a refactor's path. By ordering these artifacts chronologically, you can extract the antecedents and constraints that influenced the team's decision-making process at that time.

Checking if a rejected alternative should be revived involves reviewing the original rationale chain and comparing it against current constraints. A revival check identifies whether the specific reasons for rejection are no longer valid, making the alternative worth reconsidering.

Decision archaeology works for incident reviews and historical design analysis by reconstructing the rationale from time-ordered artifacts. It applies the same chronological tracing and rationale extraction to understand the choices made during the incident or initial design.

To trace a decision through artifact history, you need to provide a cited chronology of relevant artifacts. The Skill then processes these dated items to produce an archaeology report containing the rationale chain, rejected alternatives, and a revival check.