Working with an existing NinjaTrader Strategy can become difficult during a long AI development session. The original source may be buried in earlier messages, requirements can change and the same NinjaScript files may need to be uploaded repeatedly.
Following feedback from Xen beta users, we have updated the Working with an Existing Strategy workflow in Xen AI for NinjaTrader. The project can now retain the current Strategy source, supporting NinjaScript files, confirmed requirements and important development decisions instead of relying entirely on the chat history.
Watch the Existing Strategy Workflow
This demonstration shows how an existing NinjaTrader Strategy can be loaded into Xen, reviewed and modified while the important source files and development decisions remain connected to the project.
Watch the existing NinjaTrader Strategy AI tutorial on YouTube
Add Existing NinjaScript to the Project
When modifying an existing NinjaTrader Strategy, Xen provides a dedicated Add source code workflow. You can paste the complete source into the editor or load an existing .cs file from your computer.
The first Strategy becomes the Current codebase. This is the authoritative version Xen uses when reviewing the Strategy or processing later modification requests. If you have a newer version, you can add it and select Replace current source to make that file the new current Strategy.
Keeping the source separate from the normal conversation gives Xen a clear codebase to work from. If a complete NinjaScript Strategy is pasted into the normal message box, Xen can redirect it to the source-code workflow rather than treating a large code file as another chat message.
Add Other Strategies for Merging or Reference
An existing-code project can contain up to four source files. Additional NinjaScript files can be attached when you want Xen to incorporate functionality from another Strategy or study an existing implementation as a reference.
When another file is added, you choose how it should be used:
- Integrate with current source tells Xen to incorporate relevant functionality into the current Strategy.
- Use as reference only lets Xen study the source without automatically merging its functionality.
- Replace current source makes the newly attached file the authoritative Strategy.
Files can also be removed when they are obsolete or were attached by mistake. If the current source is removed, another current source must be selected before Xen can continue modifying the Strategy.
Review the Existing Strategy Before Modifying It
Once the current source has been saved, you can use Review strategy to analyse the attached NinjaScript before asking Xen to change it. The review can explain the existing behaviour, identify potential defects or development risks and highlight requirements that still need clarification.
The review itself is analysis-only. Xen does not need to rewrite the Strategy simply to explain what the existing code does. This is useful when working with unfamiliar source code or a Strategy originally written by another developer For example, suppose you have an EMA trend Strategy and want to add a trailing-stop system from another NinjaScript Strategy. The EMA Strategy can be set as the current source and the second file attached using Integrate with current source.
Before performing the merge, Xen can review the code and identify decisions that need clarification, such as whether the trailing stop should activate immediately after entry or only after a defined profit threshold. Once that decision is confirmed, it can remain with the project when the modification is requested.
Keep Requirements and Development Decisions with the Project
Existing-code projects can retain requirements, clarification answers and approved user decisions alongside the source files. When you later request another modification, Xen can work from the current source, supporting files, retained requirements, previous decisions, the latest generated version and relevant recent conversation context.
This is not unlimited AI memory. It is durable project state for existing-code tasks, intended to preserve the information needed to continue development without repeatedly sending the same source code and requirements.
When Xen returns a complete revised Strategy, that code becomes the latest working version available for the next modification. If Xen first adds a trailing stop and you later request a trading-time filter, the new change can therefore be applied to the revised Strategy rather than accidentally returning to the original source.
Build and Test Each Working Version
Code-specific actions such as Download .cs, Download Add-On, Build Check and Verify Requirements are displayed when Xen produces a complete NinjaScript file. They are not shown for analysis, clarification questions, requirements lists or small code snippets, making it clearer when a complete Strategy is ready for the next development stage.
After a meaningful modification, run Build Check and then compile and test the Strategy inside NinjaTrader. Keeping tested development checkpoints makes it easier to identify which change introduced a problem if unexpected behaviour appears later.
This is particularly important when merging NinjaScript from different projects. Two pieces of code can work independently but behave differently when their entry, exit, risk-management or state-management logic is combined.
Continue Developing Existing NinjaTrader Strategies with Xen
The updated workflow gives Xen a defined codebase and project state when working with existing NinjaScript. Instead of repeatedly pasting source code and trying to preserve important decisions inside a growing conversation, the Strategy, supporting files and confirmed requirements remain associated with the project.
This provides a more practical workflow for reviewing, repairing, extending or merging an existing NinjaTrader Strategy while still allowing the source to be compiled and tested at each meaningful stage of development.
