boundary-value-testing

Boundary Value Test Design

Select boundary and adjacent value candidates based on sourced value ranges, lengths, time, and resource constraints, and output BVT-## findings. It only organizes traceable test design candidates; it does not execute tests, nor does it write the design checklist as coverage, pass, or release evidence.

When to Use

• Need to extract Boundary Value Test Design candidates from field schemas, min/max rules, inclusion relationships, units, time rules, resource limits, and historical defects.
• Need to explain selection rationale, applicable constraints, evidence gaps, and minimal verification actions.
• Materials are incomplete but a limited initial version still must be delivered, with blocked or unassessed boundaries clearly identified.

Not applicable to directly executing tests, generating unsourced rules, replacing a complete test strategy, or accepting risk on behalf of the Human.

Output Format Options

• Default output is Markdown; tables, JSON, or CSV are used only when the user explicitly needs them or the existing delivery format requires them.
• 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

1. Read prompts/boundary-value-testing.md, and provide the goal, scope, materials, environment, and existing evidence.
2. First complete the six-category input audit: known, missing, conflicting, stale, out_of_scope, assumptions.
3. Use BVT-## to record input domain, boundary values, adjacent values, inclusion relationships, units, source evidence, impact, priority, and verification method, preserving source, evidence status, impact/priority, responsible role, closure conditions, and verification method.
4. When materials conflict, constraints are missing, or there is no execution evidence, preserve both sides and the open questions.

Domain Execution Key Points

• Extract upper and lower bounds, inclusion/exclusion, discrete/continuous types, minimum representable step, length encoding, currency precision, time unit/time zone, and sources.
• Deliver rules, units/steps, boundary candidates, validity, and source table; unknown precision must not be filled in as 0.01 or a default time granularity.
• When forming domain candidates, you must read and follow prompts/boundary-value-testing.md domain operations and decision process, preserving legal controls, evidence gaps, and verification actions item by item.

Core Constraints

• Do not invent thresholds, units, or adjacent values without a source, and do not write candidate boundaries as product rules or execution passes.
• File existence, name matching, design declarations, or Eval configuration do not equal real execution evidence.
• Mark unknown items as unassessed, blocked, or to be confirmed; do not fill them in with common sense.
• Do not modify requirements, code, test assets, or the target system.

Pre-Delivery Self-Check

• The six-category input audit has been recorded.
• Each BVT-## has source, minimal evidence, impact/priority, responsible role, closure conditions, and verification method.
• Facts, inferences, recommendations, unexecuted items, and Human decisions have been distinguished.
• Design candidates have not been written as complete tests, execution results, coverage proof, or release conclusions.

Reference Files

• During regression, read evals/eval.yaml and matching cases; configuration does not prove real project results.
• Trigger verification uses evals/trigger-prompts.csv and evals/local-rules.json; report BLOCKED when skill.selection evidence is missing.

Common Misconceptions

• When the scope or evidence is incomplete, do not write method names, file existence, or candidate counts as evidence that tests have been executed, covered, passed, or released.
• 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, actual 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 the source, evidence status, impact/priority, responsible role, closure conditions, and verification method, and clearly state the remaining risk.
• Write verification suggestions as next-step actions, and do not upgrade the Skill package structure, candidate counts, or local Eval configuration into real quality conclusions.