Failover Testing

When to Use

• Use this Skill when the work needs evidence-bounded analysis of primary-secondary triggers, traffic transfer, data consistency, and recovery evidence.
• Use it when the input is incomplete but a reviewable first draft with assumptions and gaps is still useful.
• Use it when static design evidence must remain separate from planned validation and completed execution.

Output Format Options

• Default to Markdown organized by risk, evidence, and priority.
• If the user asks for a table, CSV, JSON, or ticket format, preserve the same finding fields and evidence states.
• Confirm the schema, enum values, and required fields before feeding the output to automation.

How to Use

1. Read prompts/failover-testing.md and follow its input audit, coverage checklist, and output order.
2. Extract scope, environment, version, dependencies, constraints, success criteria, and available evidence.
3. Model primary-secondary triggers, traffic transfer, data consistency, and recovery evidence with scenarios and decision criteria, prioritizing high-impact or hard-to-detect items.
4. Separate facts, evidence-backed inferences, candidate recommendations, and Human decisions.
5. When information is missing, deliver a bounded draft and the smallest evidence-gathering actions; do not write recommendations as execution results.

Reference Files

• Read prompts/failover-testing.md for every invocation; it is the complete execution contract.
• Read evals/eval.yaml and the matching evals/cases/ when evaluating the Skill.
• Read references/, examples/, scripts/, or output-formats.md only when the directory exists and the task needs it.

Core Constraints

• Analyze only primary-secondary triggers, traffic transfer, data consistency, and recovery evidence; do not inject faults, access real dependencies, or call production systems.
• Do not invent thresholds, availability, recovery times, vulnerability states, or completed test runs.
• Mark unsupported claims as pending, blocked, or unassessed and provide a validation method.
• Leave risk acceptance, release approval, and Human takeover to a Human.

Delivery Self-Check

• Complete the six-part input audit and mark evidence freshness.
• Cover the failover path, failure modes, expected concerns, and validation method.
• Separate facts, inferences, recommendations, gaps, and Human decisions.
• Do not turn static design or a dry-run into a claim of execution, passing, or release.

Common Pitfalls

• Treating adjacent performance, incident, or API analysis as a complete substitute for Failover Testing.
• Listing steps without triggers, expected results, owner roles, or close conditions.
• Refusing incomplete input, or filling critical facts with template assumptions.

Best Practices

• Start with the paths most likely to cause business loss or recovery failure.
• Use the smallest isolated and reversible validation suggestion, with explicit stop conditions.
• Make every conclusion reviewable by another engineer from its evidence and boundary.