reliability-testing

Reliability Testing (Chinese Version)

When to Use

You need to design test analysis or validation preparation around availability objectives, failure modes, exposure windows, and evidence preparation.
You need to deliver a reviewable initial version when materials are incomplete, and clearly state assumptions, gaps, and human decisions.
You need to distinguish static design evidence, planned validation, and execution that has already occurred.

The default output is Markdown, organized by risk, evidence, and priority.
When the user requests a table, CSV, JSON, or ticket format, retain the same finding fields and evidence status.
Before output enters an automated process, first confirm the field schema, enum values, and required fields.

First read prompts/reliability-testing.md, and follow the input audit, coverage checklist, and output order therein.
Extract scope, environment, version, dependencies, constraints, success criteria, and available evidence.
Establish scenarios and judgment criteria for availability objectives, failure modes, exposure windows, and evidence preparation, prioritizing high-impact or hard-to-detect items.
Separate facts, evidence-supported inferences, candidate recommendations, and Human decisions.
When information is insufficient, deliver a limited initial version and list the minimum evidence-gathering actions, without writing recommendations as execution results.

Every execution must read prompts/reliability-testing.md; it is the complete execution specification for this Skill.
When evaluation is needed, read evals/eval.yaml and the matching evals/cases/.
Only read references/, examples/, scripts/, or output-formats.md when the directory actually exists and the task requires it.

Clarify the SLI event/time basis, success/failure definitions, denominator, exclusions, observation window, and objective source; request success rate and time availability cannot be interchanged.
Deliver SLIs with windows/denominators and a failure timeline; any objective comparison or extrapolation must state the applicable conditions.
When forming domain candidates, you must read and follow prompts/reliability-testing.md for the domain operations and judgment process, retaining legitimate controls, evidence gaps, and validation actions item by item.

Only analyze availability objectives, failure modes, exposure windows, and evidence preparation; do not inject faults, do not access real dependencies, and do not call production systems.
Do not fabricate thresholds, availability, recovery time, vulnerability status, or tests that have already been executed.
When evidence is insufficient, use pending confirmation, blocked, or unassessed, and provide the validation method.
Any risk acceptance, release approval, and human takeover must be left to the Human.

The six categories of input audit have been completed and evidence timeliness has been marked.
Reliability objectives, failure modes, expected focus points, and validation methods have been covered.
Facts, inferences, recommendations, gaps, and Human decisions have been distinguished.
Static design or dry-run has not been written as real execution, passing, or release conclusions.

Treating adjacent performance, incident, or API analysis as a complete substitute for reliability testing.
Listing only steps, without writing trigger conditions, expected results, responsible roles, and closure conditions.
When information is insufficient, refuse directly, or use template assumptions to fill in the key facts.

Start with the paths most likely to cause business loss or recovery failure.
Use minimal, isolated, rollback-capable validation recommendations, and record stop conditions.
Enable another engineer to review each conclusion based on evidence and boundaries.