# AI Rules for Lua Code Generation

-   Target Environment Distinction: Clearly identify whether the request pertains to a terminal application or a LÖVE 2D graphical application. Apply the subsequent relevant rules accordingly.
-   Idiomatic Lua: Generate code that follows common Lua conventions. Utilize tables effectively, leverage first-class functions, and use standard library functions (`io`, `os`, `string`, `table`, `math`, etc.) appropriately.
-   Modularity: Structure code using Lua's module system (`require` and returning tables) for better organization and reusability.
-   Clarity and Readability: Prioritize clear, well-commented code with meaningful variable and function names.
-   Error Handling: Use standard Lua error handling patterns, typically returning `nil` plus an error message/code, or using `pcall`/`xpcall` where appropriate.

---

Use Case: Terminal Applications

-   Language: Use the Teal language (`.tl` files), a typed superset of Lua. Generate code that passes Teal type checking.
-   Typing: Leverage Teal's static type system for function signatures, records, and variables to enhance code correctness and clarity.
-   Environment: Assume a standard command-line environment. Use standard Lua `io` and `os` libraries for input, output, and system interaction.
-   Dependencies: If external libraries are needed, prefer common LuaRocks packages suitable for terminal applications.

---

Use Case: LÖVE 2D Graphical Applications

-   Language: Use plain Lua (not Teal).
-   Framework Usage: Correctly utilize the LÖVE 2D API and callbacks (e.g., `love.load`, `love.update`, `love.draw`, `love.keypressed`). Structure code logically within the LÖVE 2D game loop.
-   API Modules: Employ LÖVE 2D modules (`love.graphics`, `love.audio`, `love.keyboard`, `love.mouse`, `love.filesystem`, etc.) according to best practices.
-   Performance: Be mindful of performance, especially within `love.update` and `love.draw`. Consider factors like draw calls, image/asset loading, and efficient table usage.
-   Shader Opportunity Check: When generating code for graphical effects, drawing routines, or visual processing within LÖVE 2D:
    -   Evaluate if the task could potentially be implemented more efficiently or effectively using GLSL shaders via `love.graphics.setShader` and `love.graphics.newShader`.
    -   If a shader implementation seems like a viable and potentially beneficial alternative (e.g., for complex visual effects, batch vertex manipulation, parallel pixel processing), include a note explicitly asking me (Noah) if I would like to see an alternative implementation using a shader, briefly stating the potential benefit (e.g., "This particle effect could potentially run faster using a shader. Would you like an example using `love.graphics.newShader`?"). Do not generate the shader code unless requested.

---

General Design Approach

-   OOP Preference: Prefer procedural or functional programming styles using tables and functions. Avoid implementing object-oriented patterns with metatables unless the complexity of the state management or the nature of the problem (e.g., managing many similar game entities in LÖVE 2D) makes an OOP approach significantly clearer or more maintainable. If OOP is used, justify its necessity briefly.

---

Output Expectations

-   Completeness: Provide necessary setup code (e.g., `require` statements, basic `love.load` structure for LÖVE 2D) and context for the generated snippets.
-   Explanation: Briefly explain non-obvious Lua idioms, Teal constructs, LÖVE 2D API usage, or design choices.