David Duncan's Personal Blog - Trading

Putting My Actual Trades on the Chart: TradingView Remix + Claude Code

2026-06-07T17:30:00-05:00

Putting My Actual Trades on the Chart: TradingView Remix + Claude Code

A trade review without a chart is just a spreadsheet apologizing for itself. I can read that my discipline was 4/10 and that I chased Microsoft below VWAP, but the lesson does not land until I see the arrows sitting on the candles where I actually clicked buy and sell. So I built that — two ways — and wired the whole thing into Claude Code so it happens as part of my daily review instead of as a chore I skip.

I keep my trading life in Notion: daily game plans, the daily trading journal, and the trader report card all live there. The missing piece was getting charts into those documents without hand-exporting screenshots every day. This is the story of that integration: TradingView Remix for the charts I mark up by hand, a data-driven pipeline for the charts that draw my fills automatically, and a hosting path on my own site so both kinds drop straight into Notion by URL.

Two kinds of trading chart

There are two charts I care about, and they have completely different jobs.

The game-plan chart is the one I think with. Levels, structure, the line in the sand where the thesis is wrong. This is human work — I want to draw on it, argue with it, mark the spot where I will get in. That is exactly what TradingView’s new Remix AI Chart Copilot is good at: I can ask it to label premarket highs, mark the 200-day, sketch the levels, and it does it on a real chart in my real session.

The review chart is the one I learn from. It is not about what I planned — it is about what I did. Where did the fills actually happen? Above or below VWAP? Did I add to a winner or average down a loser? That chart should not require any drawing at all, because the truth is already in the broker data. It should draw itself.

I stopped trying to make one tool do both.

The Remix side: driving my own browser

Remix runs as a browser extension in my logged-in TradingView session. The problem: my automation lives in WSL, and a headless robot browser does not have my TradingView login or my extensions. The fix turned out to be clean — Chrome’s remote debugging protocol.

I run a dedicated Chrome profile launched with --remote-debugging-port=9222, cloned from my real profile so the TradingView login and the Remix extension come along. From WSL, my tooling connects to that running browser over CDP and drives the real session — the same one with the copilot in it. I mark up a chart with Remix, say “capture it,” and the script screenshots that exact tab, uploads it to my site, and hands me back a URL I can paste into the day’s game plan in Notion.

A few things I learned the hard way, in case you try this:

Chrome 136+ silently ignores the debug flag on your default profile. You need a separate --user-data-dir. It will look like it is working and simply not open the port.
The WSL-to-Windows hop is not localhost. WSL’s resolv.conf nameserver is a virtual DNS address, not the host — use the default-route gateway, and forward the port through.
Clone your profile rather than starting fresh, or you will be logging into everything again.

The payoff: the AI copilot stays a human-in-the-loop tool — I do the thinking and the marking — and the machine just handles capture and publishing. That division of labor matters. The copilot is not making trading decisions; it is making my charts faster to produce.

The review side: charts that draw my fills

For the review chart I went the other direction — no browser at all. My DAS Trader exports already contain every fill: timestamp, side, quantity, price. My market-data provider gives me the intraday candles. matplotlib does the rest.

The script pulls one-minute bars for the session, overlays VWAP, and drops a green up-arrow at every buy and a red down-arrow at every sell, at the actual fill price and time. Then it crops to the trade window so a five-minute scalp is not lost inside a full session, and titles the chart with the real execution count.

That last part bit me first, and it is a good lesson in fidelity. My first version used five-minute candles and a six-fill Microsoft trade rendered as “1 buy / 2 sell bars” — nonsense, because four of the six fills had collapsed into the same candle and overwrote each other. The fix was one-minute resolution and counting executions, not candles. Now the title reads “6 executions (3 buys / 3 sells)” and every fill is visible where it happened. The chart tells the truth about the trade, which is the only thing a review chart is for.

What is public and what is not

The charts are hosted on my own domain so Notion can embed them by URL — which means the image is publicly reachable, so I had to be deliberate about what goes out. My rule:

Account dollars and account numbers are private. Published performance is expressed in R-units — risk-normalized, so I can share the quality of a decision without broadcasting my balance.
Account IDs become labels. A chart says “live” or “swing,” never the real account number.
Chart prices are fine. The market printed those prices for everyone; the teaching value is in where I entered relative to them.

The full-dollar version of every review goes to a private vault. The Notion journal that I share — the report card the community sees — carries the R-unit version. Same trade, same lesson, no overshare.

Why wire it into the AI at all

I could do all of this by hand. I would not. That is the real reason the integration matters: a review step that takes effort is a review step I skip on the days I most need it — the red ones. When the chart draws itself from my broker data, sanitizes itself, and drops into my Notion journal as a URL, the friction that used to kill the habit is gone.

AI did not make me a better trader. The discipline did. But the AI removed every excuse I had for not looking at the discipline — and on a 4-out-of-10 day, looking is the whole game.

David Duncan is a momentum trader, Fedora Cloud SIG contributor, and builder of AI-assisted trading infrastructure at davidduncan.org.

Taming the Finviz Elite Export API with a JSON Schema

2026-05-27T09:00:00-05:00

If you’ve ever tried to automate a Finviz Elite screener, you’ve run into the same problem: the c= query parameter takes a comma-separated list of integer column IDs, and the documentation for exactly what each ID means lives in the UI — not in an API spec. You end up with magic numbers in your URL and no way to know, six months later, why you picked c=1,65,61,63,64,66,67.

This post covers how I solved that with a JSON Schema catalog, and how it powers a pre-market gap scanner that feeds directly into a morning trading game plan.

The Finviz Elite Export Endpoint

The export endpoint is simple:

GET https://elite.finviz.com/export
  ?v=111
  &f={comma-separated filter codes}
  &ft=4
  &c={comma-separated column IDs}
  &auth={YOUR_API_KEY}

The response is a plain CSV with a header row — parse it with any standard CSV library. No pagination, no JSON envelope, no rate-limit headers to worry about. The tricky part is knowing which filters and columns to use.

Filter codes

Filters are human-readable strings like geo_usa, sh_price_o3, ta_gap_u5. The screener URL in the Finviz Elite web app encodes exactly these filter strings in its f= parameter, so you can build a screener visually, copy the URL, and read the filter codes directly.

For a pre-market sweet-spot gap screener ($3–$50, average volume > 500K, gap up > 3%):

f=geo_usa,sh_price_o3,sh_price_u50,sh_avgvol_o500,ta_gap_u3

Column IDs: the problem

Column IDs are integers from 0 to 150. The Finviz UI doesn’t expose them — you can only discover them by inspecting the CSV header names and matching them back to the screener column labels by hand.

The full catalog looks like this (selected trading-relevant columns):

ID	Column Name	Category
1	Ticker	identity
49	Average True Range	technical
61	Gap	price-volume
63	Average Volume	price-volume
64	Relative Volume	price-volume
65	Price	price-volume
66	Change	price-volume
67	Volume	price-volume
68	Earnings Date	events
71	After-Hours Close	price-volume
72	After-Hours Change	price-volume
81	Prev Close	price-volume
86	Open	price-volume
87	High	price-volume
88	Low	price-volume

There are 150+ columns spanning valuation, growth, ownership, profitability, technical indicators, intraday performance, and more.

Enter the JSON Schema

Rather than keeping these IDs as comments in a URL string, I modeled the full column catalog as a JSON Schema. The schema serves two purposes: it validates c= selections before the request fires, and it’s the canonical reference for what every ID means.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Finviz Export Column Selection",
  "type": "object",
  "required": ["columns"],
  "properties": {
    "columns": {
      "type": "array",
      "uniqueItems": true,
      "items": {
        "type": "integer",
        "enum": [0, 1, 2, 3, ..., 150]
      }
    },
    "asQueryString": {
      "type": "string",
      "pattern": "^c=\\d+(,\\d+)*$"
    },
    "profile": {
      "type": "string"
    }
  },
  "$defs": {
    "columnDefinition": {
      "type": "object",
      "required": ["id", "name"],
      "properties": {
        "id":         { "type": "integer" },
        "name":       { "type": "string" },
        "category":   { "type": "string" },
        "assetScope": { "type": "string", "enum": ["equity", "etf", "mixed"] }
      }
    },
    "columnCatalog": {
      "type": "array",
      "items": { "$ref": "#/$defs/columnDefinition" },
      "default": [
        { "id": 1,  "name": "Ticker",          "category": "identity",     "assetScope": "mixed" },
        { "id": 61, "name": "Gap",             "category": "price-volume", "assetScope": "mixed" },
        { "id": 63, "name": "Average Volume",  "category": "price-volume", "assetScope": "mixed" },
        { "id": 64, "name": "Relative Volume", "category": "price-volume", "assetScope": "mixed" },
        { "id": 65, "name": "Price",           "category": "price-volume", "assetScope": "mixed" },
        { "id": 66, "name": "Change",          "category": "price-volume", "assetScope": "mixed" },
        { "id": 67, "name": "Volume",          "category": "price-volume", "assetScope": "mixed" }
      ]
    }
  }
}

The columnCatalog default in $defs isn’t used for validation — it’s the reference. Any tool that reads the schema file knows exactly what c=1,65,61,63,64,66,67 means without a comment in the code.

Using It in a Pre-Market Scanner

The schema drives a finviz_screen() function in a Python scanner that runs each morning. The function:

Builds the c= parameter from the trading profile defined in the schema
Fires the export request with the sweet-spot filter set
Parses the CSV response with csv.DictReader — column access by name, not by position
Returns a list of tickers to pass downstream for z-score and Camarilla pivot analysis

import csv, io, urllib.request, ssl

FINVIZ_BASE = "https://elite.finviz.com/export"
FINVIZ_COLS = "1,65,61,63,64,66,67"  # matches the schema profile

def finviz_screen(api_key: str, min_gap: float = 3.0) -> list:
    filters = f"geo_usa,sh_price_o3,sh_price_u50,sh_avgvol_o500,ta_gap_u{int(min_gap)}"
    url = f"{FINVIZ_BASE}?v=111&f={filters}&ft=4&c={FINVIZ_COLS}&auth={api_key}"
    ctx = ssl.create_default_context()
    req = urllib.request.Request(url, headers={"User-Agent": "phase2_scan/1.0"})
    resp = urllib.request.urlopen(req, timeout=15, context=ctx)
    content = resp.read().decode("utf-8")
    reader = csv.DictReader(io.StringIO(content))
    return [
        {
            "ticker":     row["Ticker"].strip(),
            "fv_price":   row["Price"],
            "fv_gap":     row["Gap"],
            "fv_change":  row["Change"],
            "fv_volume":  row["Volume"],
            "fv_rel_vol": row["Relative Volume"],
        }
        for row in reader if row.get("Ticker", "").strip()
    ]

Column access by name (row["Gap"], row["Relative Volume"]) means the code is readable without the schema open in another tab. If Finviz ever adds a column or reorders the output, DictReader handles it transparently.

The Full Pipeline

The screener output feeds directly into a z-score and Camarilla pivot stage:

Finviz --screen (gap >3%, $3-$50, vol >500K)
    → ticker list
    → Polygon 22-day OHLCV per ticker
    → 20-day z-score classification (NORMAL / EXTENDED / EXTREME)
    → Camarilla H3/H4/L3/L4 from prior session
    → 5-day ATR proxy
    → setup signal (FL Long watch / Caution / Offsides)
    → formatted table + JSON for Notion

The scanner supports three modes:

# Auto-discover via Finviz
python3 phase2_scan.py --screen

# Strong gappers only
python3 phase2_scan.py --screen --min-gap 5

# News-first: manual tickers (bypass screener)
python3 phase2_scan.py LUNR SOUN MU

# Combine: Finviz + specific news catalyst tickers
python3 phase2_scan.py --screen LUNR

Why Schema First?

The schema adds two things that a comment in a URL string can’t:

Toolability. Any agent, script, or IDE that reads FinvizColumnSchema.json can enumerate valid columns, build a c= string, and validate selections without touching the Finviz UI or documentation. The catalog is the documentation.

Durability. When you come back to this code in six months and want to add Earnings Date (68) or After-Hours Close (71) to the screener, you look up the ID in the schema rather than re-reverse-engineering the API. The schema accumulates knowledge; comments rot.

For a trading workflow that runs every morning before the bell, those two properties matter.