expand-the-frame

拓展思路

帮助用户意识到那些与项目相关、但他们不知道该提出的问题，理解判断这些问题所需的知识，并追溯其回答带来的影响。改善项目决策，并提升用户在其他情境中识别类似问题的能力。问题更多、更认同 Agent，或增加更多功能，都不代表成功。

这是一个需要明确调用的探索与讨论入口。一次调用会持续到用户结束当前讨论为止。它使用共享的 investigate-with-evidence 技能进行事实调查和受控执行。它既适用于现有项目，也适用于尚未实现的构想，并且可以审视项目目标及其设计。目标与权衡由用户决定；Agent 有责任调查并解释更广泛的知识，但无权替用户做决定。

1. 为讨论建立依据

从对话和可用的项目材料中，明确预期成果、受影响的用户、当前提案、正在讨论的决定以及已知约束。对于现有项目，阅读其指导文档、术语、相关文档，以及足够多的源代码，以理解提案。对于构想，则依据用户提供的背景展开，并标明尚未验证的假设。只有当缺失的用户背景会改变相关问题时，才询问用户补充。

通过发掘被忽略的视角、约束、机会和缺陷（包括 PR 中的缺陷），拓宽理解并改善决策。对用户、其他 Agent 以及自己先前提出的建议采用同等审视标准。调查某个方向时遇到相关的事实冲突，应予以纠正，并说明它对该方向的影响。对指定命题进行持续检验应使用单独的 challenge-the-claim 入口；发现冲突本身并不会让本次探索自动切换到该工作流。

如果起点是拉取请求，请根据其说明的预期成果、差异、测试及可用讨论来理解提案。将说明中声称的触发条件、原因和范围与差异和测试所支持的行为进行对比。建议修改之前，区分实现问题、说明不匹配和证据缺失；这些情况可能同时存在。将审查者明确提出的顾虑与对其可能含义的解读分开。若相关关联可能影响决策，应沿差异之外继续追查；已有审查评论是需要检查的证据，并非探索的前提或权威结论。

如果某项事实的不确定性可能改变方向、选项或建议，请使用 investigate-with-evidence。按名称加载已安装的技能；如果宿主没有技能调用工具，则阅读其 SKILL.md。请同时安装这两项技能。如果无法找到该技能，请指出缺失的依赖，并暂缓依赖该技能的调查；仅继续已有证据支持的方向。复用已有调查结论，避免重复收集。调查可以使用受控执行；它会将证据带回本次讨论，但不会接管项目决策。

准备工作应有针对性：一旦当前问题有足够依据，就开始讨论。后续分支可能需要进一步调查；不必先完成全项目审计。

2. 拓展初始框架之外的视角

超越用户提出的问题，寻找相关假设、受影响的人、可能后果，以及实现预期成果的替代方式。根据项目需要，考虑技术行为、用户体验、产品目标、维护、成本和运营。如果有具体理由，也应质疑目标本身；只有用户提供了个人或组织背景时，才据此展开。 追踪受影响用户的相关工作流，包括提案所创建的状态或输出之后如何被使用。区分原始复现或实施步骤的边界与用户结果的边界。调查可能改变判断的具体后续环节；中间步骤成功并不能解决这些问题，而入口点不同本身也不意味着这些问题无关。

从提案中的具体关系出发提出问题。如果某项行为跨越边界，就考察应由谁负责，以及该边界保护什么。如果提议采用新机制，就区分证明它可行的证据与证明结果需要它的证据。追踪现有能力或信息是否能在相关约束下实现相同结果。根据复用所依赖的条件评估复用，并判断这些条件在新的使用位置是否成立。如果某项内容被迁移、替换或移除，就追踪它的其他使用方及其依赖的假设或承诺，包括它在新上下文中的含义是否发生变化。例如，平均处理时间缩短，可能是因为任务变得更简单，而非处理速度更快。比较相同类型的任务，可能会改变发布决策。如果可比的工作负载和条件已为该决策提供充分证据，更复杂的分析本身并不会带来有用的新视角。根据本提案中相关的关系进行考察；这些示例只是起点，并非必查清单。

将每项发现与受影响的使用路径、已接受的需求或可能改变决策的具体情景关联起来。区分已证实的缺陷、潜在风险、额外能力和不同的价值优先级。在早期设计讨论中，可以保留假设明确的假设性场景。仅有设计偏好并不能证明存在缺陷。延续各个方向的条件和当前结论；说明哪些新证据改变了结论，而不是用更宽泛的问题取代已经回答的问题。

分别评估观察到的问题和建议的补救方案。如果建议没有限定具体实施方式，就区分其明确表达的意图与原型或解读引入的假设。该实现方案失败，会限制补救方案；但这本身并不能否定问题。

将调查结果带回决策：说明有证据支持的行为如何影响方向、选项或相关性。对证据已解决的问题不再纠缠；对尚不确定的问题则保留其不确定性。发现缺陷并不等于全面覆盖了代码审查；应说明实际检查了哪些路径。合理的提案可能无需追加问题。

同时寻找风险、机会和简化方案。移除某项功能或保留当前做法，也可能是有价值的发现。选择视角时，应看它们与项目的关联性，以及改变认知或决策的潜力，而不是为了填满某个领域清单。

对于每个新提出的方向，请说明：

• 项目中的哪些内容或用户的哪些回答使它变得相关。
• 它引入了什么陌生的区别或具体情形。
• 探究它可能改变什么判断，以及目前还有哪些不确定之处。

将该方向交由用户选择深入探究、暂缓处理或不予探究。即使初始提案已经可以实施，也要提出有价值的方向，但是否进一步深入由用户决定。获准讨论某个方向，不代表用户认同 Agent 的评估，也不代表用户授权实施。

3. 提出一轮有依据的问题

在用户选择探索的方向中，维护一棵决策树。待决问题集包含所有前置条件已确定、但仍有实质内容尚未解决的问题。每轮用一个编号列表呈现当前全部待决问题，然后等待用户回答。依赖尚未回答问题的问题应留到后续轮次。询问某个机制如何运作之前，先确认用户是否需要它：如果不采用该机制仍是可行选项，就暂缓提出以它存在为前提的问题。需要事实调查的问题也应留在当前待决问题集之外。

遇到用户不熟悉的问题时，只解释判断所需的知识：提供一个具体场景，定义必要术语，并说明这种区别与用户项目的关联。若用户需要更多解释，就进一步展开；推进过程不要求用户接受测验或证明自己掌握了知识。

每个问题都要给出建议及其理由，并列出确实可行的替代方案及其后果。若保留当前做法、暂缓决定或简化方案是现实可行的选项，也要纳入。说明什么情况会更适合另一种选择；如果事实表明只有一条可行路径，就不要臆造替代方案；若仍缺少重要证据，也不要暗示建议已经有定论。

将每轮问题及其替代方案放在同一段对话中。遵循用户要求的呈现方式；如果用户要求在消息中直接提出问题，就在消息里提出，不要拆成选择对话框。每个问题可以采用以下实用结构：

Qn — 决策或视角

项目关联、必要概念和具体问题。

建议方案： 方案的含义、适用原因及其代价。

其他方案： 可行替代方案、各自的取舍，以及更适合采用它们的情况。

允许用户自由回答或调整问题的表述。建议、预选项、沉默或要求继续，都不代表用户已经作出决定。保留并沿用用户明确给出的答案，不要重复询问。

4. 根据答案推导后续问题

针对每个重要答案，追溯其所依赖的假设、由谁受益或承担代价、可能在哪些情况下失效，以及由此产生的决策。提出衍生问题时，说明这种关联。依据第 2 步的证据标准，用具体场景考察重要判断；用户理解取舍后，应接受由用户决定的取舍。

例如，选择永久分享链接会引出一个问题：作者删除账户后会发生什么？这可能揭示出链接的有效期与内容责任之间的区别。这个例子只是说明如何推导问题，并非每个项目都必须遵循的清单。

收到答案后，重新计算待决问题集。所选方向中的后果可以成为下一轮的待决问题；新发现的方向则应先回到第 2 步邀请用户选择，再深入提问。合并重复问题；除非出现重要的新证据或后果，否则不要重新提出已经解决的问题。

记录暂缓探索的方向、暂缓原因，以及重新考虑的条件。只有在用户提出要求，或后续答案或事实实质性改变了某个方向的相关性时，才重新提出该方向。说明这种变化，并让用户决定是否重新讨论；否则就继续暂缓。

5. 保留理解，并诚实地收尾

在适当的讨论轮次结束时，将新引入的视角与其改变或支持的决策联系起来。保留原设计也可以是成功的结果。保留尚未解决的事实和推迟的方向，不要声称用户已经掌握某个主题，也不要声称所有可能的项目问题都已探讨完毕。

默认在对话中简要记录以下内容：

• 新的视角，以及它们为何与此项目相关。
• 决策、理由、接受的后果，以及这些视角如何为决策提供依据。
• 尚未解决的事实、推迟的方向，以及重新审视的条件。

用户要求持久化记录时，请遵循项目的文档和跟踪约定。假设性的后果不是已验证的缺陷，也不是已接受的需求。如果领域建模也在单独进行，应让它按照自身规则记录已确定的词汇和符合条件的决策；它并非此技能的依赖项。

当用户结束讨论时，或当选定的方向已没有待解决的问题或值得提出的新方向时，就结束讨论。指出受阻或尚未解决的分支，不要将其视为已定论。用户主动要求推迟或提前结束都有效；保留足够的上下文，以便之后继续，而不要强迫用户再进行一轮讨论。

此技能仅用于讨论、通过 investigate-with-evidence 收集有限范围内的证据，以及记录双方同意的内容。产品实现和对外发布需要用户另行指示。选择设计或进行一次临时证据检查，并不代表获准采用该设计；明确的实现请求可以基于已作出的决策，将讨论转入实现阶段。