What problem does it solve? Designs often reach implementation without anyone asking how the feature will be tested, how it fails, or what is observable when it breaks. Testability problems discovered after code is written are the expensive kind; this Skill surfaces the testability bill while the design is still cheap to change. ## Core Features & Use Cases - Six-question interrogation: Walks through what "working" looks like, the cheapest check that proves it, failure modes, observability per failure, design seams that make checks cheap, and what will deliberately not be tested. - Companion to design workflows: Runs alongside spec drafting, ADR authoring, or plan review sessions, and never acts as a gate that blocks a design. - Structured write-down: Answers land in one home — a ## Testability section in the effort spec, the Consequences section of an ADR, or V<n> items in a verification plan. - Use Case: While drafting a spec for a retry mechanism, use this Skill to enumerate failure modes (dependency down, partial completion, concurrent runs), record the observable signal for each, and capture the accepted untested risk as an explicit decision. ## Quick Start Ask the agent to run the design-for-testability interrogation on the current spec or ADR draft and record the six answers in the design document.
