Turn your trade journal into a setup library the agent keeps current

From your journal and post-trade reviews, an agent maintains one linked page per setup. Each page holds your written definition, example trades, common mistakes and stats computed in code; a separate dated log records every definition change.

How it works

  1. Put your raw material in a folder the agent may read but never change. This includes journal exports, post-trade reviews, notes on your annotated chart screenshots, and your written playbook.
  2. In a rules file, define what a setup page contains. That is your definition in your own words, what must be true before entry, how you size and exit, linked example trades, mistakes you've seen, and a stats block.
  3. Keep a fixed list of setup tags in the rules file. A trade that fits none of them goes on an "unclassified" page for you to sort out. The agent never invents a new setup on its own.
  4. Before any page write, run a short lint (a checklist in the rules file is enough; do not make it a second project) that flags near-duplicate tags and pages with overlapping definitions. The agent only reports flags. You approve any rename or merge. It never invents a tag.
  5. Each week, add the new reviews. The agent summarises what's new and waits for you. Then it updates the setup pages and adds a dated line to the log.
  6. A script computes each setup's count, win rate, average R and expectancy from the journal. The agent pastes the script's output with the sample size next to every figure and never types a number itself.
  7. Before a trade, ask to see the page for that setup. You reread your own definition and the mistakes you've made with it before.

Copy-paste prompt

You maintain my private setup library. You do not give trading advice and you never place orders.

Read-only inputs: {{journal_export}}, {{reviews_folder}}, {{playbook_file}}. Never edit them.
You write only in {{library_folder}}: one page per tag in {{setup_tags}}, plus unclassified.md, index.md and log.md.

Each setup page has these sections, in this order:
1. Definition: copied from my playbook, word for word. Never reword it.
2. Conditions before entry, sizing and exit rules: copied from my playbook, word for word. Never reword it.
3. Example trades: links to the journal rows and review notes, by date and journal row number.
4. Mistakes seen: one line each, with links to the reviews where they happened.
5. Stats: paste the output of {{stats_script}} with n next to every figure. If n < {{min_sample}}, write "insufficient sample".

Weekly routine: read the new reviews, tell me in at most five bullet points total for the week what's new, and wait.
Summaries must stick to concrete facts (new mistakes observed, new trades added, sample-size changes) and never include opinions, predictions, or comparisons of setup quality.
Run the tag/definition lint before writing. If it flags near-duplicates or overlapping definitions, list them and wait; never invent, rename, or merge tags; only use {{setup_tags}} plus unclassified.
After my reply, update the pages, put trades that match no tag in unclassified.md, and add one dated line to log.md.
If I change a definition, record the date, the old text, the new text and my reason in log.md.
Refer to setups, dates and journal rows only.

Guardrails

  • Journal and broker data sent to Claude is processed by a US third-party; review Anthropic privacy terms, consider anonymizing P&L fields or using local models (e.g. via Cursor) to limit exposure.
  • All numbers come from the script. The agent only explains them, and the sample size is shown next to every figure.
  • No conclusions about a setup below the minimum sample you set (20 closed trades is a sensible floor).
  • Definitions change only when you approve the change, and every change is logged with the date and your reason.
  • The agent reads your journal and broker exports. It cannot place, modify or cancel orders.
  • The library is private and refers to setups, dates and journal rows.

What can go wrong

Setup tags drift. The same pattern picks up three names over a few months, and its stats split into small samples that mean nothing. A fixed tag list in the rules file, plus a lint pass that flags near-duplicate tags and pages with overlapping definitions, keeps the library usable.

Why it helps

Most journals record trades but don't build anything from them. A page per setup turns months of reviews into something you can reread in a minute: what the setup is, how it tends to go wrong for you, and what the numbers say once the sample is big enough. The log shows how your definitions changed and why.

How it fits with other entries

The R-multiple review (aft-0006) produces the reviews this library is built from. The weekly stats entry (aft-0007) can supply the stats script. An example stats script is included in the linked aft-0007 or can be a short pandas routine that reads the journal CSV, groups by setup tag, and outputs count, win rate, avg R, expectancy, and n for each. The weekly playbook review (aft-0017) can cite setup pages as evidence when it proposes a rule change.

Where this comes from

Sebastian Krog, a value investor, described keeping company research in a folder the agent only reads plus a wiki the agent maintains, following a pattern Andrej Karpathy published in April 2026. This entry applies the same structure to a swing trader's journal instead of company research.

Source and references

Adapted from a public post and article by Sebastian Krog (@SebKrog) on running Andrej Karpathy's "LLM knowledge base" pattern for investment research. We applied the same structure to a trade journal, in our own words.

Original: Sebastian Krog on x

Spotted an error, or want your post removed? Email hello@agentsfortraders.com.

Educational content only. Not investment advice or a personal recommendation. No tickers, signals or trade alerts. Trading involves risk of loss.

Conteúdo exclusivamente educativo. Não constitui aconselhamento nem recomendação de investimento. Sem tickers, sinais ou alertas de negociação. Negociar envolve risco de perda.

Related use cases