Creating Better Trading Tools with AI

One of the biggest factors affecting the quality of AI-generated code is the scope of the request you provide.

Xen AI is designed to build professional cTrader applications through small, focused iterations. It retrieves relevant cTrader API and development information from its knowledge base as it works, so you do not need to place a complete product specification into one prompt.

Begin with the smallest useful version of your trading tool. Let Xen create it, publish it to cTrader, and test it before requesting the next feature. This cycle makes faults easier to identify and prevents untested requirements from being combined into one large, fragile implementation.

Why Some AI Requests Produce Better Results

Artificial intelligence works best when it receives clear requirements. If important information is omitted, Xen must make assumptions about how your trading tool should behave. Those assumptions may differ from your own expectations, resulting in additional revisions before the project is complete.

The goal is not to write long prompts. The goal is to write short, clear requests for the next testable step.

The Recommended Xen Workflow

Use the same development cycle for a trading robot, indicator, trading terminal, or dashboard:

1. Request a small baseline. Describe the minimum behaviour needed for the first working version.
2. Let Xen build it. Xen retrieves relevant information from its knowledge base and generates the implementation.
3. Publish to cTrader. Compile and run the new version in cTrader.
4. Test the behaviour. Confirm that the feature works correctly and note any errors or unexpected results.
5. Request one change. Ask Xen to fix the problem or add the next focused feature.
6. Repeat. Publish and test again before moving to another feature.

Describing Your Trading Idea

Before asking Xen to generate code, decide what the first working version must do and what can wait until a later iteration.

Across the full project, you may eventually need to define five areas:

• What you want to build.
• How trading signals are generated.
• How trades should be managed.
• Which settings users should be able to change.
• How the finished trading tool should look.

Do not try to describe every area in the first prompt. Start with the minimum logic or layout, then introduce risk controls, filters, alerts, styling, and advanced behaviour in separate requests.

Good Requests vs Poor Requests

A vague request leaves many questions unanswered.

This request does not explain which moving averages should be used, how positions should be managed, or what risk controls should be included.

A better request provides enough information for Xen to understand the strategy.

Publish this baseline to cTrader and test its entries before continuing. Later prompts can add a stop loss, take profit, trailing stop, session control, and spread filter one feature at a time.

Explaining Your Trading Logic

The trading logic is the most important part of your request.

Rather than simply naming an indicator, explain exactly how it should be used. Describe the conditions that generate buy and sell signals, any confirmation rules that should be satisfied, and any situations where trades should be ignored.

For example, if your strategy only trades during the London session or only enters after a candle closes, mention this in your request. Small details like these often have a significant impact on the finished trading tool.

Describe Risk Management

Professional trading tools require more than entry signals.

Consider explaining how trades should be managed after they have opened. This may include Stop Loss, Take Profit, Break-even, Trailing Stop, maximum open positions, trading sessions, spread filters or percentage risk management.

Add risk management after the basic entry and exit behaviour has been published and tested. Introduce each risk feature with a focused request, for example: "Add a configurable fixed stop loss of 20 pips. Do not change the entry or exit rules." Publish and test that change before adding another.

Explain the User Interface

If you are building an indicator, dashboard or trading terminal, explain how you expect it to appear on the chart.

Describe where panels should appear, how information should be grouped, preferred colours, font sizes, button layouts and any visual styling that is important.

Start with the essential calculation, information, or controls. Once the basic tool displays and behaves correctly in cTrader, refine one visual area at a time. Screenshots can help explain a specific layout change, but avoid combining a complete visual redesign with new trading logic in the same request.

Let Xen Ask Questions

Not every request needs to be perfect.

If Xen asks follow-up questions before generating code, this is usually a good sign. It means the AI has identified missing requirements and is trying to clarify them before writing your trading tool.

Taking a few moments to answer these questions will usually produce a much better result than immediately generating code with missing information.

Prompt Examples by Trading Tool

The first prompt should establish a small, testable baseline. The follow-up prompts should add or change only one feature while preserving behaviour that already works.

Trading Robot (cBot)

First prompt:

Create a cBot that opens a buy position when the 20 EMA crosses above the 50 EMA after the bar closes, and a sell position on the opposite crossover. Allow only one open position.

After publishing and testing it in cTrader, continue with requests such as:

• "Add a configurable 20-pip stop loss. Do not change the entry rules."
• "Add a take profit based on a 2:1 reward-to-risk ratio."
• "Add a London session filter and leave all other behaviour unchanged."

Technical Indicator

First prompt:

Create a cTrader indicator that plots a 20-period EMA and a 50-period EMA on the chart using configurable periods.

After checking the calculation and display in cTrader, continue with requests such as:

• "Colour the fast EMA green when it is above the slow EMA and red when below."
• "Add an arrow after a confirmed crossover at bar close."
• "Add an optional sound alert for a new crossover."

Trading Terminal

First prompt:

Create a simple cTrader trading terminal with Buy and Sell buttons, a volume input, and a Close Position button. Ask for confirmation before placing or closing a trade.

Test every control on a demo account before continuing with requests such as:

• "Add separate stop-loss and take-profit inputs."
• "Display the selected symbol's spread above the order buttons."
• "Disable the order buttons while an order request is being processed."

Market Dashboard

First prompt:

Create a read-only cTrader dashboard that displays the symbol, timeframe, current spread, and RSI value in a simple chart panel.

After checking the values and layout in cTrader, continue with requests such as:

• "Add a colour-coded RSI state for overbought, neutral, and oversold."
• "Add the current ATR value below RSI."
• "Allow the panel to be positioned in any chart corner."

Example Prompt Library

If you are unsure how to describe your next development step, the Xen AI GitHub Prompt Library contains examples for the main types of cTrader trading tools.

Use the examples as a source of focused requests. Do not combine an entire library page into one prompt; select the example that matches the next feature you want to build or change.

cBot Prompts

The cBot examples demonstrate how to describe automated trading strategies, including entry rules, exit conditions, position management, risk controls, trading sessions, and configurable parameters.

View cBot prompt examples on GitHub

Indicator Prompts

The indicator examples demonstrate how to describe calculations, chart drawings, signal conditions, colours, configurable settings, alerts, and indicator outputs.

View indicator prompt examples on GitHub

Dashboard Prompts

The dashboard examples demonstrate how to describe account information, market statistics, panel layouts, real-time updates, colours, and chart positioning.

View dashboard prompt examples on GitHub

Trading Terminal Prompts

The trading terminal examples demonstrate how to describe manual trading controls, order management, risk calculations, buttons, input fields, panel layouts, and safety checks.

View trading terminal prompt examples on GitHub

Improving Existing Projects

When continuing development on an existing project, avoid asking Xen to rebuild everything from scratch.

Instead, explain exactly what should change while leaving the rest of the project untouched. This helps Xen preserve your existing functionality and focus only on the requested improvements.

For example, instead of asking Xen to "Improve my dashboard," explain which parts need to change, such as resizing panels, adding statistics, changing colours or introducing new controls.

Work on One Feature at a Time

Large requirements containing dozens of features should be treated as a roadmap, not pasted into Xen as a single prompt. Break the roadmap into small requests with a result that can be observed and tested in cTrader.

After every request, publish the updated project to cTrader and test it. If the result is correct, request the next feature. If it is not correct, ask Xen to fix that feature before continuing.

Common Mistakes

Many AI development problems are caused by requests that are too vague or too large.

Common mistakes include asking Xen to create "a profitable robot", requesting that it "make everything better", pasting a complete commercial product specification, or asking it to add logic, risk management, alerts, and a full interface in one step.

Instead, describe the exact behaviour you expect. If you know how a feature should work, explain it in plain English. Xen does not require technical terminology; it simply needs enough information to understand your intentions.

Best Practices

The most successful Xen users tend to follow a simple workflow.

They begin with a basic working version of their trading tool, test it inside cTrader, then continue improving it through a series of focused requests. Each request builds upon the previous one until the project reaches its final form.

Whenever possible, continue development inside the same Xen Project rather than starting a new conversation. This allows Xen to understand your existing implementation and reduces the amount of context that needs to be repeated.

Maintaining this iterative approach almost always produces better results than attempting to generate a large, complex application in a single request.