Measure the gap between a rule on paper and how you actually trade it

How it works

1. Pick one rule you already trade and have written down, with a setup tag in your journal. Run it through an honest historical test first (see the quick rule backtest entry), over the same months as your journal.
2. You write and unit-test {{gap_script}} yourself before the first monthly run, then re-use it each month. Claude Code only runs the saved script; it does not write, change or debug it. Trades are matched on symbol plus entry date within one session, and the symbol never leaves the script.
3. Each input CSV has entry_date, exit_date, r_multiple, setup_tag, symbol (for matching only), entry_price, exit_price and risk_per_share (the rule's original risk per share). For matched long trades the script computes the entry-timing gap as (rule entry_price minus your entry_price) divided by the rule's risk_per_share, and the exit-timing gap as (your exit_price minus rule exit_price) divided by the same risk. If a price or risk field is missing, it reports the total R difference only and marks the split "not computed".
4. Dry-run the script on the backtest CSV and your trades CSV for the same dates and setup tag, and confirm matches and R figures on a small set of hand-checked trades before a monthly run.
5. The agent reports only the script output: matched, missed, extra, and timing gaps, each with count, average R, and n. It does not name a largest source or describe causes.
6. You decide whether to change a checklist, edit the playbook, or do nothing. The agent shows the finished report and the journal file path first, and appends it under the month only after you confirm.

Copy-paste prompt

You compare one of my written rules with how I actually traded it. You do not give trading advice, you never
place orders, and you never produce a list of current or future trades.

Inputs: {{rule_file}} (my written rule), {{backtest_trades_csv}} (trades the rule would have taken, from an
honest historical test), {{my_trades_csv}} (my closed trades from my broker export), {{journal_path}} (setup tags).
Both CSVs include entry_date, exit_date, r_multiple, setup_tag, symbol (matching only), entry_price, exit_price,
and risk_per_share (the rule's original risk per share).
Period: {{start_date}} to {{end_date}}. Setup tag: {{setup_tag}}.

1. Run {{gap_script}}. Use only its output for numbers, with n next to each figure.
2. Report: matched, missed (rule qualified, I didn't take it), extra (I took it, rule didn't qualify),
   and for matched trades the timing gaps the script computes. The script, not you, must already implement:
   entry-timing gap = (rule entry_price - my entry_price) / rule risk_per_share;
   exit-timing gap = (my exit_price - rule exit_price) / rule risk_per_share. Do not refit the stop.
   If entry_price, exit_price, or risk_per_share is absent, print total R difference only and label the split
   "not computed". Do not calculate either gap yourself.
3. If any group has fewer than {{min_sample}} trades, write "insufficient sample" for it.
4. Refer to dates and journal rows only, never to instrument names.
5. Report only the four group statistics (matched, missed, extra, timing gaps), sample sizes next to every
   figure, and nothing else. Provide no descriptions of causes or largest source.
6. Show me the full report and the journal file path it would be written to under {{journal_path}}. Do not
   write the file.
7. Only after I reply "save", show a dry-run/diff of appending the report under the month in {{journal_path}},
   and write only after I confirm that diff.

Guardrails

• All numbers come from code. The model only reads the script's figures back, with sample sizes shown, and does not name causes or a largest source.
• It is backward-looking only. No scans, no lists of current candidates and nothing about future trades.
• The rule is never tuned or "optimised" by the agent. It describes the gap between the rule and you, and you decide.
• The agent reads your exports and journal. It has no broker access and cannot place orders.
• Reports refer to dates and journal rows, never to instrument names, and stay private.
• The only write is the monthly report to your own journal, and it happens only after you have seen the report and confirmed the save.
• The gap_script must be written and unit-tested by the user; the agent may not generate, modify or debug it. All alignment logic stays under user control.

What can go wrong

The comparison is only as good as the historical test behind it. If the backtest quietly uses information from later in the day, the rule looks better on paper than any person could trade it, and the "gap" is really a bug. Run the look-ahead checks from the quick rule backtest first. The other trap is tagging: trades tagged with the setup after the fact, because they worked, make "extra" trades vanish. Tag at entry, or the numbers flatter you. There is also a privacy and regulatory risk. Broker exports and journal contents are sensitive personal records, and sending them to a cloud model means they leave your machine; check your provider's data-retention and training terms, and consider stripping account numbers and anything identifying before any upload. Finally, do not trust the agent's explanations until you have independently validated the gap_script against a small set of hand-checked trades, confirming its matching and R figures by hand before relying on a monthly run.

Source and references