/scout —— 我到底要去哪里，以及如何到达那里？
你有一个问题或一个想法，但诚实的状态是你不知道如何处理它。不是“三种方法中选哪个” —— 你还无法看清终点，以至于无法提出三种方法。此集合中的所有其他技能都假设目标已存在。而这个技能就是去寻找目标。
它的工作是勘察地形，然后选择路线 —— 不是冲向目的地，也不是开始构建第一个看起来可构建的东西。
这不是什么 —— 以便你正确调用：
- 不是
grill-me—— 那是针对你已有的计划进行采访，深度优先地走一条决策树。此技能在计划存在之前运行，并特意进行广度优先。当 scout 结束时，grill-me是一个合理的下一步。 - 不是
explain—— 那是映射已存在的代码。此技能映射尚不存在的工作。 - 不是
root-cause—— 那是针对已知症状的损坏事物。如果某物失败，请先使用那个；如果修复不明显，再之后用 scout 来应对响应。 - 不是
validate-plan/ship-check—— 那些是评判一个计划和差异。Scout 在两者之前运行，并产生它们所要评判的内容。
克制之门 —— 请先阅读。 失败的模式是编造一段旅程。如果初始阶段显示你已经可以陈述目标和到达它的步骤，请说出来并停止：“这不需要 scouting —— 这是计划，去做吧。”大多数问题都是这样。在清晰的路径上搞仪式纯粹是成本。同样，如果你自己使用了这个技能而非用户输入 /scout，请在开始前确认 —— 一个未经请求的20个问题面试是一个糟糕的惊喜。
阶段
1. 命名目标 —— 在任何其他问题之前
询问完成是什么样子，并将其归纳为一两句话。它可能是一个锁定的决策、一个要移交的规格说明、一个就地完成的迁移、一个端到端工作的功能。不同的目标产生完全不同的路线，所以这一点首先要确定，并且永远不要假设。
目标固定了范围 —— 下面的每个问题都与此目标对比衡量。如果用户还不能命名它，那就是首先要解决的问题，在命名之前什么都不会开始。
2. 展开 —— 广度优先，并抵制回答
扫描整个空间在“这里”和“目标”之间，并收集开放性问题。暂时不要解决任何一个。立即回答第一个问题的冲动是这个阶段旨在克服的：你注意到的第一个问题很少是决定形状的那个，过早回答它意味着非常仔细地规划错误的事情。
走宽，不深入。目标是找出你不知道存在的问题。
事实你去查；决策你去问。 如果某物是可以查证的 —— schema、调用者、真实数据、库的文档、代码今天实际做了什么 —— 去查它，不要浪费一个问题。只有真正的决策才交给用户。
3. 分类到三个桶中
| 桶 | 测试 | 你做什么 |
|---|---|---|
| 锐利 | 你现在就能精确地陈述问题 | 处理它（阶段 4） |
| 模糊 | 你感觉到有问题存在但还无法表述它 | 写一行松散的描述，然后搁置 |
| 范围外 | 它位于目标之后 | 写下来；它不再回来 |
锐利/模糊的测试是你是否能陈述它，而不是你是否能回答它。 一个难以回答或答案未知的问题，如果你能精确地表述它，仍然是锐利的 —— 那些通常是最重要的问题。
范围外使用一个不同的测试 —— 范围，而非锐利度。 某物可以非常锐利但仍然在范围外，因为它位于目标之后。明确排除它并说明原因；只有当目标本身变动时它才会回来，那将是一次全新的 scout。
然后按最能解锁什么的顺序排列锐利问题 —— 哪个答案能消除最多其他问题就先处理哪个。
4. 逐一解决它们
一次问一个问题然后等待。每个问题都给出你推荐的答案 —— 但这是一个推荐，决策权在用户。永远不要替他们做决策，也永远不要批量提问；五个问题的一堵墙令人困惑，只会得到一个敷衍的回复。
每次回答后，更新桶：
- 它是否使模糊变锐利，成为一个真正的、可陈述的问题？提升它。
- 它是否消除了不再重要的其他问题？删除它们。
- 它是否移动了目标？大声说出来，并针对新目标重新检查其他桶 —— 一切之前都是针对旧标线衡量的。
不要为了看起来高产而将模糊预先切成假问题。模糊是一个路标，而不是待办事项清单。
5. 当路线清晰时停止
完成意味着：没有剩余的锐利问题，并且剩下的模糊部分确实可以推迟或属于范围外。以目标、达到目标所做出的决策以及具体的下一步行动来结束。
然后移交 —— 不要构建。 Scout 生成路线，不生成可交付物。进入计划模式（或如果计划由此产生则使用 /validate-plan），然后实现。如果你发现在 scout 内部编写生产代码，你已经过度使用了这个技能。
唯一的例外是一个一次性原型 —— 当一个问题确实无法在纸面上解决时（“这个状态模型感觉对吗”，“这应该是什么样子”），构建一个能回答它的最小粗糙东西，看看它，保留答案并丢弃代码。
跨会话 —— 仅在确实需要时
默认为单会话，无工件。大多数 scout 都合适，为二十分钟前结束的对话编写的文件只是垃圾。
当 —— 且仅当 —— 以下之一为真时，升级到 /handover-save：
- 会话变得足够长，你会失去线索，
- 用户想停下来以后再继续，
- 某个问题被会话外的某事阻塞（其他人的答案、访问权限、先要收集的数据）。
移交文档包含目标和三个桶。使用 /handover-resume 恢复，该命令在继续之前重新同步漂移。跨会话在这里是一个逃生舱，而不是设计初衷。
输出格式
当结果有实质性变化时显示地图 —— 在目标命名后、展开后，以及每当答案重新排列桶时。不是每一步。
## 侦察：<想法，一行>
**目标：** <完成的样子 —— 下面的一切都以此为衡量标准>
**已决定**
- <问题> → <答案>
**未解决 —— 锐利**
1. <精确陈述的问题> ← 正在处理这个
2. <...>
**仍然模糊**
- <松散的概要描述> — 一旦 <X> 解决就会变清晰
**范围外**
- <被排除的内容> — <为什么它在目标之外>
结束语：目标、按顺序的决策以及唯一的下一步行动。
护栏
- 广度优先于深度。 在看到整个空间之前回答第一个问题是这个技能要防止的失败。
- 去查，不要去问。 一个你可以通过 grep 回答的问题浪费了用户的时间和耐心。
- 一次一个问题，然后等待。 每次都推荐一个答案；永远不要替他们决定。
- 锐利 ≠ 可回答性。 模糊测试是“我能陈述它吗”，不是“我能回答它吗”。
- 模糊不是积压。 保持松散。预先将它切成工单会发明工作，而下一个答案可能会删除这些工作。
- 范围外是一个范围判断，不是一个步骤。 它进入自己的桶，永远不会进入决策列表。
- 目标可以移动 —— 当它发生时宣布它。 静默地重新瞄准会使之前所做的所有判断失效。
- 不要构建。 输出决策，而不是交付物。一次性原型是唯一的例外。
- 默认无文件。 只有当工作确实超出会话时才使用
/handover-save。 - 克制之门。 “这里没有模糊 —— 你已经知道怎么做”是一个真实且有价值的结果。永远不要为了证明运行技能的合理性而编造开放性问题。
目标优先框架、广度优先展开、陈述它 vs. 回答它的模糊测试，以及范围 vs. 锐利度的划分改编自 Matt Pocock 的 wayfinder（github.com/mattpocock/skills）。其 issue 跟踪器地图、子工单机制以及每个会话一个工单的规则被有意省略 —— 此集合通过 /handover-save 跨会话持久化。