Prompting tips

Most failures we see in AI-generated indicators aren't model failures — they're underspecified prompts. The model knows AssemblyScript and the indicator API; it doesn't know what your indicator is supposed to do. These tips help you describe the target so it can hit it.

Be specific about the math

"Make me an oscillator" is too open-ended. "Make me an oscillator that's the difference between the 20-period SMA and the 50-period SMA, normalized by ATR(14)" is a specification.

• Name the formula or describe it precisely.
• Give parameter names and defaults.
• Say whether the indicator goes on the price pane (overlay: true) or in its own pane.
• Mention bands or filled zones if you want them.

Pin parameter ranges

Inputs default to wide ranges if you don't say otherwise. Tell the model what's reasonable: "length int, default 20, min 2, max 200." This shows up in the settings dialog and prevents users (or future-you) from setting a value that breaks warmup.

Describe the visual you want

• "Three lines, the middle one bolder than the bands."
• "Histogram in green when positive, red when negative, lighter shades when fading."
• "Dashed horizontal lines at 30 and 70, with a translucent fill between."

The model will pick the right plot styles (line vs histogram vs columns), the right break behaviour, and the right colors — but only if you tell it the look.

Iterate in the same chat

Each chat is a thread. Refining "make the bands wider" or "add a third smoothed line" is almost always cheaper and faster in the same chat than starting fresh, because:

• The model has the indicator context already.
• Prompt caching kicks in on consecutive turns — replayed input drops to about 10% of regular cost.

Start a fresh chat for a different indicator, not for tweaks to the current one.

When the model gets stuck

• Try a different model. If one is going in circles on a particular problem, switching to a different family often breaks the loop.
• Show, don't just tell. Paste a Pine Script example, a Python sketch, or even pseudo-code — the model is good at translating across notations.
• Ask it to re-check your indicator's current settings. If your inputs or plots aren't matching up, asking the model to "look at the current settings before changing the code" usually realigns it.

What the model already knows (so you don't have to repeat)

The model is briefed in detail on the indicator API. It knows:

• What the indicator code can read — current bar, bar history, your declared inputs — and the plots and bands it can write.
• The two ways to structure an indicator (recompute from history vs. carry state forward) and which one fits the math you're after.
• The rules of AssemblyScript — what's allowed, what isn't, and the strict-typing pitfalls.
• How to compile the indicator and add it to your chart.

You don't need to remind it of any of these. If the model breaks one of these rules, treat it as a model bug to be reported, not as something to prompt around.

Things to avoid

• Don't mix specs. "Make it both a Bollinger Bands and a MACD" produces confused output. Two indicators = two chats.
• Don't ask for backtest claims. The model has no idea how it'll perform. Ask for the math, run the replay yourself.
• Don't ask for non-AssemblyScript code. Even if it agrees, it won't run on the chart. Indicators are AS-only by design.

Cost discipline

• Pick the smallest model that gets the job done.
• Iterate in one chat, don't restart for tweaks.
• Trim long pasted specs once they're no longer relevant — they replay every turn.
• Output is the most expensive token type. A good prompt produces a tight reply.

Cost-related details are in AI pricing.