testability-reviewlisted

# Testability Review When this skill is activated, analyze the specified code for testability and produce a `docs/reviews/TESTABILITY_REVIEW.md` report. The goal is not to write tests — it is to identify what makes code *hard* to test and recommend targeted structural changes. ## Clarifying Questions Before starting the review, ask the engineer the following questions. Skip any already clearly answered in the conversation. **Wait for the answers before proceeding.** 1. What is the scope — a specific module or feature, or the full codebase? 2. What is the current testing strategy — what types of tests exist today (unit, integration, e2e), and what is missing? 3. Are there specific components or areas known to be difficult or impossible to test? 4. Are there constraints on refactoring — e.g. public APIs that cannot change, no new dependencies allowed, performance-sensitive paths? ## Steps 1. Use the answers above to set scope and focus; fall back to full codebase only if scope was not specified 2. Read the relevant source files 3. Identify testability smells: hidden dependencies, static calls, global state, missing interfaces, logic buried in constructors, etc. 4. For each issue, assess the impact on test quality (false positives, slow tests, untestable branches) 5. Recommend the minimal structural change needed to make each piece testable — prefer surgical fixes over rewrites ## Output Write a file called `docs/reviews/TESTABILITY_REVIEW.md` (create the `docs/reviews/`