Negative Scenario Discovery

Discover failure, denial, degradation, and unsafe-recovery paths from goals, input constraints, permissions, dependency contracts, timeout/retry, idempotency/transaction, and recovery design. Produce NS-##. Do not write full test cases, run fault injection, invent error codes, or declare behavior correct.

When to Use

• Use it to examine invalid input, unauthorized access, dependency failure, timeout, retry exhaustion, duplicate request, partial failure, and inconsistency.
• Use it to find failure stimuli and observable outcomes outside the happy path from designs or past failures.
• Use it when failure contracts are incomplete and evidence gaps, recovery choices, and Human decisions must be explicit.

Do not use it only to find boundary values, write full cases, run fault injection, conduct a real incident review, or choose final copy/SLA for a team.

Output Format Options

• Use Markdown by default; when a table, CSV, or JSON is requested, preserve the same evidence, status, impact, owner, and validation fields.
• Do not present a structured format or static inventory as execution, pass, approval, or release evidence.

How to Use

1. Read this Skill's primary prompt and provide the objective, scope, material, environment, and available evidence.
2. Follow the prompt's input audit and output contract; deliver a bounded first pass when information is incomplete.
3. Retain source, evidence status, impact, owner role, close condition, and validation method for every finding.

Workflow

1. Read and follow prompts/negative-scenario-discovery.md, beginning with the six-part input audit.
2. Analyze failure mode, stimulus, preconditions, expected rejection/degradation/retry/handoff, and consistency impact.
3. Record source, evidence state, priority, caller-visible result, and validation in NS-## entries.
4. Separate explicit product contracts, evidence-based inference, open choices, and execution prerequisites.
5. Deliver bounded failure paths when information is missing; never present a recommendation as verified behavior.

Core Constraints

• Distinguish invalid input, unauthorized access, dependency failure, timeout, retry exhaustion, duplicate request, partial failure, and unsafe recovery when applicable.
• Do not run fault injection, call real dependencies, or modify data or the target system.
• Do not invent error codes, retry counts, timeout thresholds, user copy, SLAs, or recovery approval.
• NS-## is a negative candidate and evidence need, not proof of execution, pass, recovery, or safety.
• Do not expand negative discovery into full test cases or an incident root-cause conclusion.

Reference Files

• Always read prompts/negative-scenario-discovery.md before producing an analysis.
• For regression, read evals/eval.yaml and matching cases; configuration does not prove failure paths ran.
• For trigger checks, use evals/trigger-prompts.csv and evals/local-rules.json; missing selection trace is BLOCKED.

Best Practices

• Prioritize high-impact gaps with a verifiable next action, using the smallest useful experiment or evidence request.
• Separate facts, evidence-backed inferences, recommendations, and Human decisions; never upgrade an assumption into a conclusion.

Pre-delivery Check

• Recorded known facts, missing information, conflicts, stale information, out-of-scope items, and assumptions.
• Each NS-## has failure mode, trigger, preconditions, expected handling, visible result, consistency impact, and evidence need.
• Retryable, non-retryable, Human-handoff, and safe-rejection paths are separate.
• No fault injection was run and no error code, threshold, or recovery result was invented.
• The candidate list is not presented as full cases, passed tests, incident conclusions, or release approval.

Common Pitfalls

• Using one generic “return an error” path for every failure mode.
• Listing exception names without trigger, consistency impact, or visible result.
• Treating code presence or an example response as a complete error contract.
• Choosing retry, degradation, SLA, or Human-handoff policy merely to give a definite answer.