用途：lean-comments 是一套用于审计、撰写和精简第一方源码注释与声明级文档的技能规范，跨语言适用，目标是让代码库更易理解、更安全维护，同时把注释量降到最低。默认立场是不写注释。
核心判定：在保留或添加普通注释前，想象删掉它，问称职的维护者（数月后、在 HEAD 处阅读、无法访问当前对话、diff、PR 或 issue 讨论）是否会因此丢失无法从代码、命名、类型、签名、结构、测试、配置或邻近上下文合理恢复的信息。若不会，删除或省略；若不确定，倾向于不写。
什么值得保留：有意为之的反直觉代码的原因、外部约束或兼容性要求、重要不变量或微妙边界情况、有意义的权衡或必要 workaround、非显然的耦合、顺序／时序／生命周期／并发／性能／安全约束、以及看似更简单的实现为何不正确。优先解释“为什么重要”，仅解释“代码做了什么”的注释通常应删除。
应删除的注释：复述代码、旁白式叙述下一句或明显控制流、解释显然的守卫／返回／赋值／分支、重复声明名或类型签名、充当分区标题或视觉分隔符、保留过时的变更历史、对审查者说话或为当前改动辩护、以及仅靠 Never、Always、Important、Security 等词强化语气而无信息的注释。
决策顺序：先判断必要性；能通过微小的行为保持不变的可读性改进（改局部命名、提取布尔、简化局部控制流）消除需求则先用代码表达；必要但含冗余则缩短；必要但不清、不准、过时则重写；属于声明契约、语义或用法则改用声明文档；只有已必要、最小、准确、持久且风格正确时才原样保留。不得把不必要的注释润色成文档。
声明文档：这不是覆盖率练习。公开库、SDK、插件、扩展 API 应更倾向写文档；内部 helper、简单 CRUD、适配器、DTO、普通数据结构应更倾向不写。不要重复类型系统，不要机械添加 @param、@returns 等标签。
运行时可见文档：Python docstring 等可能被内省或工具观察，删除或实质修改前需确认不改变受支持的运行时契约。
风格：单行实现注释尽量短、首字母大写、结尾不加句号等终止标点、不使用破折号或分号作句子标点；标识符、URL、路径、版本等技术字面量保持原样大小写与标点。多句声明文档使用正常句子标点。
特殊形式：TODO、FIXME、NOTE、HACK、XXX 等视为注释而非例外，需验证仍相关、准确、可操作，删除过时项。注释掉的代码通常是死代码，版本控制已保留历史时应删除。shebang、lint／编译器指令、构建标签、框架指令、许可证头等技术性构造需保留原样，但过时且经验证无用的指令可移除，许可证文本须保守处理。
编辑既有代码：既有注释视为不可信，代码变更导致注释不准或冗余时应在同一次改动中更新或删除，不叙述变更历史。若存在 unslop 等文字润色技能，lean-comments 仍具权威：先判必要性、删除、定形式、最小化，最后才润色措辞。具体安装方式与运行命令在本资料中暂未提供。