LLM Documentation Rules for Daydreams

---
description: This is for documentation
globs: .mdx, .md
---

## LLM Documentation Rules for Daydreams

### Rule 1: Use the Project Name Consistently
1. **Always** refer to the project as **“Daydreams”** with exact spelling and capitalization.  
2. **Never** use unofficial nicknames (e.g., “DD,” “Day Dreams”) unless explicitly instructed.  
3. **Avoid** pronoun ambiguity. If uncertain, repeat “Daydreams” rather than relying on “it” or “the application.”  

### Rule 2: Write Concisely and Clearly
1. **Keep sentences short** and single-purpose wherever possible.  
2. **Use active voice** (e.g., “You can create a new dream” instead of “A new dream can be created…”).  
3. **Eliminate filler words** (e.g., “basically,” “in order to,” “actually”) for direct, succinct instructions.  
4. **Break up** complex or multi-step information into smaller paragraphs or lists.

### Rule 3: Be Specific and Factually Accurate
1. **Provide exact details** (file names, ports, step counts, commands) rather than vague references.  
2. **Confirm technical information** against the actual behavior of Daydreams before mentioning it.  
3. **Avoid hyperbole** or subjective claims (e.g., “best tool,” “industry-leading”) unless verified.  
4. **Only use absolute terms** (“always,” “never”) if they are 100% accurate for Daydreams. Otherwise, include conditions.

### Rule 4: Use a User-Centric Perspective
1. **Address readers directly** (“you,” “your project”) when possible.  
2. **Focus on tasks** users want to achieve (e.g., “How to create a project,” “How to share a dream”).  
3. **Explain benefits** or outcomes of features (e.g., “This lets you continue designing without lag”).  
4. **Anticipate user questions**. If a step might prompt “What next?” or “Which format?,” answer preemptively.

### Rule 5: Maintain Consistent Formatting
1. **Apply a uniform heading structure** (e.g., H1, H2, H3) and do not vary format arbitrarily.  
2. **Use bold** for UI labels (e.g., **Save**, **Settings**).  
3. **Use inline `code`** for code elements, filenames, or commands.  
4. **Numbered lists** for sequential steps; **bulleted lists** for related items.  
5. **Apply the same style** (punctuation, capitalization) to all headings, callouts (Note:, Tip:, Warning:), and examples.

### Rule 6: Include Practical, Relevant Examples
1. **Provide at least one example** for complex tasks (e.g., a code snippet showing how to run a command).  
2. **Use realistic Daydreams scenarios** rather than generic placeholders (e.g., “MyFirstDream” instead of “foo”).  
3. **Display input and output** if demonstrating commands or console operations.  
4. **Explain or annotate** examples if the purpose or result might be unclear.

### Rule 7: Explicitly State Prerequisites
1. **Include a “Prerequisites” section** at the start of guides or major sections when necessary.  
2. **List required tools** (e.g., Java 11, Daydreams version 3.0), permissions, or background knowledge.  
3. **Provide links** or instructions if the prerequisite is non-trivial (e.g., “How to install Java 11”).  
4. **Use clear version references** or OS details if the instructions are version/OS-specific.

### Rule 8: Keep Documentation Up-to-Date
1. **Update docs** with every feature or UI change in Daydreams.  
2. **Conduct periodic reviews** (per release or scheduled intervals) to remove or revise outdated info.  
3. **Track differences** between major versions (e.g., “This feature was removed in Daydreams 4.0”).  
4. **Incorporate user feedback** to clarify sections that cause confusion.

### Rule 9: Avoid Jargon or Define It Clearly
1. **Use plain language** whenever possible (“start” vs. “initialize,” “stop” vs. “terminate”).  
2. **Explain or spell out** any acronyms or specialized Daydreams terminology upon first use.  
3. **Stick to consistent terminology** across all docs (e.g., always say “scene,” not sometimes “stage”).  
4. **Eliminate in-house slang** or code names unless they are defined for the end-user.