Update Docs

If a change spans multiple topics, update all relevant files.

Step 3: Read the Existing Section

Read the target doc file before editing. Understand:

• Where the relevant section is (or where a new section should go)
• The style and depth of surrounding content
• Whether tables, code blocks, or prose are used for similar content

Step 4: Write the Update

Follow the existing style of the document. General conventions:

• Code examples: Use fenced C# blocks with using statements when showing API usage for the first time in a section
• Property tables: Use | Property | Default | Description | format
• Type/field tables: Use | Field | Type | Description | format
• Section hierarchy: ## for major topics, ### for subtopics within them
• Tone: Direct, concise, second-person ("Add a component", "Cast a ray")
• Removed APIs: Delete the old documentation entirely — do not leave stubs or deprecation notes unless backward compatibility shims exist in code
• New sections: Place them in logical order relative to existing content (e.g., a new raycast filtering section goes inside the existing Raycasting section, not at the end of the file)

Step 5: Update docs/README.md If Needed

If a new guide file was created, or if an existing guide's scope changed significantly, update the tables in docs/README.md to reflect it.

Checklist

• Only hand-written docs in docs/ were edited (not docs/api/)
• Code examples compile and use current API signatures
• No references to removed/old API signatures remain
• Property/field tables match the actual code
• New sections are placed logically within existing structure
• docs/README.md index is up to date if guides were added/renamed