coldbox-documenterlisted

# ColdBox Documenter ## When to Use This Skill Use this skill when: - Writing or reviewing documentation comments for any ColdBox component - Deciding what information belongs in a block comment vs inline code comments - Preparing a ColdBox application for DocBox API documentation generation - Establishing documentation standards across a development team ## Language Mode Reference Examples use **BoxLang (`.bx`)** syntax by default. Adapt for your target language: | Concept | BoxLang (`.bx`) | CFML (`.cfc`) | |---------|-----------------|---------------| | Class declaration | `class [extends="..."] {` | `component [extends="..."] {` | | DI annotation | `@inject` above `property name="svc";` | `property name="svc" inject="svc";` | | View templates | `.bxm` suffix | `.cfm` / `.cfml` suffix | | Tag prefix | `<bx:if>`, `<bx:output>`, `<bx:set>` | `<cfif>`, `<cfoutput>`, `<cfset>` | > **CFML Compat Mode**: With BoxLang + CFML Compat module, `.bx` and `.cfc` files coexist freely. BoxLang-native classes use `class {}` (`.bx` files); CFML-compat classes use `component {}` (`.cfc` files). ## Guiding Principles 1. **Document the contract, not the implementation.** Comments should describe *what* and *why*, not *how*. The code already shows how. 2. **Prioritize public API.** Every public method needs a comment. Private/package-private methods need one only when the intent is not obvious. 3. **Be concise but complete.** One sharp sentence is better than three vague ones. 4. **Kee