用途：这是一个“强制简化”的技能，在任务生命周期的任意阶段使用——规划时、实现前或审阅已写好的代码 diff 时——找出可以通过合理取舍削减的内容，并以明确决策的形式呈现给用户。目标不是追求极简美学，而是让用户保有对复杂度的决策权。
使用时机与信号：任务跨越多个 UI 状态、屏幕或流程；表面涉及通知、历史、撤销、实时或批量行为；加入了并非核心诉求却“顺手”的行为；计划引入队列、worker、缓存层或后台任务；新增包、数据库表或外部服务；使用流式、websockets、SSE；涉及迁移或回填；新增管理面或认证面；请求很短但范围显得很长；diff 跨多个包但需求只提到一个。任务确实小且具体时可跳过。
两层取舍，顺序固定：先扫用户可见行为，再扫架构设计。行为层削减会删掉功能、架构和其背后代码；架构层削减移除整类实现而不影响用户所见。直接跳到代码级简化（校验、重试、抽象、循环形态）不属于本技能范围，那些属于常规代码评审。
行为层示例：整个不影响核心任务的特性、页面或流程；可合并的表单步骤；很少改动的设置（硬编码合理默认）；重复的权限层级；撤销/重做（接受操作永久或手动反转）；实时更新（改为刷新）；通知、邮件或提醒；批量操作；移动端支持；定制空状态；多语言；键盘快捷键、拖拽、动画；可用脚本或数据库完成的管理 UI；进度指示、历史/审计日志；可逆操作上的确认弹窗。
架构层示例：后台任务/队列/worker（够快就内联执行）；缓存层；单体仓库中的新包（先并入已有包）；新数据库表（加列或用 JSON 列）；新外部服务或集成；实时基础设施（改为轮询或刷新）；流式响应；独立管理应用（改为现有应用加受控路由）；事件总线/发布订阅（只有一两个下游时直接调用）；定时任务；迁移或回填；新认证面（复用已有会话/令牌）。
取舍的表达格式：削减 X。作为交换，用户接受 Y。这没问题，因为 Z。“因为”是承重部分，需说明为何在该具体情境下可接受。多数任务只有 1–3 个真实机会，通常偏向行为层，不要凑数。
呈现方式：行动前停下来并询问，不要把取舍打包进计划后径直推进，也不要在审阅代码后默默略过。按阶段调整措辞：规划或实现前用“开始前，我建议以下取舍来保持小范围……告诉我哪些不要削减，我会把它们构建进去”；实现后评审用“看现在的东西，我建议削减以下几点来简化……要我移除哪些吗”。三条规则：具体（点名被移除的行为、状态、特性或代码路径，实现后需引用文件）；以削减开头而非保留；不要加“我建议”之类的主观表态。
不可削减项：安全边界（认证检查、授权、注入安全）、数据完整性（事务、唯一约束、引用完整性）、系统边界处的显式失败（用户可见错误消息、运维日志）以及用户原始请求中明确要求的内容。若想削减这些，应重新定义为 bug 而非取舍。
限制：本技能不涉及代码级细节简化；不提供具体价格、平台或效果承诺；除上述信号外没有更多量化触发条件。