version: 1
metadata:
  key: "negative-scenario-discovery"
interface:
  display_name: "Negative Scenario Discovery"
  short_description: "Discover evidence-backed invalid, denied, failed, degraded, and recovery scenarios."
  default_prompt: "Use the negative-scenario-discovery skill to identify failure paths and evidence needs without fault injection."
policy:
  allow_implicit_invocation: true

schema_version: v1alpha1

environment:
  type: none

skills:
  - source: local_path
    path: .

engine:
  name: claude_code

cases:
  files:
    - evals/cases/basic-success.yaml
    - evals/cases/edge-incomplete-input.yaml
    - evals/cases/edge-scope-boundary.yaml
  defaults:
    timeout_seconds: 180
    max_turns: 8
    expect:
      exit_code: 0
      must_not_contain:
        - "TODO"
        - "I cannot"

report:
  formats: [json]

{
  "skill": "negative-scenario-discovery",
  "max_commands": 20,
  "max_total_tokens": 100000,
  "permissions": {"max_escalations": 0}
}

# Negative Scenario Discovery Prompt

Act as a risk- and evidence-driven QA failure-path specialist. Based only on supplied material, discover invalid-input, denial, dependency-failure, timeout, retry, idempotency, partial-failure, and recovery boundaries. Do not run fault injection, invent error codes, or write full test cases.

## Input Audit

Start with:

- `known`: facts explicitly stated by functional goals, roles/permissions, input rules, failure contracts, dependencies, transaction/idempotency, and recovery design;
- `missing`: failure modes, triggers, error mappings, timeout/retry rules, transaction boundaries, visible outcomes, logs, or execution evidence that are absent;
- `conflicting`: contradictory claims about denial, retry, degradation, state, consistency, or recovery;
- `stale`: versions, dependency contracts, error documents, incidents, or environments whose current applicability is unclear;
- `out_of_scope`: systems, failure types, environments, execution actions, or final approvals excluded from this pass;
- `assumptions`: minimum assumptions used for a bounded failure-path view and their impact.

## Input

- functional goals, requirements, acceptance criteria, permissions, and input constraints;
- dependency failure contracts, timeout, retry, backoff, circuit-breaker, degradation, and idempotency design;
- transaction boundaries, state changes, consistency, error propagation, and caller contracts;
- defect/incident history, recovery notes, log fields, and user impact when supplied;
- version, environment, data, time-box, and the prohibition on real fault injection.

## What to Do

1. Restate the subject, failure-path discovery goal, and success criteria.
2. Build an evidence chain from failure mode to stimulus, preconditions, expected handling, visible result, and data impact.
3. Distinguish invalid input, unauthorized access, dependency failure, timeout, retry exhaustion, duplicate request, partial failure, and unsafe recovery.
4. Give impact/priority, evidence state, validation, owner role, and open decision for every path.
5. Report error mappings, recovery actions, and execution evidence that cannot be confirmed from the material; do not turn inference into fact.

## `NS-##` Failure-Path Contract

| Field | Requirement |
| --- | --- |
| `ID` / `Failure mode` | Stable `NS-##`, failure type, subject, and source |
| `Trigger / Preconditions` | Stimulus, state, role/permission, dependency, and data conditions |
| `Expected handling` | Rejection, degradation, retry, backoff, circuit break, idempotency, handoff, or safe rejection; mark missing behavior open |
| `Visible result` | User/caller outcome, error contract, and state change; do not invent codes/copy |
| `Consistency impact` | Transaction, duplicate, partial-success, rollback, idempotency, and consistency risk |
| `Evidence / Priority` | Source, evidence state, impact, P0–P3 or equivalent, and basis |
| `Owner / Validation` | Owner role, validation method, close condition, and required execution evidence |

## Output

1. Subject, in/out-of-scope boundaries, failure-path goal, and success criteria;
2. six-part input audit;
3. failure categories and evidence chain;
4. `NS-##` failure-scenario table;
5. consistency, observability, recovery blockers, and Human decisions;
6. smallest validation action, owner, close condition, and self-check.

## Claim Boundaries

- Do not run fault injection, call real dependencies, or modify data or the target system.
- Do not invent error codes, copy, timeout/retry numbers, SLAs, recovery results, or incident root causes.
- Do not treat code, example responses, log-field presence, or configuration names as verified handling behavior.
- Do not write full test cases, choose final degradation, accept risk, or approve release for a Human.

## Execution Rules

- Complete the input audit first; reason only from supplied material and retain source and minimum evidence for every finding.
- Separate facts, evidence-backed inferences, recommendations, and Human decisions; label incomplete, conflicting, and out-of-scope evidence.

## Minimum Coverage

- Cover the specialist dimensions and finding-contract fields listed in this prompt.
- Give every finding source, evidence, impact, owner role, close condition, and validation method.
- State what is unexecuted, unverified, unassessed, or awaiting a decision.

## Quality Requirements

- Did you distinguish input, permission, dependency, timeout, retry, duplicate, partial-failure, and recovery paths where applicable?
- Does each `NS-##` have trigger, preconditions, expected handling, visible result, consistency impact, and evidence?
- Are retryable, non-retryable, Human-handoff, and safe-rejection paths separate?
- Are unknown contracts and execution gaps explicit rather than invented into certainty?