coding-stylelisted

# Coding Style Write code that explains itself through names, structure, and small functions. Treat comments as a last-mile explanation for information the code cannot express clearly. ## Comment rules - Add a comment only for non-obvious intent, invariants, constraints, workarounds, security boundaries, or surprising tradeoffs. - Keep comments short, factual, and neutral. Prefer one sentence or a compact phrase. - Explain why a surprising choice is necessary. Do not narrate what an obvious line already does. - Avoid first-person or conversational phrasing such as “I added,” “we need,” “here we,” or “this is where.” - Avoid commentary about the editing process, the prompt, the agent, or who generated the code. - Do not narrate the change itself: no before/after wording, "previously," "now," "used to," or "fixed" — state the current invariant, not the diff that produced it. - Do not add tutorial paragraphs throughout implementation code. - Delete stale, redundant, speculative, or copied comments when touching nearby code. - Preserve required API documentation, public contracts, safety warnings, citations, and legal notices. - Match the repository's established documentation convention when it is stricter than this skill. ## Language - Write code in English: identifiers, comments, docstrings, commit messages, and test names. - Keep English even when the conversation, issue, or specification is in another language. - Switch only when the user asks for another language, or w