“I wish the game could…” is a perfectly good beginning. It becomes an engineering task when you can explain the problem in terms someone else can observe.
Describe the friction
Write down what happens today, why it gets in your way, and what you would prefer to happen. Add an example. A screenshot with a specific observation is often more useful than a page of feature names.
Ask for investigation first
Give an agent the relevant repository and ask where the behavior lives, what constraints apply, and what evidence supports its answer. A plausible explanation should survive contact with the source.
Choose one result you can inspect
A small first task might be making one setting clearer, preserving a selection through a refresh, or explaining one unfamiliar log event. Define what success looks like before asking for implementation.
Keep enough context to continue
Record what changed, what you decided, what did not work, and the next useful action. Lex provides a deliberate checkpoint workflow for this kind of continuity. Its public evaluation guide can help determine whether it fits your repository.
Review the result together
An agent can write code and still misunderstand the experience you intended. Inspect the behavior, ask how it was verified, and distinguish a successful build from a working feature.
You do not need to begin with an elaborate toolchain. Begin with one idea, enough evidence to understand it, and a change small enough to assess.