property-based-testing

Property-Based Testing

Role: worker. This command derives and generates property-based tests directly — it does not replace example-based tests, and it does not fabricate a weak "doesn't crash" property when no round-trip pair or documented invariant can be found.

Procedure

Step 1: Detect the target language (reuse project-init — never re-derive)

Run project-init's own stack detection — ${CLAUDE_PLUGIN_ROOT}/skills/project-init/SKILL.md § "Step 1: Detect the stack" — over the target project. That section is this repo's canonical, single source of truth for stack detection (its own frontmatter says so); this skill reuses its result and never re-implements the filesystem-signal table (package.json/tsconfig.json for JS/TS, pyproject.toml/ requirements*.txt/setup.py for Python, *.sln/*.csproj for C#, pom.xml/build.gradle for Java) itself.

Reduce that step's result to a single detected-language value:

• Exactly one stack detected → its display name, verbatim as project-init's own stack table spells it (Python, JS/TS, C#, Java).
• Zero or ambiguous signals (project-init's own "ask the user" branch) → no detected language.

Step 2: Gate on support

Pass the detected language (or nothing, when Step 1 found none) to scripts/detect_and_dispatch.py:

python3 "${CLAUDE_PLUGIN_ROOT}/skills/property-based-testing/scripts/detect_and_dispatch.py" --language "<detected language>"

This script decides support — it does not detect anything itself (see its own module docstring). When the language is neither Python nor JS/TS, or no language was passed at all, it prints the exact message below and exits non-zero. Stop here — no partial run, no file written, exactly as the Gherkin "Unsupported or undetected language" scenario requires:

Unsupported language: <detected|unknown> — supported: Python, JS/TS.

<detected> is the actual detected language name (e.g. Go, C#) when Step 1 found one but it isn't supported; the literal word unknown when Step 1 found nothing at all.