property-test-generatorlisted

Use this skill when the user has a list of behavioral invariants for a function/module/feature and wants property-based tests generated from them. Triggers on phrases like "generate property tests", "make hypothesis tests for X", "property-test these invariants", "fuzz-test this function", or when the feature-development skill's Stage 1 spec audit identifies invariants worth exploring with Hypothesis. ALSO use proactively if you read a spec_audit.md that lists invariants without corresponding property tests — generating them now (during spec audit) is cheaper than discovering edge cases after impl. Output: a Python test file using `hypothesis` (default) or `dart_check` for Flutter, with one `@given(...)` test per invariant, calibrated input strategies, and shrink-friendly assertions. The skill does NOT run the tests — it generates them, the user runs them.
neuralforge-labs/tlmforge · ★ 4 · Testing & QA · score 55

Install: claude install-skill neuralforge-labs/tlmforge

# Property test generator This skill turns English invariants into mechanical input-space exploration. Property-based tests catch the bugs the reviewer trio misses BECAUSE they explore inputs you didn't think to enumerate. Especially valuable for memory/encryption/auth/PII code paths where input spaces are large and the failure mode is "weird input → silent corruption." ## When to use **Trigger conditions:** 1. User explicitly asks: "generate property tests", "make Hypothesis tests for X", "fuzz-test this". 2. A `spec_audit.md` lists invariants in a section (typically labeled "Invariants" or "Properties this must satisfy"). Generating tests at spec-audit time is the cheapest place to do it — invariants that turn out un-testable are signal that the spec is fuzzy. 3. The user is modifying a function in a security-sensitive area (auth, encryption, PII, payments) — propose property tests proactively even if not asked. **When NOT to use:** - Pure UI / integration tests (property tests don't fit click-flow surfaces well — Playwright is the right tool). - Unit tests for trivial functions where example-based tests are sufficient and clearer. - If the user just wants 1-2 tests for a happy path (overhead of `@given` + strategy auth doesn't earn its keep for tiny surfaces). ## Recipe ### Step 1 — extract invariants Read the user-provided spec / spec_audit.md / invariant list. Each invariant should fit the shape: "**For all <input X> satisfying <precondition>, <function Y