Property-Based Test Design - QA Skill Library

Why this Skill

It turns this Skill's method into a quality input that can be executed, reviewed, and reused.

Analyze domain invariants, input generation domains, constraints, failure examples, shrinking strategies, and existing properties.
Do not invent invariants, generation domains, or shrink results, or treat a generator as proof of a finding.
File presence, names, templates, and Eval configuration are not runtime evidence.
Do not edit requirements, code, test assets, or target systems, or accept risk for a Human.
Do not treat a method name, file presence, or candidate count as execution, coverage, pass, or release evidence.

When to use

Use this Skill

Analyze domain invariants, input generation domains, constraints, failure examples, shrinking strategies, and existing properties.
Preserve selection rationale, evidence gaps, priority, and validation actions.
Inputs are incomplete but a bounded first pass can mark items unassessed or blocked.

Common pitfalls

Do not treat a method name, file presence, or candidate count as execution, coverage, pass, or release evidence.
Do not fill missing invariants, generation domains, or results with convention; preserve unassessed, blocked, and pending items.
Do not expand this specialist design into a complete strategy, full test cases, runtime execution, or a release decision.

Input

Minimum Input

Read `prompts/property-based-testing.md` and provide the objective, scope, material, environment, and evidence.

Recommended Input

Project goal
Test scope
Constraints

Optional Context

Relevant code or configuration
Historical results
Logs and metrics

Output

The output follows this Skill's method and makes facts, assumptions, risks, and next steps explicit.

Judge the output value before installing

01Read prompts/property-based-testing.md and provide the objective, scope, material, environment, and evidence.
02Start with separate known, missing, conflicting, stale, out_of_scope, and assumptions entries.
03Produce PBT-## findings with source, evidence state, applicability, impact/priority, owner, close condition, and validation.
04Separate facts, evidence-backed inferences, recommendations, and Human decisions.

View full output structure

05Recommend follow-up validation without claiming execution.

How It Works

01Read prompts/property-based-testing.md and provide the objective, scope, material, environment, and evidence.
02Start with separate known, missing, conflicting, stale, out_of_scope, and assumptions entries.
03Produce PBT-## findings with source, evidence state, applicability, impact/priority, owner, close condition, and validation.
04Separate facts, evidence-backed inferences, recommendations, and Human decisions.
05Recommend follow-up validation without claiming execution.

Install & Quick Start

Install command / SHELL

npx skills add \
  https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/property-based-testing
  -g

property-based-testing.prompt

@skill property-based-testing

Using the current project context, produce an actionable result following this Skill.

Additional context:
[Paste project context or requirement]

---
name: property-based-testing
description: Use this skill when you need to turn invariants, generation domains, and shrinking strategies into reviewable property-test candidates; triggers include 基于属性的测试 and property-based test design.
---

# Property-Based Test Design

Turn invariants, generation domains, and shrinking strategies into reviewable property-test candidates. Produce PBT-## design candidates within the evidence boundary; do not execute tests or claim coverage or pass results.

## When to Use

- Analyze domain invariants, input generation domains, constraints, failure examples, shrinking strategies, and existing properties.
- Preserve selection rationale, evidence gaps, priority, and validation actions.
- Inputs are incomplete but a bounded first pass can mark items unassessed or blocked.

## Output Format Options

- Use Markdown by default; use tables, JSON, or CSV only when explicitly requested or required by the delivery format.
- Separate static analysis, unexecuted work, evidence states, and Human decisions; keep items unassessed, blocked, or NOT_RUN when runtime evidence is absent.

## How to Use

1. Read `prompts/property-based-testing.md` and provide the objective, scope, material, environment, and evidence.
2. Start with separate known, missing, conflicting, stale, out_of_scope, and assumptions entries.
3. Produce PBT-## findings with source, evidence state, applicability, impact/priority, owner, close condition, and validation.
4. Separate facts, evidence-backed inferences, recommendations, and Human decisions.
5. Recommend follow-up validation without claiming execution.

## Core Constraints

- Do not invent invariants, generation domains, or shrink results, or treat a generator as proof of a finding.
- File presence, names, templates, and Eval configuration are not runtime evidence.
- Do not edit requirements, code, test assets, or target systems, or accept risk for a Human.

## Pre-delivery Check

- [ ] The six-part input audit is complete.
- [ ] Every PBT-## has source, evidence state, applicability, concern, impact/priority, owner, close condition, and validation.
- [ ] Facts, inferences, recommendations, and Human decisions are separate.
- [ ] Unexecuted, unverified, unassessed, and pending-decision items are explicit.

## Reference Files

- Read evals/eval.yaml and matching cases for regression; configuration does not prove project results.
- Use evals/trigger-prompts.csv and evals/local-rules.json for trigger checks; missing skill.selection evidence is BLOCKED.

## Common Pitfalls

- Do not treat a method name, file presence, or candidate count as execution, coverage, pass, or release evidence.
- Do not fill missing invariants, generation domains, or results with convention; preserve unassessed, blocked, and pending items.
- Do not expand this specialist design into a complete strategy, full test cases, runtime execution, or a release decision.

## Best Practices

- Complete the six-part input audit before selecting the smallest traceable and verifiable finding scope.
- Keep the source, evidence state, impact/priority, owner role, close condition, validation method, and residual risk for every finding.
- Write validation suggestions as next actions; do not upgrade package structure, candidate counts, or local Eval configuration into real quality conclusions.