Diet 是一个用于代码简化审查的技能（Skill），其描述为“Manual standalone lens for unearned code weight; prefer code-review as the automatic review entry point.”，即它是一个手动、独立使用的透镜，用于发现代码中未赚取其成本的重量；自动审查入口建议优先使用 code-review。
用途
Diet 的核心问题是：这段代码中，哪些部分在今天没有赚回它的维护成本？
它明确说明自己不是通用的架构或目录布局审查，而是针对那些“感觉比问题本身更重”的代码的简化审查。典型的过重表现包括：过多的辅助函数、包装器、schema 字段、列、选项、泛型层，或通过追加更多机制（而不是与现有设计整合）来解决问题的代码路径。该技能要求审查者不要偏离到目录、文件夹或模块重组，除非那正是重量问题的核心，或者用户明确要求这样做。
该技能还强调：不要假设代码来自 LLM 或智能体。如果用户提到 vibe-coded 或 agent-written 的改动，这只能作为审查视角的背景，而不是证据。不要强制删除。明确、可读、边界良好的代码即使不是最小的，也往往值得保留。目标不是更少的代码行，而是更少的义务：更少的概念、状态、分支、兼容性承诺和需要保留的接口面。
审查姿态
技能列出的指导原则（非教条）包括：
YAGNI：不要仅为假设的未来情况保留机制。 AHA / 三次法则：避免草率抽象；在提取错误的共享层之前先重复两次。 重复可能比错误的抽象更便宜。 优先整合而非追加：尽可能在现有设计中解决问题，而不是添加侧通道、一次性适配器或并行流程。 保留面向可读性的明确性：当小型辅助函数、包装器或对象能澄清命名、边界或不变式时，它可能值得其成本。
判断护栏
首先区分本质复杂性与偶然复杂性。本质复杂性来自领域、外部契约、数据生命周期、失败模式、安全性、性能或用户工作流。偶然复杂性来自当前行为并不需要的实现机制。
在建议移除之前，先确认什么会停止工作、哪些测试或契约需要改变，以及该行为是否是公开的、持久化的、已迁移的或被其他子系统使用。如果本地证据无法回答，就把它放入 Bucket II。
兼容性层、迁移字段、回退、别名、双读或双写路径，只有在存在当前发布、外部契约或有文档记录的迁移窗口时才算合理；否则通常是 Bucket II 候选。
简化优先级（简化阶梯）：删除未使用或推测性代码；内联透传包装器；让泛型代码具体化到当前用途；把追加的路径合并进现有设计；拆分分歧的情况而不是添加标志或模式；仅当局部简化无法消除底层重量时才重新设计。
当直接实现创建更少的概念、跳转、配置路径和需保留状态时，更长的直接实现可能比更短的抽象更精简。
工作流程
把审查锚定在真实代码上。阅读被修改的文件、附近的接口，以及相关时受影响的测试或文档。区分：真正服务于当前行为的代码；主要为假设的未来灵活性而存在的代码；作为变通方法被追加而非干净整合的代码。
对每一个辅助函数、包装器、字段、列、选项、模式、schema 条目或抽象层，追问：当前行为有什么依赖它？它移除了什么具体的维护成本？简化阶梯的哪一级适用，简化后代码形态是什么？
同时对照 Review Standard 中的强信号检查改动，并记录每个触发的信号。保持高标准：窄简化足够时不要建议大重构；不要制造发现，“代码已足够精简”是有效结论。
Review Standard
强信号（可能值得减肥）：字段、列、选项、配置键或钩子主要为了未来灵活性而存在，当前行为几乎不触及；辅助函数、包装器或抽象增加了一次跳转，却没有改善命名、归属、不变式或真正的复用；泛型抽象、扩展点或策略面只有一条真实路径，没有具体的第二处使用；调用方仍需了解抽象声称隐藏的内部细节；所谓共享助手现在通过标志、类型、模式或条件分支来服务分歧情况；一个概念需要反复的映射或转换层，主要是为了保留泛型设计；修复是追加在现有设计旁边而非整合进其中，并且这种变通很可能扩散；代码变得难以跟随，因为它为假设的后续工作而非今天的路径做了优化。
弱信号（通常不足以单独触发行动）：代码有点重复但仍然清晰；辅助函数是单次使用但实质改善了调用点或命名；包装器把别扭的依赖或副作用隔离在更好的接缝后面；小型对象以更容易看出不变式的方式分组相关数据；代码明确而非聪明；一点重复比共享抽象更便宜。
输出结构
Bucket I — Obvious / High-Confidence：存在无需太多讨论即可执行的简化路径。保持简洁。每项包含：看起来过重的内容、为什么今天似乎没有赚回成本、最小合理的简化方向及简化后代码形态、仅在重要时说明主要权衡。
Bucket II — Worth Discussing：存在真实权衡、不明确约束、多种可能方向，或担忧合理但支持较弱——不要夸大置信度。每项包含：看起来过重或打补丁的内容、使其不确定的决策或缺失约束、主要选项与权衡。
Keep As-Is：指出乍看可能偏重但现在确实值得的选择。明确说明何时明确性、重复或小型抽象是正确的选择。
Verdict：以四档之一收尾——Lean enough as-is；Recommended targeted simplifications；Recommended changes include design decisions；Broader redesign may be warranted after clarifying constraints。如果 Bucket I 或 Bucket II 为空，需明确说明。
片段规则
当代码证据重要时，优先使用小型嵌入片段而不是编辑器风格的行引用。每个片段第一行以注释形式放源文件路径。片段保持紧凑：辅助函数签名、schema 形状、包装层、标志、模式开关和追加的分支通常就足够。
限制与补充说明
资料未提供该技能的安装命令、运行平台、依赖要求、定价或授权信息。资料未说明它是否自动运行，也未说明其与 code-review 的具体集成方式，仅描述其为手动独立使用的审查透镜。