Discover test candidates from input transformations and expected relations when a reliable oracle is missing, and output MT-##. It only produces design candidates within the evidence boundary; it does not execute tests and does not claim coverage or passing.
When to Use
- Need to analyze baseline inputs, transformation rules, expected relations, output invariants, randomness, and existing evidence.
- 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; use tables, JSON, or CSV only when the user explicitly requires it or the existing delivery format requires it.
- Separate static analysis, unexecuted items, evidence status, and Human decisions; keep unassessed, blocked, or NOT_RUN when there is no execution evidence.
How to Use
- Read prompts/metamorphic-testing.md, and first list known, missing, conflicting, stale, out_of_scope, and assumptions.
- Form MT-## according to 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
- First determine the original input domain, transformation T, output relation R, and their sources/applicability preconditions; the absence of a reliable oracle does not mean arbitrary equivalence relations may be assumed.
- Deliver an input→transformation→output relation→precondition→counterexample table, separating the applicability of the relation from whether the implementation satisfies the relation.
- When forming domain candidates, you must read and follow the domain operations and decision process of prompts/metamorphic-testing.md , retaining legitimate controls, evidence gaps, and verification actions item by item.
Core Constraints
- Do not invent transformation relations, output results, or randomness conclusions, and do not treat a relation table as execution proof.
- 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 MT-## 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 pending-confirmation 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.
- For each finding, retain source, evidence status, impact/priority, responsible role, closure conditions, and verification method, and clearly state the remaining risk.
- Write validation suggestions as next-step actions, and do not upgrade the Skill package structure, number of candidates, or local Eval configuration into real quality conclusions.