Organize invariants, generation domains, and shrinking strategies into reviewable property-test candidates, outputting PBT-##. It only produces design candidates within the evidence boundary, does not execute tests, and does not claim coverage or passing.
When to Use
- Need to analyze domain invariants, input generation domains, constraints, failure examples, shrinking strategies, and existing properties.
- Need to retain selection rationale, evidence gaps, priorities, and verification actions.
- Inputs are incomplete but a limited initial version must be delivered, marked unassessed or blocked.
Output Format Options
- Default output is Markdown; tables, JSON, or CSV are used only when explicitly required by the user or mandated by an existing delivery format.
- Separate static analysis, unexecuted items, evidence status, and Human decisions; keep unassessed, blocked, or NOT_RUN when there is no runtime evidence.
How to Use
- Read prompts/property-based-testing.md, first listing known, missing, conflicting, stale, out_of_scope, assumptions.
- Form PBT-## per the method contract, retaining source, evidence status, impact, responsible role, closure conditions, and verification method.
- Facts, inferences, recommendations, and Human decisions must be separated.
- Only propose follow-up verification intent; do not write it as an executed result.
Domain Execution Points
- Derive input domains, sourced invariants, preconditions, and observable oracles from the contract; properties cannot be asserted from function names or personal common sense.
- Deliver generation domains, properties/preconditions, replay data, and minimal counterexample criteria; ordered but element-dropping output cannot be judged as satisfying a sorting contract.
- When forming domain candidates, you must read and follow the domain operations and determination process of prompts/property-based-testing.md , retaining legitimate controls, evidence gaps, and verification actions item by item.
Core Constraints
- Do not invent invariants, generation domains, or shrinking results, and do not treat the existence of a generator as a failure already found.
- File existence, names, templates, and Eval configuration do not equal real execution evidence.
- Do not modify requirements, code, test assets, or the target system, and do not accept risk on behalf of the Human.
Pre-Delivery Self-Check
- The six-category input audit is complete.
- Each PBT-## has source, evidence, impact/priority, responsible role, closure conditions, and verification method.
- Unexecuted, unverified, unassessed, and pending-decision items are clearly identified.
Reference Files
- During regression, read evals/eval.yaml and matching cases; configuration does not prove real project results.
- For trigger verification use evals/trigger-prompts.csv and evals/local-rules.json; report BLOCKED when skill.selection evidence is missing.
Common Pitfalls
- When scope or evidence is incomplete, do not write method names, file existence, or candidate counts as test executed, coverage, passing, or release evidence.
- Do not use common sense to fill in rules, thresholds, data, environments, or results that were not provided; retain unassessed, blocked, and to-be-confirmed items.
- Do not expand this Skill's specialized candidates into a complete strategy, complete test cases, real execution, or release decisions.
Best Practices
- Complete the six-category input audit first, then choose the smallest, traceable, and verifiable discovery scope.
- Each finding retains its source, evidence status, impact/priority, responsible role, closure conditions, and verification method, and clearly states the remaining risk.
- Write verification recommendations as next-step actions, and do not elevate the Skill package structure, number of candidates, or local Eval configuration into genuine quality conclusions.