用途：把《Shape Up》第3、14章的方法迁移到开发任务的范围管理中，帮助在需求不断膨胀时划定本轮边界，区分必要项与可选项，并判断何时交付、延长或转回调查。适用于“小功能越做越大”“顺便重构”“到期还有工作，该不该继续”等问题。
主要能力：开工时从现有上下文提取谁在什么场景、哪一步遇到困难、现在如何绕过，以及用户明确要交付什么；把用户愿意投入的时间/工作边界记为 appetite（投入上限），不写成预计工时；用一张简短范围卡进入工作，包含当前困难与目标、本轮边界、必要项及验收、可选项与未知。工作中对每个新增事项作取舍，判断不做会怎样、影响谁、发生可能性与实际后果，再决定是否属于本轮必要项。收尾时对照用户原本的困难和约定验收，给出证据与缺口，判断交付、延长或转回调查。
使用方式：范围卡是执行依据，不是默认加一道审批。用户只要建议就交卡；用户已要求实施就继续完成授权工作。缺少预算时标明未给定，先提出与现有需求相称的范围；只有取舍确实依赖预算时才追问。保留用户明确需求、实现目标必需的正确性和既有验证要求，有冲突时说明并提出调整方案。用户明确追加目标时更新范围和验收。
限制：书中的团队周数不能换算成模型的分钟数，也不能承诺未经核实的完成时间。不能仅用“优化”“重构 2.0”定义完成。模糊的“更专业一点”先落到具体效果，避免自动扩成整个系统重做。若用户要求实施，只有范围卡不能算完成；若验收失败，不能因缩小措辞而改判通过。最后可指出本次真正用到的章节小节、附上原文链接，并给一个与此次取舍相关的问题。用户不必先读书才能使用。