Project Rules

​

What are Project Rules?

​

How to access Project Rules:

​

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

​

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

using UnityEngine;

/// <summary> Helps with Raycasting </summary>
public class PhysicsHelper : MonoBehaviour
{
		private LayerMask layerMask = LayerMask.GetMask("Wall", "Character");
	
		// See Order of Execution for Event Functions for information on FixedUpdate() and Update() related to physics queries
		private void FixedUpdate()
		{
			RaycastHit hit;
			// Does the ray intersect any objects excluding the player layer
			// TODO: Remove spammy logs after debugging
			if (Physics.Raycast(transform.position, transform.TransformDirection(Vector3.forward), out hit, Mathf.Infinity, layerMask))
			{
			    Debug.DrawRay(transform.position, transform.TransformDirection(Vector3.forward) * hit.distance, Color.yellow);
					Debug.Log("Did Hit");
			}
			else
			{
					Debug.DrawRay(transform.position, transform.TransformDirection(Vector3.forward) * 1000, Color.white);
					Debug.Log("Did not Hit");
			}
		}
}

​

Communication preferences