القائمة
Start here to adversarially validate a change — edge cases, failure modes, and security — and try to break it before shipping.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | testing |
| description | Start here to adversarially validate a change — edge cases, failure modes, and security — and try to break it before shipping. |
| context | fork |
| agent | tester |
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 claim is only validated when a test proves it. "It looks right" is not evidence.
quality phase).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.
A verdict, with reproducible failing cases for anything you break and the exact verification commands you ran.
Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
Guides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.
Start here to ship built-and-tested code to its target safely — release steps, rollout, smoke checks, and rollback.
Start here to settle how a non-trivial change will be built — interfaces, contracts, file-level structure, and trade-offs.
Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.
Start here to document what shipped — READMEs, API docs, ADRs, and usage — once a feature lands or an interface changes.