state-transition-testing

State Transition Test Design

Discover test candidates for reachable, unreachable, and exceptional transitions from states, events, guards, and actions, and output STT-## 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

• When State Transition Test Design candidates need to be extracted from state models, events, guard conditions, actions, roles, error transitions, and state persistence evidence.
• When selection rationale, applicable constraints, evidence gaps, and minimal verification actions need to be explained.
• When materials are incomplete but a limited initial version must still be delivered, with blocked or unassessed boundaries clearly stated.

Not applicable to directly executing tests, generating rules without sources, 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.
• Keep static analysis, unexecuted items, evidence status, and Human decisions separate; when there is no execution evidence, keep it unassessed, blocked, or NOT_RUN.

How to Use

1. Read prompts/state-transition-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, and assumptions.
3. Use STT-## to record state, event, precondition guard, action, target state, reachability, source evidence, 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 Points

• Establish a sourced state/event/guard/action/target matrix, marking initial and terminal states, persistence, and the atomicity contract on failure.
• Deliver tables of valid/invalid transitions and guard boundaries; state transitions and business side effects must be compared together.
• When forming domain candidates, it is mandatory to read and follow the domain operations and determination process of prompts/state-transition-testing.md , preserving legitimate comparisons, evidence gaps, and verification actions item by item.

Core Constraints

• Do not invent states or events, do not treat static state diagrams as runtime results, and do not claim that all paths have been executed.
• File existence, name matching, design declarations, or Eval configuration do not equal real execution evidence.
• Mark unknowns as unassessed, blocked, or pending confirmation; 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 STT-## 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 test cases; configuration does not prove real project results.
• For trigger verification, use evals/trigger-prompts.csv and evals/local-rules.json; when skill.selection evidence is missing, report BLOCKED.

Common Pitfalls

• When 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 pending-confirmation 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 categories of 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 residual risk.
• Write verification recommendations as next-step actions, and do not upgrade the Skill package structure, number of candidates, or local Eval configuration into actual quality conclusions.