What problem does it solve? Explanations, design docs, and debugging sessions often start from a finished answer, leaving audiences (or yourself) with memorized conclusions that cannot be rebuilt, varied, or stress-tested. This Skill provides a disciplined method for reaching answers by chaining questions whose answers are forced, so every mechanism and design choice is justified by the constraints that produced it. ## Core Features & Use Cases - Sixteen derivation moves: A repertoire covering setup (concrete instances, quantitative failure of naive solutions, well-posedness checks, cross-domain isomorphs), derivation (smallest hard instance, components voiced as questions, running budgets), and stress-testing (breaking points, baseline comparisons, single-assumption perturbations, falsifiable predictions). - Multi-domain application: Applies the same loop to explanation, debugging (test the assumed mechanism, not the symptom), design review (demand the number that killed the simpler alternative), option selection, and learning new topics as deltas from known ones. - Honesty and anti-pattern guardrails: Explicit conventions for labeling invented examples, skipped proofs, and naming collisions, plus a do/don't table that catches assertion-style exposition. - Use Case: When explaining why a system uses a cache, instead of stating it, you open with the 10ms latency requirement and the 300ms database, let the naive approach fail quantitatively, and let the cache emerge as the only surviving answer. ## Quick Start Explain why this system uses a cache by deriving it from the latency constraints rather than stating it as a given.
