doc-comments

## Purpose Developer-facing comments and doc comments in this repository are read by contributors, months or years after they were written, with none of the context you have right now. This skill defines who that reader is, what each kind of comment is for, and which patterns are banned. **Scope boundary:** rustdoc inside `declare_lint_rule!` / `declare_assist_rule!` blocks is end-user documentation generated into the website. Load this skill for comment hygiene, but use [lint-rule-development](../lint-rule-development/SKILL.md) for the audience, content structure, examples, and option documentation. Its content rules take precedence for those blocks. ## The Reader For developer-facing comments, write for a Biome contributor who is competent in Rust but has **no access to your current context**: not this conversation, not the pull request, not the issue, not the diff. They see only the repository at HEAD. Two consequences follow directly: 1. **Never narrate change history.** Words like "now", "previously", "no longer", "the new approach" are meaningless at HEAD, where only one approach exists. State how the code works, not how it came to be. 2. **Never address the reviewer.** A comment that argues your change is correct ("this properly handles X") belongs in the PR description, not in the source. The comment must justify the code as it stands, permanently. ## Three Kinds of Documentation, Three Different Jobs | Kind | Job | Contains | | ---- | --- | ------...