You need to more clearly separate how your individual modules work. Tutorial code should not need to reach into UI code, but the UI code interfaces should expose all the data necessary for an external source (like game logic or a tutorial) to drive it.
For instance, every UI element might have a way to enable/disable it, hide/show it, or highlight it. The code that decides which elements are visible or such is not in the UI itself, it's in a separate game logic system. This system can then query a ruleset about which actions should be available and what to do in response to a UI event. These rules can describe different game modes or tutorial states.
The nuts and bolts of game play should also include an abstraction to allow game events to flow from these rules. You'd have a submodule for moving units, attacking, whatever concrete actions you can perform or the AI can do. In typical game flow you might want an AI module driving decisions of non-player characters and attacks which request random damage amounts. In tutorial mode you probably want purely scripted "AI" with pre-determined attack values.
It's all just a matter of layering. Make each module responsible for only one thing and then have "glue modules" for logic that can either simply be different implementations for different game modes or the tutorial or which is completely data-driven if you have the time to build that.