negative-scenario-discovery

Negative scenario discovery

Discover, from functional goals, input constraints, permissions, dependency failure contracts, timeouts/retries, idempotency/transactions, and recovery design, the failure, denial, degradation, and unsafe recovery paths that need verification, and output NS-##. It does not write complete test cases, does not execute fault injection, does not invent error codes, and does not declare system behavior correct.

When to use

• When you need to check invalid input, unauthorized access, dependency failure, timeout, retry exhaustion, duplicate requests, partial failure, and data inconsistency.
• When you need to discover, from design or historical failures, failure stimuli and observable results beyond the happy path.
• When you need to organize evidence gaps, recovery options, and Human pending decisions when the failure contract is incomplete.

Not applicable to discovering only boundary values, writing complete test cases, executing fault injection, reviewing real incidents, or deciding final error copy/SLA on behalf of the team.

Output format options

• Default output is Markdown; when the user requests tables, CSV, or JSON, preserve the same evidence, status, impact, responsible role, and verification fields.
• Do not write structured formats or static checklists as execution, pass, approval, or release evidence.

How to use

1. First read this Skill's main Prompt, and provide the goal, scope, materials, environment, and existing evidence.
2. Execute according to the Prompt's input audit and output contract; when information is missing, deliver a bounded initial version.
3. For each finding, retain the source, evidence status, impact, responsible role, closure conditions, and verification method.

How it works

1. Read and follow prompts/negative-scenario-discovery.md, and first perform the six types of input audit.
2. Analyze failure modes, triggering stimuli, preconditions, expected denial/degradation/retry/manual takeover, and data consistency impact.
3. Use NS-## to record the source, evidence status, priority, caller-visible result, and verification method.
4. Distinguish explicit product contracts, evidence-based inferences, choices pending confirmation, and execution prerequisites.
5. When information is insufficient, deliver bounded failure paths, and do not write recommendations as verified behavior.

Core constraints

• Must distinguish invalid input, unauthorized, dependency failure, timeout, retry exhaustion, duplicate request, partial failure, and unsafe recovery (when applicable).
• Do not execute fault injection, do not call real dependencies, and do not modify data or target systems.
• Do not invent error codes, retry counts, timeout thresholds, user copy, SLA, or recovery approval.
• NS-## are negative candidates and evidence requirements, not proof of executed, passed, recovered, or safe.
• Do not expand negative scenario discovery into complete test cases or incident root cause conclusions.

Reference files

• Must read before each output prompts/negative-scenario-discovery.md。
• Read during regression evals/eval.yaml and matching use cases; configuration does not prove the failure path has been executed.
• Trigger verification uses evals/trigger-prompts.csv and evals/local-rules.json; when selection trace is missing, report BLOCKED。

Best practices

• Prioritize high-impact and verifiable gaps, and use minimal experiments or supplementary evidence actions to reduce uncertainty.
• Separate facts, evidence-supported inferences, recommendations, and Human decisions, and avoid escalating assumptions into conclusions.

Self-check before delivery

• Known facts, information gaps, conflicts, outdated information, out-of-scope items, and assumptions have been recorded.
• Each NS-## has failure modes, triggers, preconditions, expected behavior, visible results, data impact, and evidence requirements.
• Retryable, non-retryable, manual takeover, and safe rejection have been distinguished.
• No fault injection was performed, and no error codes/thresholds/recovery results were fabricated.
• The candidate list has not been written as complete use cases, test passes, incident conclusions, or release approvals.

Common pitfalls

• Using a single "return error" to cover all failure modes.
• Listing only exception names without specifying trigger conditions, data consistency, and visible results.
• Treating the existence of code or example responses as a complete error contract.
• Arbitrarily deciding retry, degradation, SLA, or manual takeover strategies in order to give a definitive answer.