Keep the Why

The core job: preserve and recover the reasoning that code alone cannot explain. Because "ask Bob" is not documentation — Keep a Changelog records what changed, this preserves why it changed.

When to use this skill

Four modes, all part of the same job:

1. Continuous capture — record rationale as it surfaces during normal development: decisions, rejected alternatives, workarounds, incidents, constraints, and changes that didn't happen (starting to modify something, then stopping once a reason not to became clear — that reasoning would otherwise leave no trace). See references/continuous-capture.md.
2. Retrospective recovery — given an existing or legacy repository, reconstruct what the code cannot explain from git history, issues, existing docs, and the code itself.
3. Knowledge-transfer interview — when a maintainer's knowledge is about to become unavailable, analyze the repository first, then either ask targeted questions or let them narrate freely. See references/interview-playbook.md.
4. Maintenance — keep existing rationale current: resolve contradictions, mark superseded entries, merge duplicates, split files that have grown too large.

Edge cases

Don't create a context/ entry for: