testing

name	testing
description	Use after implementation to probe edge cases, failure modes, malformed input, scale, security, and contradictions.
targets	["*"]
claudecode	{"context":"fork","agent":"tester"}

This skill defines the testing phase. Use the `tester` agent when bounded adversarial validation can proceed independently; otherwise work locally. Produce reproducible cases and a clear verdict.

Use lifecycle-documentation only when the result needs a durable artifact or handoff.

Try to break it — falsify the change. Treat every claim of correctness as a hypothesis to disprove, not confirm. Run the existing tests first, then attack.

A behavioral claim is validated only when an executable test supports it. Visual, accessibility, process, and quality claims require evidence appropriate to those claims.

Attack surface

• Edge cases — boundaries, empty/null, extremes.
• Scale and concurrency — what breaks under load or races.
• Malformed input — garbage, hostile, unexpected shapes.
• Security — how a malicious actor would abuse it (dynamic security testing; hardening review belongs to the quality phase).
• Contradictions — where behavior disagrees with what was specified.

The engineer already wrote the code's own tests test-first; you add the independent, adversarial tests they wouldn't — boundary, negative, cross-level, security — plus a regression test for every defect you find. Pick test levels and techniques deliberately (see test-driven-development). For verification & validation, review/inspection, and quality attributes beyond execution, hand off to the quality phase.

What to produce

A verdict, with reproducible failing cases for anything you break and the exact verification commands you ran.