Most traders who sit down with Claude to build a strategy walk away frustrated within the first hour. The code runs but doesn’t do what they meant. The backtest looks brilliant and falls apart in walk-forward. The live system misbehaves in ways the prompt never anticipated.
The instinct is to blame the AI, or to go hunting for some clever prompting technique that will unlock better results. Neither is the actual problem.
The actual problem is that the strategy in your head still has unstated assumptions. Assumptions that work fine when you’re trading discretionary, because your pattern recognition fills the gaps in real time. Those same assumptions become invisible bugs the moment you try to codify the strategy into bar-by-bar boolean logic.
This post is for traders with three to four years or more in the markets, who have an edge they’re trying to systematize, and who want to know what actually works when building with Claude. No prompt engineering folklore. Just the workflow that produces strategies that ship.
The work that comes before the prompt
If you cannot describe your entry trigger as an expression evaluable on a single bar’s data, the strategy is not ready to automate.
This is the threshold. Everything else follows from it.
Before opening Claude, you should be able to articulate these without hand-waving:
Market context filter. What regime does this strategy work in. “Trade only when ADX(14) on the daily timeframe exceeds 25 and price is above the weekly Anchored VWAP from the last quarterly pivot” gives Claude something to implement. “Trade when trending” gives Claude permission to invent.
The trigger condition. A bar-by-bar evaluable expression. “Long when price closes above the upper Keltner Channel (20 EMA, 2.0 ATR), and intraday CVD has made a higher high in the last 20 bars, and the close is above session VWAP plus one standard deviation.” Every term must be unambiguous to a reader who has never seen your charts.
The invalidation. Where you’re structurally wrong, not just where your stop sits. “Stop below the most recent swing low identified by a fractal pivot in the last 30 bars, or 1.2x ATR(20) from entry, whichever is wider.”
Exit asymmetry. Most edges live here. Most traders underspecify it. Initial target, scaling rules, trail logic, time stop, all separately defined. “Scale 50% at 1.5R, move stop to entry on remainder, trail with Chandelier Exit (22, 3.0 ATR), hard time exit at 15:10 IST regardless.”
Position sizing as a function of conviction. Not “1 lot.” Something like: “Base risk = 0.75% of account equity per trade, sized from stop distance. Increase to 1.25% when entry coincides with prior day’s value area boundary and session VWAP confluence.”
The disqualifiers. When you do not trade, despite a valid signal. “Skip if 20-bar realized volatility is below the 30th percentile of the last 60 bars. Skip if event risk in the next 60 minutes (RBI policy, US CPI, expiry settlement). Skip if cumulative day P&L is worse than -2R.”
If any of these are fuzzy in your head, Claude will fill the gap with reasonable-sounding defaults, and you will discover the gap during live trading. Which is the expensive way to find out.
Picking the right platform for the job
Pine Script v6 for visual validation, alert-based semi-automation, and rapid iteration. The fastest feedback loop in the industry. Constrained to TradingView’s data and execution model.
Amibroker AFL when you need realistic Indian market backtests with portfolio-level constraints, position sizing across instruments, and walk-forward optimization. Steeper, but it remains the most honest backtester for Indian equities at portfolio scale.
Python with OpenAlgo when you want to actually trade live, automate across multiple brokers, integrate machine learning models, run options strategies with proper Greek management, or do anything that touches order management beyond what charting platforms expose.
The pragmatic path most serious traders end up on: prototype in Pine Script for visual confirmation, validate seriously in AFL with real tick data and walk-forward, then port the survivors to Python with OpenAlgo for production execution.
The context you provide determines the code you get
Most traders skimp here. Don’t. The minimum context that gets you a working build on the first or second iteration:
The strategy specification you wrote on paper, pasted in full. Not summarized. Not “you know, the usual setup.” Written out.
A CSV of 500 to 1000 bars of the actual instrument and timeframe you’ll trade. This single artifact eliminates an entire round of column-name-and-timestamp-format debugging. For Pine and AFL it matters less because data flows through the platform. For Python it’s mandatory.
For Pine Script v6 specifically, mention v6 explicitly in your prompt. The syntax differs from v5 in meaningful ways, including matrix operations, dynamic request.security calls, and method-style function syntax. Claude will default to v5 if you don’t say.
A reference implementation in your style, even if it does something different. It tells Claude your naming conventions, whether you prefer functional or imperative AFL, whether your Pine code uses libraries, how you structure OpenAlgo calls.
For OpenAlgo specifically, paste your actual broker configuration and a working order placement snippet from your existing code. The SDK supports REST and WebSocket patterns. Claude shouldn’t have to guess which you’ve adopted.
Annotated chart screenshots. One showing a textbook entry the strategy should take, one showing a near-miss it should reject. These resolve more ambiguity in 30 seconds than three paragraphs of prose.
Build in stages. This is the workflow that separates traders who ship from traders who debug forever.
Stage one: indicator calculations and plotting only. No entries, no exits, no strategy execution. Verify the Anchored VWAP anchors at the right bar. Verify the CVD accumulates correctly and resets when you expect. Verify the Keltner bands track price the way they should. Eyeball this on 50 charts before moving on.
Stage two: entry conditions plotted as shapes on the chart. Still no exits, still no orders. Walk through 30 to 50 historical signals manually. Are they firing on the bars where you’d actually take the trade? If 4 out of 5 look right, you’re ready to proceed. If only 2 out of 5 look right, your specification has a gap. Fix it now, not after you’ve added 200 more lines.
Stage three: exit logic and stop management. Backtest with realistic costs and slippage. Examine the trade list, not just the equity curve. The equity curve hides everything that matters.
Stage four: position sizing and portfolio-level constraints.
Stage five: alerts (Pine), automation hooks, or for Python, the OpenAlgo order placement layer with proper error handling.
If something breaks at stage three, you know stages one and two are clean. This is enormously easier to debug than a single 500-line prompt that produced a single 800-line file that doesn’t work.
What a good prompt actually looks like
Realistic prompt for a Pine Script v6 strategy on BANKNIFTY:
Build a Pine Script v6 strategy for BANKNIFTY futures, 15-minute
timeframe, intraday only.
Setup logic:
- Anchor a session VWAP at 09:15 IST each day
- Calculate VWAP standard deviation bands at 1 and 2 sigma
- Calculate Keltner Channels (20 EMA, 2.0 ATR(20))
- Build an intraday CVD using volume * sign(close - open)
accumulated from 09:15, reset each session
- Detect bullish order flow divergence: price makes a lower low
over the last 20 bars while CVD makes a higher low
Long entry:
- Bullish CVD divergence triggered within the last 5 bars
- Price reclaims session VWAP after having traded below
VWAP minus 1 sigma in the same session
- Entry on close of the reclaim bar
- Only between 09:45 and 14:00 IST
Risk management:
- Initial stop = lowest low of the last 10 bars minus 0.3 x ATR(14)
- Position size = round_to_lot(equity * 0.0075 / stop_distance)
- BANKNIFTY lot size = 35
- Scale out 50% at 1.5R, move stop to breakeven on remainder
- Trail remainder with Chandelier Exit (22, 3.0 ATR)
- Hard time exit at 15:10 IST
Filters and disqualifiers:
- Skip if daily ATR(14) is below 30th percentile of last 60 days
- Skip if cumulative day P&L is below -1.5R
- Maximum 2 long entries per day
For this first pass, output only:
1. The indicator calculations (session VWAP with bands, Keltner
Channels, intraday CVD)
2. The bullish divergence detection logic
3. Plots and shape markers for all of the above so I can validate
visually on the chart
Do not add entry execution, exits, or strategy() calls yet. I want
to confirm the divergence detection fires on the bars I expect
before going further. Use Pine v6 syntax including method-call
style where appropriate.
Notice what this prompt does. Every term is concrete. The platform and version are explicit. The scope is constrained to verifiable output. The trader has stated what they want to see before committing to full implementation. There is no preamble telling Claude it’s an expert Pine Script developer. Claude already knows how to write Pine Script. What Claude needed was the specification, and the trader provided it.
The AFL equivalent
For an Amibroker user building a portfolio-level mean reversion system on NIFTY 500 constituents, the prompt should specify the universe construction (top 200 by 20-day median rupee turnover, refreshed monthly), the ranking metric (z-score of close versus 50-day Hull MA combined with Connors RSI(3,2,100) below 15), portfolio constraints (maximum 10 simultaneous positions, sector cap of 3 per sector, no entries on stocks gapping more than 2% at open), the reentry logic after a stopped-out trade, and the rebalancing frequency.
AFL’s portfolio backtester rewards this kind of precision. Generic AFL written from a vague spec produces backtest results that look beautiful and don’t survive walk-forward analysis. The platform isn’t the problem. The specification is.
The Python with OpenAlgo equivalent
The prompt should include your OpenAlgo connection pattern (REST polling versus WebSocket streaming for quotes), your existing broker adapter if you have one, your preferred logging and error handling conventions, and an explicit statement of which failure modes to handle.
A real example: an opening range breakout system with dynamic range qualification needs to specify how the range is computed (first 5 minutes, first 15 minutes, or volatility-adjusted), what disqualifies a range (spread too wide, gap day larger than X percent, earnings on the calendar), and the order modification ladder for trailing stops as price moves favorably.
OpenAlgo’s order placement API is straightforward. The state management around bracket orders, modifications, and reconciliation against broker-reported order state is where Python strategies actually get hard. Be specific about this in your prompts. “Handle broker session expiry mid-trade by re-authenticating and reconciling open orders before placing anything new” is the level of specification that produces production-grade code.
What separates traders who ship from traders who don’t
Three skills, in order of importance:
Statistical literacy beyond Sharpe ratio. If your evaluation toolkit is just CAGR and max drawdown, you will ship strategies that mean-revert in backtest and trend in live trading, then wonder why. Distribution of returns. MAE and MFE analysis. Regime-conditional performance. Parameter stability surfaces, not point estimates. Bootstrap confidence intervals on Sharpe. Deflated Sharpe ratio when you’ve tested many variants. This separates traders who compound from traders who recycle accounts.
Reading code well enough to audit it. You do not need to write Pine v6 from scratch. You must catch when Claude writes ta.crossover where you wanted ta.crossunder. When request.security is called without lookahead=barmerge.lookahead_off and is silently introducing future data into your backtest. When a session VWAP doesn’t actually reset at session start because of a subtle bar-state condition. Two to three weeks of focused reading on real code and you’ll catch 90% of these.
Debugging discipline. When the live system misbehaves, isolate. Is it the data, the signal logic, the order management layer, or broker behavior? Log enough state to answer this from the logs alone, without re-running anything from memory. The traders who survive automation are the ones who treat their strategy like a piece of production software, because that’s what it is.
What to avoid
Asking for a complete profitable strategy. You’ll get something that compiles, looks plausible on a backtest of the last 18 months, and is not profitable. Edge comes from the trader, not the code generator.
Pasting a setup from a YouTube video and asking Claude to backtest it. If the setup worked at scale, the person who posted it would be running capital, not selling a course about it.
One-shot prompting for the full system. Stage it. Verify each layer.
Treating Claude as a quant researcher. Claude implements what you specify, and catches obvious implementation mistakes when they’re visible. Claude cannot tell you whether your edge is statistically real. That’s your job, with proper out-of-sample testing and honest evaluation.
Trusting the equity curve. Always inspect the trade list. The equity curve hides everything that matters: the one trade that made the year, the period where the strategy was flat for nine months, the regime where it bled steadily. Look at the trades.
The takeaway
The bottleneck in AI-assisted strategy development is not the AI. It’s the precision of your specification.
That precision is a trading skill, not a prompting skill. It’s the same precision that separates traders who can teach their methodology from traders who can only execute it. AI-assisted strategy development just exposes which of those two you are. If your discretionary edge is real and articulable, Claude will help you systematize it faster than you thought possible. If your edge lives in unstated pattern recognition that you’ve never had to write down, the bottleneck is going to be writing it down, not the LLM.
Start there. Then prompt.
