Turn a trading idea into a cBot specification

Define the market and the decision time

Name the symbol or say explicitly that the cBot should use its instance symbol. Define the period, price source and any additional timeframe. “Trade forex on an hourly chart” leaves both the instruments and data inputs unresolved.

State whether a decision uses the current unfinished bar or the latest completed bar. Intrabar signals can appear and disappear before a close, while closed-bar decisions need a new event to confirm the completed bar. Define how often the rule is evaluated and how duplicate actions are prevented.

Turn conditions into exact comparisons

“Buy when the trend is strong” does not define a measurable event. “Buy when the 20 SMA crosses above the 50 SMA on completed H1 bars” is better, but still needs the price source, equality handling and startup behaviour. Specify what must be true on the latest closed bar and on the previous one.

List the conditions that block an otherwise valid signal, such as a spread threshold or an existing position. Separate entry filters from exit rules: a blocked new entry should not accidentally disable protection for an existing position.

Define exposure and operating boundaries

Choose a sizing method and units. Fixed units, fixed lots and a percentage of equity are different rules. If using percentage risk, define the stop distance, rounding and what happens when the minimum permitted size would exceed the risk limit. Rejecting a trade is a valid outcome.

Define exits, maximum simultaneous positions, trading hours and time zone. Say whether closing time means “stop opening” or “close positions”. Specify which positions the cBot owns and how it behaves on hedging or netting accounts. Include any pending orders in its exposure policy.

Plan for restart and failure

A restart should not silently create a second trade for an old signal. Specify whether the cBot recovers matching positions, which label it uses and whether it can resume with no stored local state. Decide what stopping the cBot should do to existing exposure.

Also define insufficient history, market closure, invalid parameters, order rejection and missing protection. Ask for useful diagnostic logs. These rules make a failure visible and give you a repeatable test instead of relying on “it seems to work”.

A complete example to adapt

This intentionally simple example uses invented educational settings, not recommended trading parameters. Review every assumption before adapting it. The acceptance checks are part of the specification: they explain how to tell whether the implementation follows the request.

Educational cBot specification — SMA crossover demo

Platform: cTrader C#, standard time bars, demo evaluation only.
Market: the instance symbol; test first on the broker’s EURUSD symbol.
Period: H1. Reject another instance period with a clear log message.
Clock: UTC. Entry window: Monday–Friday, 08:00 inclusive to 16:00 exclusive.
Inputs: fast SMA 20, slow SMA 50, source Close; fixed volume 1,000 units;
stop loss 20 pips; take profit 40 pips; maximum spread 2 pips.
Validate fast > 0, slow > fast and positive risk/volume inputs.
Reject unsupported volume or invalid inputs; do not silently increase volume.

Timing: evaluate once on each newly completed H1 bar, when the next bar
starts. Use only closed bars. Require at least slow period + 2 closed bars.
Buy signal: fast SMA on the latest closed bar > slow SMA, and fast SMA on
the previous closed bar <= slow SMA. Sell signal: the reverse inequalities.
Enter a market order only within the entry window and spread limit.
Do not enter retrospectively for a signal that existed before startup.

Positions: use label CInfoSmaDemo, scoped to this instance symbol.
At most one position for this label and symbol; no pyramiding.
Run only one instance per account/symbol with this label on a hedging demo
account. Refuse netting accounts to avoid shared-position ambiguity.
Do not manage manual trades or positions with another label.

Exit: attach the specified stop loss and take profit to every entry.
Also close the labelled position on the opposite closed-bar crossover,
even outside entry hours or above the spread limit. Confirm the close
succeeded before any new entry. No immediate reversal on the same bar.
If a position closes by stop/target, wait for a fresh crossover.

Restart: recover matching open positions and manage them; do not duplicate
an entry or replay past signals. Stopping the instance leaves positions
and server-side protection in place. State this in the log.
If protection cannot be applied, attempt to close the new position,
report any failure prominently and stop new entries.
If an order fails, log the full result; do not retry that signal.
If data is insufficient or the market is closed, skip and log the reason.
Log startup settings, signal bar time (UTC), blocked-entry reasons,
order/close results and exceptions, without credentials.

Acceptance checks: verify both crossover directions, no duplicate entry,
session boundaries, spread gate, volume validation, failed order handling,
restart recovery and isolation from unrelated positions. Backtest first,
then observe the same source and settings on demo. No performance target.

Use the specification as a test checklist

Give a developer or Xen the complete specification and ask for any contradictions to be identified before implementation. Review the generated source against each rule, then compile and test it. If you later change a rule, update both the specification and the checks so the expected behaviour remains clear.

Further reading

• cBot lifecycle and instances
• Hedging and netting behaviour
• Testing a cBot