利益相关者走查
没人写下来的需求，会在一个并非作者的人尝试去做某件事时浮现出来：安装服务的运维人员、搜索数据的研究员、搭建仓库的同事、凌晨三点查看日志的维护者。走查就是在纸面上模拟这个过程，使用一个命名的人物角色和一个具体的流程，在变更被规定之前进行。它的输出不是一份设计文档，而是留给负责人的问题、存在的缺口以及可供规范和测试使用的验收示例。
借鉴自两项来自他人的习惯，在此致谢：一是采用“两顶帽子”的访谈方式，即产品帽子（关注用户价值、目标和成功）和开发者帽子（关注可行性、安全性和边界情况），如同 jeffallan 以 MIT 协议发布的 Feature Forge 技能所做的那样；二是像 melodic-software 的需求启发技能那样，将模拟利益相关者“说过”的内容标记为比真实利益相关者所说内容的置信度更低。
输入
在走查之前，先与用户确定以下内容，并将其写在输出文档的顶部：
- 人物角色。 他们是谁、他们想从该流程中得到什么、他们知道什么和不知道什么、他们的机器上有什么、以及他们绝不会阅读什么。更倾向于使用机构中某个真实人物的角色而非通用原型；在可以询问真实人物时，更倾向于使用他们的真实回答而非你的猜测。
- 流程。 他们试图完成的事情，从第一步开始，直到他们认为完成的那一刻。示例：在服务器上安装爬虫；在索引中查找上周的测量结果；将新的文件格式添加为外部集合；创建一个新的仓库用于使用代理进行开发；在夜间运行后读取爬虫日志。
- 现有资料。 人物角色会遇到的文档、代码、命令和页面，这样走查才能检验现实，而非一个计划。以人物角色的方式阅读它们：按照他们会遇到的顺序，跳过他们可能会跳过的部分。
走查
逐步执行流程，每一小步都代入人物角色的视角。对于每一步，记录以下内容：
- 他们做什么，具体而言：输入的命令、打开的页面、阅读的文件、询问的人。
- 当时他们需要知道什么，以及现有资料是否告诉他们了。
- 这里在实践中会出什么问题：静默失败、误导性信息、没有默认选项的选择、需要他们没有权限的步骤、没有反馈的等待。
- 如果可能的话，他们会向负责人提的问题，用他们自己的话。
然后，在整个走查过程中切换两次帽子：戴上产品帽子，询问人物角色想要什么、流程是否交付了它、对他们来说“完成”是什么样子、他们会抱怨什么；戴上开发者帽子，询问哪些是不可行的、不安全的、规模上会变慢的，或者在步骤顺序上脆弱的。
当走查到达文档未覆盖的点时，不要编造答案：将其记录为一个问题，如果你必须假设某些事情才能继续，请说明这一点，并将剩余的走查标记为基于该假设。
当一个步骤揭示出更普遍的问题（五个为什么）时，提升一个抽象层级：一条令人困惑的消息是一个步骤；而“工具在做事之前从不说明它将做什么”是一个需求。
输出
如果项目有设计说明文档，则将走查记录写入该文档（例如 design/walkthroughs/<persona>-<process>.md），否则写入 docs/walkthroughs/，并在回复中给出简短的摘要。模板：
# 走查：<人物角色> <进行的流程>
人物角色：<身份、目标、知识、环境>。置信度：<模拟 | 基于与…的访谈>。
现有资料：<阅读的文档、代码、命令>。
## 步骤
1. **<步骤>。** 做：<…>。需要知道：<…>。出问题：<…>。会问：“<…>”。
## 产品帽子
<他们想要什么、对他们来说“完成”是什么、他们会抱怨什么>
## 开发者帽子
<不可行、不安全、慢、脆弱>
## 留给负责人的问题
- <问题，用人物角色的话，以及它来自的步骤>
## 缺口
- <不存在的需求、行为或文档；需要它的步骤>
## 验收示例
- 当 <具体情景>，则 <可观察的结果>。 （可用于规范场景或测试）
规则
- 说明哪些部分是模拟的。代理进行的走查能发现一个细心同事会发现的问题；它不知道真实的人物角色看重什么。当存在真实的利益相关者时，将问题交给他们，并更新置信度行。
- 保持在角色中。如果你知道系统如何工作，人物角色不知道；写下他们看到的，而不是你知道的。
- 具体胜于笼统。“运维人员运行
modama-crawler crawl并在两个小时内看到任何输出”是一个发现；“可以改进反馈”则不是。 - 问题、缺口和示例是可交付的成果。不要在此处设计修复方案；由负责人决定哪些成为需求。
- 考虑一个全新的视角：对于一个已存在的工具，给一个子代理仅提供人物角色、流程和面向用户的文档，指示其运行该工具，它能发现作者无法忘却的东西。这就是本插件中的
hallway-test技能；当走查变成“让我们试试看”时，使用它。