用途：当计划或设计显得过度工程化，或用户提出“这太多了”“我首先真正需要什么”“MVP”时，用 slim-down 把范围裁剪到一个增量——能交付价值且不阻碍后续成长的最小一步。核心原则是砍范围而非砍质量：去掉功能，不降低品质，增量要小但可扩展，不留死路。
主要能力与工作流：第一步读现状，阅读当前代码库了解已构建内容与在用模式，阅读待精简的计划或规格，区分新工作与已完成或部分完成的工作，并用简短块总结当前状态、完整目标与差距。第二步识别核心，用一句话描述该计划必须具备的核心价值，作为后续判断的锚点。第三步按保留、延后、舍弃分类：核心必需项保留；有价值但暂不需要的延后，并设计成日后可加；锦上添花、投机性或解决尚不存在问题的舍弃。排序规则包括：仅在 10 倍规模才需要的延后；处理尚未发生的边缘情况的延后；移除不破坏核心的延后；为灵活性新增抽象层的舍弃，除非已证明必要；现有代码已部分处理的保留，完成而非重做。第四步检查可扩展性，确认保留项不会阻塞延后项、当前增量不会造成被迫重写的死路，否则调整设计。第五步写出增量定义：目标一句话、交付项、延后项、舍弃项及原因、完成判定标准，可按用户要求写入文件。
使用方式与限制：以对话方式与用户协作，展示分类表并允许用户调整。裁剪时尊重现有代码，不替换可用部分；优先延后而非舍弃；延后时说明当前设计如何为其留出空间；表述要具体，例如“延后 OAuth，先用 API key，认证中间件接口保持不变”。不要在此过程中新增功能、重新设计架构、空泛地说“做个 MVP”、砍掉用户已构建的内容，也不要假定用户想要最便宜的方案，他们要的是最小可用方案。资料未提供安装命令、平台支持、收费或价格信息。