Improve test suite

Overview

Diagnose weak, redundant, brittle, or low-signal tests across a repository or subsystem, then produce a practical improvement plan. Prefer a smaller suite that proves real behavior through public interfaces. Preserve tests tied to incidents or contracts unless evidence shows that another test covers the same risk more reliably.

When to Use

• Reviewing a repo or subsystem test suite for brittleness, redundancy, or low signal
• Planning test cleanup before or alongside broader architecture work
• Auditing whether tests align with behavior-first, public-interface, vertical-slice TDD principles
• Identifying which tests to remove, which seams need better proof, and which new tests would add real trust

When Not to Use

• Root-cause debugging when the failure mode is not yet understood
• Ordinary feature implementation with a local test choice question better handled by engineering
• Pure code-architecture review where testing is secondary
• One-off flaky test investigation that does not need suite-level review