​
What are Project Rules?

Persistent, reusable context that Bezi will apply to every prompt response in the project. Adding Project Rules is the best way to ensure Bezi’s assistance will be consistent with your project’s goals, preferences, and workflows.
Project Rules only apply to the Unity project they’re set in. To apply the same Project Rules across multiple projects, finalize them in one project, then paste them into the other Project Rules pages.

​
How to access Project Rules:

To access your Project Rules, click the icon in the top left of your app to open the Sidebar then select Project Rules to open the page. Project Rules comes with default rules. You can edit those or write your own from scratch.

​
What to use Project Rules for:

  1. Output and structural guidelines: define code syntax, input/UI systems, debug strategies, domain-specific knowledge, project-specific workflows, and more
  2. Communication preferences: set Bezi’s tone of voice, your proficiency level, how much instruction you want, and more

​
Project Rules writing guide

Project Rules can be written in natural languange. Like a prompt, an effective Project Rule is focused on a specific purpose. Do not try to pack too much into a single rule.
You cannot make Bezi do something it’s incapable of doing via a project rule. Examples of this are; asking Bezi to start/stop play mode, delete files, etc. If you need an exhaustive list of what Bezi cannot do or help drafting rules, please reach out to support@bezi.com.

​
Things to do

  1. ALWAYS write direct, clear instructions: only use decisive verbs and be very specific
    1. GOOD: Follow code style rules defined in MyProjectStyle.md
    2. GOOD: NEVER use the Singleton design pattern
    3. BAD: write good code
    4. BAD: follow all SOLID principles
  2. Expand definitions with context and synonyms: Explain why the rule matters, if you want Bezi to identify something in your project give multiple examples, etc.
  3. Always add real, positive examples from the project: Find examples of situations that you want Bezi to mirror and list as many as possible, to help Bezi recognize the patterns
  4. Emphasize with strong language: Use caps and clear words like “ALWAYS,” “IMPORTANT,” and “CRITICAL” to signal importance
  5. Prioritize by importance: Place CRITICAL rules at the top, and move less important ones down
  6. Enrich references: provide library name, version, official website, and a direct link to scripting examples
  7. Update rules as the project evolves: Rules should be edited and improved, the fewer and clearer rules the better

​
Things not to do

  1. Do not write rules that use if or when: Rules must be set as universal principles
  2. Do not use vague language: Statements should be clear and decisive, “always” or “never”
  3. Do not use negative examples: If you are telling Bezi never to do something, define what it should do instead and give example(s) of the positive behavior
  4. Do not use negative examples: If you are telling Bezi never to do something, define what it should do instead and give example(s) of the positive behavior
  5. Do not have too much information in a single rule: Rules must be simple and clear. Write out the entire rule and, if there is too much information it in, break it into multiple rules and give it its own section
  6. Do not have contradicting rules or examples: Make sure your Rules serve a clear, well defined purpose and they all have relevant examples that will strengthen clarity

​
Project Rule Examples

​
Output and structural guidelines

​
Communication preferences