Writing Effective Requests

You do not need to know C# to describe a trading tool, but Xen needs enough information to distinguish one trading behaviour from another. A useful request explains what the script should observe, what event should trigger an action, and what should happen afterwards.

For a Strategy, describe the entry condition, exit condition, trade direction, position size and any requested protection. If calculation timing matters, state whether the decision should be made at bar close or intrabar. Session times, secondary timeframes and one-position restrictions should be included when they are part of the intended design.

For an Indicator, explain the calculation, where it should appear, and how its output should be presented. Mention plots, colours, markers, reference levels and user-adjustable inputs when those details matter.

Start with behaviour

A request such as “build an RSI strategy” leaves several material decisions unresolved. A stronger request explains when a long or short entry occurs, whether an opposing signal closes or reverses a position, and how risk is managed.

For example:

Create a NinjaTrader 8 Strategy that enters long when RSI(14) crosses above 30 and enters short when it crosses below 70. Evaluate signals on bar close, allow one open position, and use configurable 20-tick stop loss and 40-tick profit target inputs.

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

Avoid combining unrelated changes

Once a working baseline exists, ask for one meaningful refinement at a time. Small, testable changes make it easier to identify where a problem was introduced. A follow-up such as “add a configurable trading session from 09:30 to 16:00” is easier to verify than a request that simultaneously changes entries, risk, timeframes and visual output.

When modifying existing code, include the complete file and state what must remain unchanged. Xen uses the current conversation as context, but the latest complete source is the safest basis for a revision.

Let Xen clarify genuine ambiguity

Xen does not need a questionnaire for every request. When one missing decision would materially change the strategy or indicator, the Prompt Builder can ask a focused question. Complex projects can be divided into a Build Plan so that a minimal working version is compiled before later features are added.

Do not add technical API names merely to make a request appear advanced. Describe the required behaviour accurately and let the NinjaTrader-specific task prompt determine the appropriate implementation.

Requests after testing

When NinjaTrader reports a compiler or runtime error, include the exact message and the latest complete source. Explain what action caused the error when known. For behavioural problems, describe what happened, what you expected, the instrument and timeframe, and whether the issue appeared historically, in real time or in Strategy Analyzer.

Avoid saying only “it does not work”. Concrete evidence gives the model a much better chance of making a focused repair.