Log and review every trade decision in your Notion ledger

Trading Ledger is a trade journaling skill in the tradition of the Market Wizards interviews: a written record of every trade's decision process, reviewed on a schedule. The user reports a trade in plain language, such as "bought 500 NVDA at 135, stop at 128, betting the post-earnings dip fills," and the skill writes ticker, size, and price to the user's own Notion database plus the part a plain spreadsheet journal loses - the thesis, the plan, and the emotion. If no reason is stated it asks on the spot, because "entry reasons decay overnight." Reviews grade decision quality against the user's own stated plan rather than against the outcome - a stopped-out trade that followed the plan scores better than a profitable trade entered on impulse. Unlike its sibling @time-ledger, database confirmation here is stricter: a single title match on "trading-ledger" is explicitly not sufficient confirmation - the skill must show the candidate title and data_source_id and get the user to confirm the exact database before any query or write, using owner or schema metadata as an additional identity check if the connector returns it, and it does not re-run fuzzy selection after that confirmation. The companion template's schema, whose select values must be copied exactly: Entry (title), Ticker (text, including strikes and expiries like "NVDA 0620C150" or "ESU6"), Market (US Stocks/US Options/US Futures/A-Shares/HK Stocks/CN Futures/Crypto/Other), Direction (Long/Short), Size (text with units), Entry Price/Exit Price (number), Entry Date/Exit Date (date, expanded as "date:Entry Date:start": "YYYY-MM-DD" since a bare value fails with HTTP 400), Thesis (text, "the soul of the journal," asked for on the spot if missing), Plan (text: stop, target, contingency, also asked for if missing), Emotion (Calm/FOMO/Panic/Revenge/Boredom/Overconfidence, tagged only from what the user admits or states plainly, never diagnosed), Execution (Per plan/Early exit/Delayed stop/Impulse/Unplanned add, filled at close), P&L (realized, number), Status (Open/Closed/To-confirm/Reviewed), Review (text), and Notes (text).

Use it when the user reports a trade fill, such as "bought 500 NVDA at 135," "closed my TSLA position," or "opened 2 ES contracts short," says "log a trade," "trading ledger," or "tidy up my trading ledger," or asks to "review my trades." Closing an existing position finds that ticker's Status=Open row and grades Execution against the user's own Plan - stopped where planned counts as Per plan, running past the target as Early exit, holding through the stop as Delayed stop - and if no matching open row exists, it creates one marked To-confirm and asks whether the entry was simply never logged. A review walks recent closed and all open positions asking three fixed questions per closed trade: did the thesis play out (a wrong thesis with a profitable outcome is explicitly called luck, not a good trade); how was the execution (a per-plan loss is called a good trade); and what share of trades were emotion-tagged - conclusions get written into Review, the row moves from Closed to Reviewed, and every still-open position gets asked whether its entry thesis still holds today. It never computes P&L on its own, since options and futures carry multipliers and only the user's own numbers are used, never looks up market prices to fill a gap, and must never produce trading signals, price data, or buy/sell recommendations - it records and mirrors the user's own decisions and states plainly that nothing it writes is financial advice.

Input is a plain-language trade report, close, or review request; output is a Notion row per trade with the schema above, created via create-pages and updated via update-page on close or review. A worked example: "picked up some TSM July calls this morning, same thesis as before earnings" logs an open row and immediately asks for the missing strike, expiry, contract count, price, and plan, rather than guessing any of them. Documented pitfalls: the same Date-field HTTP 400 and silent-drop issue (notion-mcp-server#121) as the sibling time-tracking skill, requiring a read-back-and-backfill after the session's first create; closing the wrong row when the same ticker was traded twice, fixed by matching on Status=Open plus ticker and asking which one if multiple match; and overnight US fills getting dated to the wrong day for non-US users, fixed by treating an overnight fill as belonging to the US trading date and confirming before writing.

Writes and updates rows only in the exact Notion database ID the user confirmed for the current session, via the official Notion connector (MCP) - no shell commands, no network fetches, no market-data lookups, and no credentials handled by the skill. If the connector can't query the ledger for a close, reconcile, or review flow, the skill stops after logging the new facts it does have and asks the user for the relevant row details rather than guessing a match. It names one related, separate skill, @time-ledger, applying the same parse-plain-language-into-your-own-Notion-database-and-ask-instead-of-guessing pattern to general time tracking.

Traders who want a Market-Wizards-style decision journal - thesis, plan, and emotion captured at entry, execution graded against their own plan rather than the outcome - without broker integration, since only the trader knows why a trade was taken, not just that it happened.