Skip to content

Work on an Existing Trading Robot

What this Workflow Does

The Work on Existing cBot workflow allows you to modify, extend, or fix an already built trading robot.

It is designed to help you:

  • Improve or adjust existing strategy logic
  • Add new features without breaking current behaviour
  • Fix bugs and refine execution
  • Safely evolve a working robot step by step

This workflow prioritises controlled changes and stability over rapid modification.

When to Use This Workflow

Use this workflow when:

  • You already have a working cBot
  • You want to modify or extend its behaviour
  • You need to fix bugs or improve logic
  • You want to add features incrementally

Do not use this workflow to build a new robot from scratch.
Use Build a Trading Robot instead.

What You Should Prepare

Before starting, provide:

  1. Existing source code
    The full cBot file you want to modify.

  2. Clear objective
    What you want to change or improve.

  3. Specific rules or behaviour
    Exact conditions or logic you want added or adjusted.

  4. Constraints (optional)
    Limits such as risk rules, execution restrictions, or performance concerns.

Avoid vague goals. Be precise about what should change.

How to Interact with Xen

Focus on one change at a time.

Good examples:

  • “Add a trailing stop after 20 pips profit.”
  • “Only allow one position per direction.”
  • “Fix duplicate trades on the same candle.”
  • “Add a time filter between 08:00 and 17:00.”

Avoid:

  • “Improve everything”
  • “Make it more profitable”
  • “Add full risk management, filters, and optimisation”

Incremental updates reduce errors and preserve stability.

How Xen Modifies Existing Robots

Xen will:

  • Analyse the existing structure and logic
  • Modify only the relevant sections of code
  • Preserve working behaviour wherever possible
  • Keep logic clean and organised
  • Return a complete, compile-ready file after each change

Xen does not assume intent. Clear instructions produce accurate results.

Common Mistakes to Avoid

  • Providing incomplete or partial code
  • Requesting multiple unrelated changes at once
  • Breaking existing logic without testing
  • Ignoring how new features interact with current rules
  • Manually editing code without informing Xen

Each change should be tested before continuing.

After each modification:

  • Compile and confirm no errors
  • Backtest to verify expected behaviour
  • Check trade execution, risk, and edge cases

Then extend gradually with:

  • improved risk handling
  • execution filters
  • trailing or scaling logic
  • alerts and notifications

You may also want to explore: