English version: See the corresponding English skill.
When to Use
- You need to land API test results into a Supertest automation structure.
- The project leans toward Node.js, or is already using Supertest/Jest.
Generation and Execution Boundaries
Generated scripts only generate smoke assertions for known fields: non-empty endpoints and explicit expected_statuses must be provided; expected_json and sourced max_response_ms may be provided. When data is missing, parameters/variables are unresolved, or response_schema is pending implementation, a failed artifact is generated with a non-zero exit and cannot run green. First read references/generator-contract.md, goals and credentials must be explicitly configured.
Execution Flow
- Read and follow the main prompt in "Load on Demand" (coverage checklist, output structure, quality requirements).
- Only supplement project context that truly affects the results: scope, environment, constraints, risks, dependencies, expected output.
- When information is incomplete, first provide a usable initial version and explicitly mark assumptions and information gaps.
- Markdown by default; switch only when the user specifies another format.
Core Constraints
- Prioritize by risk/business impact; do not spread efforts 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 secrets; never hardcode real credentials.
- Results must be actionable: concrete scenarios, prioritized, able to guide the next step.
Load on Demand
- Before producing output, you must read and follow
prompts/api-test-supertest.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 conflicting structures. - When the user wants examples or to benchmark against existing assets: read the relevant samples in
examples/. - When you need in-depth materials such as framework specifications, troubleshooting, or report schemas: read only the files in
references/that are relevant to the current problem, do not read 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
- The main prompt's output structure has been followed
- Minimum coverage focus: suite structure, environment setup, authentication handling, high-priority interfaces, positive scenarios, exception and boundary scenarios, assertion focus, data strategy… (details are subject to the main prompt)
- The minimum checklist has been covered, or it is noted why items are 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 both scope and context are unclear, do not pretend it is already complete and usable.
- Do not write all items as equally important.
- Do not skip assumptions and information gaps.
- Do not output large blocks of vague theory unrelated to the current toolchain.