English version: See the corresponding English skill.
When to Use
- You need to land API test results into a pytest automation structure.
- The project leans Python, or you want the output to directly fit pytest.
Generation and Execution Boundaries
The generated script only generates smoke assertions for known fields: non-empty endpoints and explicit expected_statuses must be provided; expected_json and source-based max_response_ms may be provided. When data is missing, parameters/variables are unresolved, or response_schema is pending implementation, generate a failure artifact and exit non-zero; it must not run green. Read references/generator-contract.mdfirst; targets and credentials must be explicitly configured.
Execution Workflow
- Read and follow the main prompt in "Load on Demand" (coverage checklist, output structure, quality requirements).
- Only supplement project context that truly affects the result: scope, environment, constraints, risks, dependencies, expected outputs.
- When information is incomplete, first give a usable initial version and explicitly mark assumptions and information gaps.
- Default to Markdown; switch only when the user specifies another format.
Core Constraints
- Prioritize by risk/business impact; do not spread evenly.
- Write "confirmed facts" and "current assumptions" separately.
- Do not fabricate interfaces, fields, environments, or root cause details the user did not provide.
- Always use placeholders or environment variable semantics for authentication and keys; hardcoding real credentials is prohibited.
- Results must be actionable: scenarios specific, prioritized, and able to guide next steps.
Load on Demand
- Before producing output, you must read and follow
prompts/api-test-pytest.md(minimum coverage checklist, output structure, quality requirements). - When you need to apply an existing template: read the matching template in
output-templates/; do not invent a conflicting structure. - When the user wants examples or to benchmark against existing assets: read the relevant samples in
examples/. - When you need in-depth material such as framework specifications, troubleshooting, or report schema: read only the files in
references/relevant to the current problem; do not read through the entire directory. - When you need format conversion or auxiliary validation: prefer using the existing scripts in
scripts/rather than rewriting them. - When you need to evaluate/regress this skill: use
evals/, and validate and run with skill-up.
Pre-delivery Self-check
- Has followed the main prompt's output structure
- Minimum coverage focus: module structure, fixture strategy, authentication handling, high-priority interfaces, positive scenarios, exception and boundary scenarios, assertion focus, test data strategy… (details are subject to the main prompt)
- Has covered the minimum checklist, or indicated why it is omitted
- High-risk items have clear priorities
- No details have been fabricated that the user did not provide
- Assumptions and information gaps have been marked
Common Pitfalls
- When neither scope nor context is clear, do not pretend it is already fully usable.
- Do not write all items as equally important.
- Do not skip assumptions and information gaps.
- Do not output large sections of vague theory unrelated to the current toolchain.