preflight

预先调研

/route 会引导至 /preflight；它不会取代 /route。只有在路由确定当前的直接需求是范围明确的前期调研后，才使用此技能。如果你还没有选定主导技能路径，请停止——先使用 /route。

你即将着手处理某件事：$ARGUMENTS

首先，你需要了解这件事涉及什么。当前的任务是正确判断这项前期调研应投入多少精力。

做得太少和做得太多一样糟糕。你必须估算最合适的投入程度，并尽可能保留 token。

你可能需要：

• 澄清含糊的任务
• 有条理地诊断故障
• 撰写或评审一份周全、详尽且符合实现范围的设计文档
• 高效执行经过充分准备的计划
• 通过委派给子 Agent 来保留自己的上下文

不要用此技能来判断任务属于 /slice、/design、/execute 还是其他主导技能。必须先做出这个判断。

如果你无法判断 /preflight 是否适用，那你可能需要使用 /route，而不是此技能。

只需了解足以向用户提出正确澄清问题的信息。这些问题可能包括：调研应做到多深入？还有哪些地方不明确？哪些假设可以放心沿用？

如果你追着过程中冒出的问题不断深挖，就会像氦气球一样飘向广阔天空，消失不见。

相反，请按以下步骤操作：

1. 阅读眼前的材料
2. 盘点相关的 /retrieve-memory 和 /canon
3. 扩大搜索范围前，确认停止条件
4. 事先明确说明：

• 具体需要了解什么。
• 即使没有找到所有答案，具体会在何时停止。

5. 保持好奇并收集后续问题，但不要偏离当前任务去追查它们。
6. 达到停止条件后就停下。
7. 在宣布已准备就绪前，使用以下标题作出批判性评估：

• 已确认的输入
• 将带入下一步的假设
• 尚未解决的问题、风险或依赖项
• 矛盾或含糊之处（包括产物之间，或设计与实现范围之间明显存在的矛盾）

8. 如果任务涉及实现，除非明确说明以下情况之一，否则不要得出“可以继续了”“没有阻碍”或类似结论：

• 阅读主导性材料后，已无未解决的问题
• 仍有未解决的问题，但已明确接受这些问题作为实现假设

9. 即使范围相关的不确定性不构成硬性阻碍，也要认真对待。指出诸如交互语义、映射或常量的归属、阶段边界不明确、组件或 API 的选择，以及设计与自由裁量之间的差距等问题。
10. 向用户说明任何重大发现、待解问题和未解决的权衡。
11. 指明下一步的主导环节；建议切换到下一项技能或工作流，或进行进一步调查。

如果用户提出要求，请重复此流程以作进一步澄清。

指引

由广到深：先从宏观层面入手，再根据需要深入细节。

搜索顺序：

• 已提供的工件
• 相关或链接的文件、文档、工件
• doctrine search "<query>" — 如果不知道某项内容归属哪个工件，这是查找它的最省力方式：在实体语料库中执行一次排序查询。它既不会检索记忆，也不会检索参考文档，而且默认类型集不包含策略和标准——lib:reference/using-doctrine.md 说明了其范围以及如何扩大范围。
• 相关治理文件（ADR、标准、策略）——参见 /canon
• .doctrine/spec/tech/ 下的相关技术规范
• /retrieve-memory
• 待办事项（backlog list / backlog show <ID>）——这项工作是否已记录在案？哪些未完成事项与之相关？
• 知识记录（doctrine knowledge list）——尚未解决的记录是否会阻碍或影响这项工作？你决定采纳的假设 → 通过 /knowledge 记录为 ASM。
• 相关工件（暂定：可能已过时）
• 代码

约束

• 不要让 /preflight 取代 /route 的工作。
• 不要把有界研究视为开始实施的许可。
• 不要仅仅因为出现新的好奇点就扩大范围。
• 不要混淆“我可以开始编码”和“材料已就绪”。就绪意味着你已梳理出剩余的未知事项，并已解决这些事项，或将其明确列为有意识采纳的假设。

未经用户确认，不要开始实施。