Rules are persistent, custom instructions for Bezi to follow. They are added directly to the system prompt and given extra weight, so if your instructions conflict with our existing system prompt, your preferences are prioritized. Use rules to ensure Bezi’s ouput is consistent with your project structure, preferences, and workflows.Project Rules only apply to the Unity project they’re set in. Currently, there is no non-manual way to share Rules across projects or accounts (coming soon!).
Project Rules are universal principles for how Bezi works with a given project
Define project-specific structures and systems (unity version, render pipeline, default packages, etc.)
Define how Bezi should interact with certain systems or information types
Customize response formats, explanations, code style, etc.
To access Project Rules: Click the icon in the top left of your app, then selectProject Rulesto open the page.How to decide if information should live in a Rule or a Page:
RULE: Define how Bezi should interact with information in Unity and Pages, game-wide “constants” so Bezi doesn’t have to think about them, etc.
PAGE: Explain how a specific thing works, how something should be implemented, etc,
Include real, positive examples from the project: For each rule, find examples of you want Bezi to copy and list as many as possible, to help Bezi recognize the patterns
Use strong language: Use caps and clear words like “ALWAYS,” “IMPORTANT,” and “CRITICAL” to signal importance
Prioritize by importance: Place CRITICAL rules at the top, and move less important ones down
Enrich references: Provide library name, version, official website, and a direct link to scripting examples
Update your rules regularly: Rules must evolve alonside your project. We don’t recommend asking Bezi to write your project rules, as you know what is most important.
Keep Project Rules succinct: Make sure to remove old rules and keep the document brief. Too much information will increase likelihood Bezi misses something
Never use anti-examples (e.g. “don’t do X”), as Bezi may reference the example without taking into account the context it’s used in
Never write conditional rules, using “IF” or “SHOULD” because rules must be constants and Bezi will not reliably follow these instructions
Don’t include conflicting information in your rules because Bezi will break one or both rules
Don’t make your rules too long because the more information Bezi has to adhere to, the more likely it is to miss something or to find conflicting instructions
Don’t “set and forget” your rules - this should be a living document that changes as your project and requirements evolve! Old rules need to be cleared out to make room for new ones
