Negative Scenario Discovery
Use it to examine invalid input, unauthorized access, dependency failure, timeout, retry exhaustion, duplicate request, partial failure, and inconsistency.
StatusStable
TypeAtomic Skill
DomainSoftware testing
SDLCTest design
Good forSRE / DevOps
LanguageChinese / English
EvalsEvals ✓
Synced2026-09-15
Why this Skill
It turns this Skill's method into a quality input that can be executed, reviewed, and reused.
- 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.
- Using one generic “return an error” path for every failure mode.
When to use
Use this Skill
- 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.
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.
Input
Minimum Input
- The current task scope, objective, and subject under review.
Recommended Input
- Project goal
- Test scope
- Constraints
Optional Context
- Relevant code or configuration
- Historical results
- Logs and metrics
Output
The output follows this Skill's method and makes facts, assumptions, risks, and next steps explicit.
These are the Skill's expected output requirements, not evidence that it ran in a real project.
- 01Read and follow prompts/negative-scenario-discovery.md, beginning with the six-part input audit.
- 02Analyze failure mode, stimulus, preconditions, expected rejection/degradation/retry/handoff, and consistency impact.
- 03Record source, evidence state, priority, caller-visible result, and validation in NS-## entries.
- 04Separate explicit product contracts, evidence-based inference, open choices, and execution prerequisites.
View full output structure
- 05Deliver bounded failure paths when information is missing; never present a recommendation as verified behavior.
How It Works
- 01Read and follow prompts/negative-scenario-discovery.md, beginning with the six-part input audit.
- 02Analyze failure mode, stimulus, preconditions, expected rejection/degradation/retry/handoff, and consistency impact.
- 03Record source, evidence state, priority, caller-visible result, and validation in NS-## entries.
- 04Separate explicit product contracts, evidence-based inference, open choices, and execution prerequisites.
- 05Deliver bounded failure paths when information is missing; never present a recommendation as verified behavior.
Install & Quick Start
Install command / SHELL
npx skills add \
https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/negative-scenario-discovery
-gnegative-scenario-discovery.prompt
@skill negative-scenario-discovery
Using the current project context, produce an actionable result following this Skill.
Additional context:
[Paste project context or requirement]---
name: negative-scenario-discovery
description: Use this skill when you need to discover invalid, denied, failed, degraded, or unsafe-recovery scenarios from product evidence; triggers include negative scenario discovery.
---
# 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.