api-negative-testing

API negative testing

Design illegal input, rejection, and degradation candidates from contracts, constraints, and error evidence, and output ANT-## findings. It only organizes traceable API quality candidates; it does not execute tests, nor does it write a design checklist as coverage, pass, or release evidence.

When to use

• Need to extract API negative testing candidates from API contracts, authentication and authorization constraints, parameter rules, error codes, rate limiting rules, historical defects, and raw responses.
• Need to explain the rationale for selection, applicable constraints, evidence gaps, and minimum verification actions.
• Materials are incomplete but a bounded initial version still must be delivered, with blocked or unassessed boundaries stated explicitly.

Not applicable to directly executing tests, generating contracts or behaviors without sources, replacing a complete test strategy, or accepting risk on behalf of a Human.

Output format options

• Default output is Markdown; use tables, JSON, or CSV only when the user explicitly needs them or the existing delivery format requires them.
• Separate static analysis, unexecuted items, evidence status, and Human decisions; keep unassessed, blocked, or NOT_RUN when there is no execution evidence.

How to use

1. Read prompts/api-negative-testing.md, and provide the goal, scope, materials, environment, and existing evidence.
2. First complete the six-category input audit: known, missing, conflicting, stale, out_of_scope, and assumptions.
3. Use ANT-## to record the object, preconditions, behavior of interest, source evidence, and verification method, retaining impact/priority, responsible role, closure conditions, and evidence status.
4. When materials conflict, constraints are missing, or there is no execution evidence, retain both sides and the open questions.

Domain execution key points

• Extract type, required, nullable, range, length encoding, and size constraints field by field, then extract identity/permission and error contracts, noting the source of each.
• Output a "constraint → input variant → expected rejection/allow → response and side-effect observation → verification" table, tracing field rules and permission rules separately.
• When forming domain candidates, you must read and follow the domain operations and decision process of prompts/api-negative-testing.md , retaining legal controls, evidence gaps, and verification actions item by item.

Core constraints

• Do not execute tests, do not assume rules, versions, thresholds, data, or responses that were not provided, and do not treat the number of candidates as proof of coverage.
• File existence, name matching, design declarations, or Eval configuration do not equal real execution evidence.
• Mark unknown items as unassessed, blocked, or open, and do not fill them in with common sense.
• Do not modify requirements, code, test assets, or the target system.

Pre-delivery self-check

• The six-category input audit of known, missing, conflicting, stale, out_of_scope, and assumptions has been recorded.
• Each ANT-## has a source, evidence status, impact/priority, responsible role, closure conditions, and verification method.
• Facts, inferences, recommendations, unexecuted items, and Human decisions have been distinguished.
• Design candidates have not been written as execution results, proof of coverage, or release conclusions.

Reference files

• During regression, read evals/eval.yaml and matching cases; configuration does not prove real project results.
• Trigger validation uses evals/trigger-prompts.csv and evals/local-rules.json; when skill.selection evidence is missing, report BLOCKED.

Common pitfalls

• When the scope or evidence is incomplete, do not write method names, file existence, or candidate counts as evidence that testing has been executed, covered, passed, or released.
• Do not use common sense to fill in rules, thresholds, data, environments, or results that were not provided; retain unassessed, blocked, and to-be-confirmed items.
• Do not expand this Skill's specialized candidates into a complete strategy, complete test cases, actual execution, or a release decision.

Best practices

• Complete the six-category input audit first, then choose the smallest, traceable, and verifiable scope of findings.
• For each finding, retain the source, evidence status, impact/priority, responsible role, closure conditions, and verification method, and clearly state the remaining risk.
• Write verification suggestions as next-step actions, and do not upgrade the Skill package structure, candidate counts, or local Eval configuration into real quality conclusions.