English version: See the corresponding English skill.
When to Use
- You need to land API test results into a Bruno structure or Bruno workflow.
- The project is already using Bruno, or you want the output to directly fit Bruno.
Generation and Execution Boundaries
The generation script only generates 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, generate a failure artifact and exit non-zero; it must not run green. First read references/generator-contract.md, and targets 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 result: scope, environment, constraints, risks, dependencies, expected deliverables.
- When information is incomplete, first provide 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 effort 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: scenarios specific, prioritized, and able to guide the next step.
Load on Demand
- Before producing output, you must read and follow
prompts/api-test-bruno.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/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 concerns: collection structure, environment setup, authentication handling, high-priority interfaces, positive scenarios, exception and boundary scenarios, variable and data strategy, assertion focus… (details are subject to the main prompt)
- The minimum checklist has been covered, or it is stated why items were omitted
- High-risk items have clear priorities
- No details the user did not provide have been fabricated
- Assumptions and information gaps have been marked
Common Pitfalls
- When both scope and context are unclear, 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 stretches of vague theory unrelated to the current toolchain.