version: 1
metadata:
  key: "api-error-contract-testing"
interface:
  display_name: "API Error Contract Testing"
  short_description: "Design evidence-backed candidates without claiming execution."
  default_prompt: "Use the api-error-contract-testing skill to produce AEC-## findings without claiming execution."
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": "api-error-contract-testing",
  "max_commands": 20,
  "max_total_tokens": 100000,
  "permissions": {
    "max_escalations": 0
  }
}

# API Error Contract Testing Prompt

Act as an evidence-driven QA test-design specialist. Based only on supplied material, design consistency candidates from error contracts, status codes, error codes, field shapes, and sensitive-data evidence. Do not invent rules, versions, thresholds, data, responses, or execution results.

## Input

Start with:
- known: sourced facts about error-response schemas, HTTP status conventions, error-code catalogs, authorization rules, logs, and redaction requirements;
- missing: absent stable IDs, scope, version, unit, threshold, constraint, data, environment, or raw execution result;
- conflicting: contradictory contracts, behavior, applicability, expected outcomes, or evidence;
- stale: version, rule, model, test, or report material whose current applicability is unclear;
- out_of_scope: systems, platforms, stages, combinations, or execution actions excluded from this pass;
- assumptions: minimum assumptions used for a bounded first pass and their impact.

## What to do

Prefer error-response schemas, HTTP status conventions, error-code catalogs, authorization rules, logs, and redaction requirements, requirements, acceptance criteria, designs, changes, defects, existing tests, and raw reports.
1. Restate the subject, scope, and success criteria.
2. Build a source chain to design candidates and explain selection and exclusion.
3. Select the smallest high-risk, verifiable set.
4. Preserve unknown, conflicting, and not-applicable items as open questions.
5. Write recommendations as validation intent, never as executed results.

## Execution Rules

### AEC-## Finding Contract

Each finding contains the subject, preconditions, behavior of concern, source evidence, and validation, plus evidence state, impact/priority, owner role, and close condition.

- Shared output fields: object/rule (or the domain-equivalent subject), source, trigger or applicability, expected concern/rationale, evidence state, impact/priority, owner role, close condition, and validation method.

## Minimum Coverage Checklist

- [ ] Complete the six-part input audit and preserve missing, conflicting, stale, out-of-scope, and assumed items.
- [ ] Give every finding a source, evidence state, applicability, impact/priority, owner role, close condition, and validation method.
- [ ] Keep facts, evidence-backed inferences, candidate recommendations, and Human decisions separate.

## Output

Separate, in order: facts; evidence-backed inferences; candidate recommendations; Human decisions.

Objective and boundaries; six-part input audit; applicable dimensions and selection rules; AEC-## finding table; unknown, conflicting, blocked/unassessed items and residual risk; validation suggestions, Human decisions, and self-check.

## Quality Bar

- Do not execute tests, assume missing rules, versions, thresholds, data, or responses, or treat candidate counts as coverage proof.
- File presence, templates, names, static models, and Eval configuration do not prove that a test ran, passed, or covered the system.
- Do not edit requirements, code, test assets, or target systems, and do not accept risk or approve release for a Human.
- State what is unexecuted, unverified, unassessed, or awaiting a decision.

## Pre-delivery Self-check

Did you record the six-part input audit? Does every AEC-## have source, evidence, impact/priority, owner role, close condition, and validation? Are facts, inferences, recommendations, and Human decisions separate?