Decision to Delivery 是一个面向复杂决策与交付场景的技能，目标是把交织在一起的研究、职业或商业决策以及工具构建，转化为一个有边界、可执行的交付流程。它的核心主张是：让下一个有用的成果变得明确，把不确定性路由到能够解决它的行动上，并完成服务于该成果的最小产物。它同时提醒，表面上的工作流问题应当被视为假设，而不是对用户的诊断。
建立工作约定
在提出更多工作之前，先阅读实际简报和当前产物。检查相关既往对话时，只把它当作背景，而不是新的授权。需要分别识别：用户的决策（例如某个职位是否合适）、所需交付物（例如案例回复）、外部验证（例如付费意愿）、以及可选的可复用工具。
通过一轮简短的高价值提问，确定即时目标、期望成果、约束、截止时间、时间预算和未完成承诺。在获得授权的情况下检查带日期的沟通记录：自我设定的截止时间和已经做出的承诺可能不同，需要把这种差异呈现出来，而不是悄悄改变其中任何一个。
提出一个具体的流程，包含输入、输出、负责人、时间限制、停止和重启标准。如果用户要求对流程进行审批，那么在创建技能或应用流程之前必须获得明确批准，并在中断期间保持这一边界。如果当前请求已经授权了这项工作，则不要额外增加审批关卡。
映射与路由
把每个所需输出映射到现有材料、缺失的关键决策以及最小的下一步行动。把案例要求与有吸引力的演示或可选基础设施区分开，避免维护第二套相互竞争的论证版本。
对于每个关键未知，选择能够回答它的路径：
证据：属于可从现有来源发现的事实。有用的下一步是检查来源，记录日期、范围和局限。
实验：涉及需求、采用、性能或预测价值。有用的下一步是提出有边界的测试，以及可观察的成功或停止标准。
承诺：涉及能力、权限、所有权、预算、激励。有用的下一步是找到能够做出承诺的人，记录实际达成的约定。
偏好：涉及期望的工作、风险容忍度、呈现重点。只有在答案会改变下一步行动时，才向用户提问。
研究无法确立一个人的承诺，可运行的演示无法确立客户需求，有来源的观察也不是商业契合度的证明。这些区分需要保留在交付物本身之中。
只记录关键决策：问题、当前立场、来源或假设、下一步行动、负责人、停止条件和重启条件。让未解决的承诺保持可见，但不要生成一个详尽的新队列。
在约定范围内交付
优先保证完整覆盖和一条可靠的用户旅程，然后再考虑深度打磨。在有帮助时复用现有应用或数据；检查并备份被触及的文件，保留并行工作和评审决策，把同步引用视为只读。当增加一个展示视图可以避免改动活跃的研究系统时，优先采用这种附加方式。
按照证据改变决策或支撑展示内容的能力来排序审查。不要仅仅为了让演示看起来完整，就清理大量积压或扩大批次。准确标注目标候选、假设、估算、AI 预计算输出和模拟流程。绝不能用虚构记录替代承诺提供的真实示例。
在信息不可用且简报允许假设时，使用可编辑的假设，并展示其影响和来源。提出未来测试，而不是声称已获得外部验证。当用户排除新输入时，保留空白，而不是编造答案或联系他人。
用下一步学习或交付来约束工具化。询问什么成果能够证明扩展是合理的；如果没有任何成果会改变下一步行动，就搁置该增强。如果时间收紧，先削减可选交互和打磨，再考虑削减必需覆盖、可用的销售材料、来源或可靠导航。
收尾与重启
按照目标用户实际体验的方式验证产物：渲染行为、核心旅程、计算、证据链接和标签。区分技术完成、外部验证和用户评审。
交接内容包括：交付物、变更、验证、关键限制、已做出的决策、带有负责人的未解决承诺，以及下一步行动。在可用时，通过用户偏好的评审渠道进行通知。
当约定的必需输出已经存在且可用、证据或假设清晰可读、剩余未知都有路径和负责人时，停止。仅在出现矛盾证据、重大约束变化、旅程失败或明确反馈时重启。新的外观类想法不需要重启一个已完成的范围。
发送、发布、部署以及其他有后果的外部行动，需要各自获得适当的授权；批准本操作流程并不等于授予这些授权。