agent-failure-recovery-testing

Agent Failure Recovery Test (Chinese Version)

When to Use

When evidence-based analysis, design, or verification preparation is needed around failure classification, retry/fallback/escalation, state consistency, user notification, and recovery evidence.
When an Agent, RAG, or LLM solution, result, or evidence needs review, and actionable improvement items need to be formed.
When input is incomplete but a constrained initial version with assumptions, information gaps, and human decision boundaries still needs to be delivered.

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

First read and follow prompts/agent-failure-recovery-testing.md, including input audit, domain coverage, and output order.
Extract scope, environment, version, time window, constraints, success criteria, and available evidence, with focus on failure classification, retry and fallback, escalation paths, state consistency, and user notification.
First distinguish confirmed facts, evidence-supported inferences, candidate recommendations, and Human decisions, then sort by risk and evidence strength.
Convert high-risk items into preconditions, steps, expected results or judgment criteria, required evidence, and verification methods.
When information is insufficient, deliver a constrained initial version, clarify which conclusions cannot hold, and do not write static materials as execution results.

When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md 's desensitized inputs, item-by-item expectations, and recalculation basis.
Every execution must read prompts/agent-failure-recovery-testing.md; it is the complete execution specification of this Skill.
When evaluation is needed, read evals/eval.yaml and the matching cases under evals/cases/ .
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

Establish a Failure | Whether Write Is Confirmed | Retryability | Retry/Compensation/Escalation | Post-Recovery State | Required Evidence table according to the project protocol; separate temporary errors, permanent errors, and uncertain results.
A timeout cannot lead to the conclusion that execution did not occur: first query committed side effects using operation_id/idempotency key, then decide whether to read back the result or safely retry; the same key must not produce a second business write.
Verify partial success against completed steps and remaining steps; execute compensation only when the protocol and authorization permit it, record compensation results step by step, and escalate on failure.
Permanent errors stop retrying as-is and notify the responsible person. Verify business state, retry count, user-visible results, and resources before and after recovery; if logs are missing, recovery remains unverified.

Only analyze failure classification, retry/fallback/escalation, state consistency, user notification, and recovery evidence; do not replace the business owner's or Human's risk acceptance, exception approval, and safety decisions.
Do not fabricate system behavior, fields, model outputs, data, thresholds, root causes, execution records, or pass conclusions.
Static design, plans, file existence, or dry-run can only retain the original evidence status and cannot be upgraded to proof of real execution.
When evidence is insufficient, use pending confirmation, blocked, unassessed, or NOT_SCORED, and provide the minimum verification method.
When user data, production, or security is involved, use least privilege, desensitized data, mocks, dry-run, or an isolated environment.

Failure classification, retry and fallback, escalation paths, state consistency, and user notification are covered, with source, evidence status, and verification method recorded for each item.
Facts, inferences, candidate recommendations, information gaps, and Human decisions are separated.
High-risk items have P0/P1/P2/P3 or equivalent priority, responsible role, and closure conditions.
Plans, static checks, or dry-runs are not written as test execution, all passed, or security approval.
Residual risk, stop/escalation conditions, and next steps are stated.

Listing only checkpoints without stating trigger conditions, expected focus points, responsible roles, closure conditions, and evidence.
Treating test or model tool names from adjacent domains as the complete judgment for Agent failure recovery.
Using unexplained numbers to create false precision, or writing correlation as causation.
Directly refusing when the input is incomplete, or conversely pretending the conclusion is already certain.

Start from the path most likely to cause user harm, business loss, or decision blockage.
Use the smallest verifiable experiment to reduce uncertainty, and record conditions, versions, sources, and evidence.
Enable another engineer to independently install, execute, and review the outputs of this Skill.