Writing Effective Requests

You do not need to know Pine Script to describe a trading tool, but Xen needs enough information to distinguish one behaviour from another. Explain what the script should observe, what event should trigger an action and what should happen afterwards.

For a strategy, describe entries, exits, trade direction, position size and protection. State whether signals should be confirmed at bar close, whether pyramiding is allowed and how sessions or higher timeframes should be handled when they matter. For an indicator, explain the calculation, whether it overlays price or uses a separate pane, and how plots, markers, colours, levels and alerts should behave.

Start with behaviour

A request such as "build an RSI strategy" leaves several decisions unresolved. A stronger request explains the crossing condition, long and short behaviour, exits and risk controls.

For example:

Create a Pine Script v6 strategy that enters long when RSI(14) crosses above 30 and enters short when it crosses below 70. Confirm signals at bar close, allow one position, and provide configurable stop-loss and profit-target percentages.

This is specific enough to implement while remaining understandable to a trader.

Build in focused stages

Once a working baseline exists, ask for one meaningful refinement at a time. A request such as "add a configurable trading session from 09:30 to 16:00" is easier to verify than a single prompt that changes entries, exits, risk, timeframes and visuals together. Larger projects can use Prompt Builder to divide the work into stages.

When modifying existing code, attach the complete current file and state what must remain unchanged. After testing, report the exact Pine Editor diagnostic or describe the unexpected chart or Strategy Tester behaviour, including the symbol, timeframe and settings used. Concrete evidence is more useful than saying only that the script does not work.

Let Xen clarify genuine ambiguity

Xen does not need a questionnaire for every request. Prompt Builder is offered when one missing decision could materially change a new strategy or indicator. Do not add Pine API names merely to make a request sound technical. Describe the required behaviour accurately and let the task-specific instructions determine an appropriate implementation.

Requests after testing

When TradingView reports a compiler error or warning, copy it exactly and use the latest complete source. For a strategy that behaves differently from the design, explain what happened, what you expected and whether the observation came from historical bars, real-time bars or Strategy Tester. Keep repair work separate from unrelated enhancements until the original problem is confirmed as resolved.