Crypto Trading Bot Prompt Checklist: Six Sections

You fed an idea to AI, it spat back a Pine Script, you pasted it in and it compiled on the first try. Then you set up the alert, filled in the webhook URL, hit Create — nothing happened. No error message, no notification, just silence.

This article doesn't evaluate which AI tool is better, and it won't do a tool comparison. It does one thing: break down any crypto trading bot prompt into six sections, each with verifiable checkpoints, plus a five-layer quality review before submission.

Layer 0: Does this alert even qualify to send a webhook?

Before writing any prompt, confirm whether the alert you got is an indicator or a strategy. This determines whether all the rules below apply — if the alert itself is wrong, no amount of prompt engineering will fix it.

Placeholders prefixed with strategy. only work when used in alerts created by a strategy; using them in an indicator alert will replace them with empty values, no error message. This is a conclusion derived from the official definition, not a sentence TradingView wrote out explicitly.

The first thing you need to do: go to the Add Alert dialog in the top right of your chart, select your conditions, scroll down to the Notifications section, look at the Script field. Paste the AI-generated prompt there and hit Create. If you see "No alerts created. Please select a strategy instead of an indicator", that means the alert you got is an indicator.

The six-part skeleton of a crypto trading bot prompt: each part has verifiable checkpoints

Break the AI-generated prompt into six sections, each independently verifiable. You don't need to write it all at once — confirm section by section with the AI, and for each section ask it to "give me concrete examples", not just show you what the code looks like.

Three technical terms, explained on first use:

Part 1: Identify the target — indicator or strategy?

Ask yourself: who decides the final order size, TradingView's platform side or the execution side? The answer to this question determines which type of alert you should use.

If there's strategy.entry, strategy.exit or strategy.position_size, that's a strategy and it can send webhooks. Red flags: only ta.xxx functions or plot/bgcolor output, no order-related logic — that's an indicator, don't send it to a webhook.

When prompting the AI, give direct instructions, not "is this code good":

Prompt the AI:
        What field does this code use to determine order size when pasted into the Webhook slot?
        Give me concrete examples.

Part 2: Input parameters — where does the price come from, which candle?

Questions for the AI: Where is the price read from? Which candle is used? Does it wait for bar close? These details determine whether your signal is "looks great in backtests but misses orders live" or actually usable.

Trap: many prompts just say "use closing price" without specifying which candle. If the alert is set to "Once per bar" but the code uses close[1], you're getting the previous candle's close — off by one bar, the order timing is wrong.

Check-in prompt for the AI:
        List all input sources:
        - Is request.security used? If so, write out the timeframe and lookahead settings
        - Is barstate.isconfirmed used? Why does it need to wait for confirmation?
        - Are any input.xxx parameters used to let users change values on the chart? List them all
        - Is alert.freq_once_per_bar_close or alert.freq_once_per_bar used?

        Give me concrete examples.

Part 3: Output definition — who decides the order size?

The core question: who determines the final order size, TradingView's platform side or the execution side? Both can control it, but the mechanisms are completely different.

The TradingView side uses strategy.position_size to control quantity — this is a number fully simulated by the Pine strategy on TradingView's servers, completely unrelated to your real account. The execution side (webhook) uses qty_type (percentage, fixed quantity, manual) plus quantity to determine the actual order size.

Ask the AI for output in this format:

Please output in a row-by-row format:
        alert_time | price | qty | direction | strategy.position_size
        2026-09-28T10:30:00 | 65432.50 | 10 | long | 5000

        Explain the source of each field:
        - price: which candle's close is used? If request.security is used, what's the lookahead setting?
        - qty: fixed value or calculated using strategy.percent_of_equity?
        - strategy.position_size: this is a number simulated by TradingView, completely unrelated to your real account.

Part 4: Conditional logic — when does it trigger, will orders be missed?

Ask: will this condition trigger in live trading the same way it did in backtests, or will it miss orders because "the bar wasn't confirmed"? This is the most common reason backtests look great but live trading underperforms.

barstate.isconfirmed: if the condition uses current price, add and barstate.isconfirmed to prevent triggering before the bar finishes. request.security: for cross-timeframe calls, write out the lookahead and barmerge settings to avoid future data leakage. For the detailed lookahead debugging flow, see The request.security Lookahead Trap: Great Backtests, Mismatched Live Trading.

For the conditions in question, ask the AI: "How many orders would this condition miss in live trading? How many would barstate.isconfirmed block?"

Part 5: Timeframes and data sources

Cross-timeframe calls are where Pine Script goes wrong most easily. Higher timeframe for trend filtering, lower timeframe for precise entries — sounds reasonable, but get the request.security lookahead wrong and you'll be pulling in future data.

Ask the AI for output:

List all uses of request.security in this format:
        request.security(timeframe, source, expression, lookahead, barmerge)
        - timeframe: 1D / 4H / 1H / 60 / 30 / 15 / 5 / 3 / 1 / 600
        - source: same chart / different chart / different timeframe
        - lookahead: barmerge.lookahead_off (default) or barmerge.lookahead_on

        Explain why cross-timeframe is needed:
        - Are you using a higher timeframe's trend for filtering?
        - Or using lower timeframe data for precise entries?

        Illustrate with examples.

The default is barmerge.lookahead_off (the safe value), only explicitly passing barmerge.lookahead_on will pull in future data. The prompt should say "the default is safe, no special setting needed" rather than "you must set it or you'll leak future data".

Part 6: Risk controls and boundaries

The bottom line upfront: TradingView makes no written guarantee on webhook "delivery / retry / timing" — this is a derivation, not an official quote.

A single alert triggers at most 15 times within 3 minutes; beyond that, no more are sent. Strategy backtesting runs on the broker emulator, executing hypothetical orders that have no connection to real accounts. Webhook latency is typically 1–5 seconds, but there's no official upper bound.

Ask the AI: "If this code places an order 5 seconds after a webhook delay, how much would it differ from the backtest result?" There's no standard answer, but the prompt should mention coping strategies.

Practical example: prompt skeleton for a BTC grid trading bot

Apply the six-part structure to a real strategy, laying out each section's core requirement into a table. You can build the full prompt directly from this skeleton:

When prompting the AI, ask each section to "give me concrete examples" rather than just showing you what the code looks like. The full prompt example can be assembled section by section from this table.

Five-layer review: self-check before submission

Go through each layer before submitting. If any layer blocks, go back and fix the prompt — don't force it through:

• Layer 0: Is this alert an indicator or a strategy? If it's an indicator, the entire prompt needs to be rewritten.
• Layer 1: The code compiles, but can it auto-execute orders? Where's the gap?
• Layer 2: Is order size controlled by TradingView (strategy.position_size) or execution side (webhook qty)?
• Layer 3: What is request.security's lookahead setting? Is barstate.isconfirmed used?
• Layer 4: Where are the risks of webhook delay, retries, and missed orders? Does the prompt mention coping strategies?

The observations above (compile success rate ~95%, auto-execution rate ~30–50%, webhook latency typically 1–5 seconds) vary significantly depending on alert type, execution configuration, and exchange response speed. The prompt should ask the AI to "give me concrete examples" rather than just looking at what the code looks like.

Frequently asked questions

Two more questions that come up frequently:

This article does not constitute investment advice. Crypto trading carries high risk — please assess your own risk tolerance before proceeding.