api-contract-testing

API Contract Testing (Chinese Version)

When to Use

You need to verify contract consistency between API providers and consumers regarding schema, semantics, compatibility, and evolution strategy.
You need to conduct a risk review of existing solutions, results, or evidence, and form actionable improvement items.
The input is incomplete, but a usable initial version with assumptions and information gaps still needs to be provided first.

The default output is Markdown, suitable for review, execution, and continuous supplementation.
When the user requests a table, CSV, JSON, or ticket format, retain the same risk, evidence, priority, and boundary fields.
If the output will enter an automated process, first confirm the field schema, enum values, and required items.

First read and follow prompts/api-contract-testing.md 's input, execution rules, minimum coverage checklist, and output order.
Supplement the scope, environment, version, constraints, evidence, and success criteria that truly affect judgment.
First conduct an input audit, then distinguish confirmed facts, reasonable assumptions, and questions to be confirmed.
Sort by risk and evidence strength, and produce results that can be directly executed, reviewed, or verified.
When information is insufficient, do not stop at asking questions: first deliver a limited initial version, and explain which conclusions cannot currently hold.

Each execution must read prompts/api-contract-testing.md; it is the complete execution specification of this Skill.
When this Skill needs to be evaluated or regressed, read evals/eval.yaml and the matching evals/cases/ test cases.
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

A contract is not only a schema; it also includes semantics and error behavior
Do not infer the complete contract from samples
Breaking changes must be given a migration path
Do not fabricate system behavior, fields, data, metrics, or root causes that do not exist in the input.
Key conclusions must be linked to evidence; when evidence is insufficient, mark them as assumptions and provide verification methods.
Priority must explain the basis in terms of business impact, likelihood of occurrence, or detectability.

Covered: fields and types, required and nullable, enums, status codes, error bodies, compatibility, version evolution, consumer impact.
Facts, assumptions, gaps, and recommendations have been distinguished.
High-risk items have clear priority, evidence, owner, or next step.
The output contains verifiable judgment criteria, rather than vague generalities.
No unauthorized production write operations or destructive actions were performed.

Only listing checkpoints without explaining input conditions, expected results, or evidence.
Marking everything as high priority, losing the value of trade-offs.
Replacing domain judgment with tool names or general theories.
Directly refusing when the input is incomplete, or conversely pretending the conclusions are already certain.

Start from the paths most likely to cause business loss, security issues, or release blockage.
Use the smallest verifiable experiments to reduce uncertainty, and record reproduction conditions.
Enable the output to be directly executed and reviewed by another engineer.