Make your agent prove a new script works by running it, not describing it

How it works

1. Keep a small test file for each script you rely on: three to five cases you worked out by hand, with the inputs and the exact output you expect (for example, the share count for a given account size, risk per trade and stop distance, or the R-multiple of a closed trade).
2. After any session in which the agent writes or edits that script, tell it to stop explaining and run the script the way you will use it: your command, your entry point, on the test file.
3. It pastes the raw command and raw output, then lines each result up against your expected number as match or mismatch. A description of the code, or "this should work", doesn't count.
4. It also runs one case that only the new code can handle, to show the command you use actually reaches the new code and not an old copy.
5. Any mismatch, error or unreached code means the session isn't finished. You decide whether to fix it now or roll back to the previous version.
6. Every bug you find becomes a new test case, so the next check covers it.

Copy-paste prompt

Before we finish, prove the change works. Do not describe the code and do not tell me it should work.

Script: {{script_path}}. The command I actually use: {{command}}.
Test cases: {{test_file}} (inputs and the output I expect, worked out by hand).
New behaviour to prove: {{new_feature_case}} (a case only the new code can handle).

1. Run exactly my command on each test case. Paste the raw command and the raw output.
2. Make a table: case, expected, actual, match or mismatch.
3. Run the new-behaviour case and show from the output that it went through the new code path.
4. If any case mismatches, errors or doesn't reach the new code, write "not done" and list what failed.
Do not edit the test file or my expected numbers, and do not run anything against a live account.
This is about my own tools; add no trading suggestions of any kind.

Guardrails

• Expected numbers come from your hand-checked test file, and the agent may not edit them.
• You see the raw command and raw output, not a summary.
• Checks run on test inputs only, never against a live account. The scripts here only read files and cannot place orders.
• A mismatch means not done, whatever the explanation.

What can go wrong

Coding agents are good at writing a function and bad at noticing that nothing calls it, or that your command still loads an older copy. Reading the code, or the agent's summary of it, misses both. The other trap is an agent "fixing" a failing case by changing the expected value, which is why the test file is off-limits and the expected numbers are yours. Three passing cases don't prove the edge cases either; add one each time something breaks.

Source and references