Untested on Argon. The template and illustrative output below are editorial examples; no model response is represented as a test result.
Prepare the inputs
Replace every bracketed field. Provide the failing command, actual error and expected behavior. If no command execution tool is available, include the relevant files and test output and ask for a proposed patch only.
Keep the instruction separate from the supplied task material. Check availability in your chosen product, and only provide data that product is authorized to process. This template does not connect tools or change application permissions.
The prompt
Copy the template and replace every bracketed field before use.
Task: fix this reproducible defect in [repository and revision].
Failure: [command and actual output].
Expected behavior: [observable acceptance criteria].
Scope: [permitted files and any files that must stay unchanged].
Available tools: [explicitly allowed tools and commands].
Budget: [time, attempts, or spending limit].
First inspect the relevant code and callers. Explain the likely cause
briefly, then propose the smallest change that addresses that cause.
Use only the supplied tools and permissions. Do not weaken existing
checks, expose credentials, deploy, or edit unrelated files.
Run the original failing check and relevant nearby checks if execution
is available. Report checks as not run when you cannot execute them.
Stop for missing access, an unclear requirement, or the stated budget.
Return: cause, proposed diff, checks actually run and their results,
remaining uncertainty, and the next review step.An illustrative output example
For a checkout that rejects an empty cart, replace “expected behavior” with “return the existing validation error before attempting payment.” The result should identify the validation path and show the unchanged payment boundary; it should not invent a successful payment test.
How to judge the result
- Reproduce the original failure before accepting the change.
- Reject patches that bypass the check or alter unrelated behavior.
- Require actual command output for any claim that tests passed.
If the result fails a check, record the failure before refining the prompt. Keep the same inputs and acceptance criteria when comparing models. Do not mistake an attractive output format for a correct result.