Test Design

Design the test plan before implementation escapes into review or release: extract risk-bearing domains from code or specs, then generate the exact cases needed to catch boundary, calendar, concurrency, state-transition, and library-semantic failures.

When to Use

• User asks to design tests or generate test cases from code, specs, or a ticket ("design tests", "test plan", "/test-design")
• User wants edge case tests or boundary value tests before writing or shipping code
• User wants a feature-level test plan instead of test implementation
• User wants to compare planned coverage against existing tests and find gaps

When NOT to Use

• Writing test code as the primary task
• Reviewing a completed diff for bugs after implementation (use review-and-fix)
• Full release validation, exploratory QA execution, or production incident triage
• Performance benchmarking plans that do not require correctness or edge-case analysis

Inputs