req-scout — 需求侦察兵

需求协议的开源实现：加载 AGENTS.md 后，AI 变身为「需求 Scout」——通过对话一点一点帮您把模糊想法挖成可落地、可验证、可直接开工的需求文档。

产出接口对准 Anchorlaw（编程执行协议）的 stage-0 输入契约——需求确认后直接喂给 Anchorlaw 实施，零重新诠释。

这是什么

三协议闭环中的「需求协议」一环：

需求协议（本项目）→ Anchorlaw（编程执行）→ RE 框架（逆向探索）
   模糊意图 → 已确认需求       需求 → 代码+验证      目标程序 → 逆向结论

• Anchorlaw 解决「拿到确定需求后怎么实施并验证」
• req-scout 解决「模糊想法怎么变成确定需求」——Anchorlaw 的上游

为什么需要它

1. 需求发掘是探索型工作，不是构建型工作——探索人类的意图要靠对话，不能用判据驱动的流水线硬套（Anchorlaw v0.10 结构反转的教训）。
2. AI 角色的注意力机制：发散（倾听/共情/提问）和收敛（判定/挑剔/矛盾检测）是两种互相干扰的认知模式。单角色既发散又收敛，必然互相污染——所以本协议用 Scout（发散）+ Judge（收敛）双角色闭环。
3. 模糊是需求的逃逸通道：「差不多」「到时候再说」到实现期就变成甩锅空间——必须当场锁定。

怎么用

1. 安装（可选，DSH 用户推荐）

本仓库原生支持 DSH 的 skill 发现机制（.dsh/skills/ 项目级 / ~/.dsh/skills/ 用户级），提供安装脚本（参照 Anchorlaw 的双模式设计，幂等可重跑）：

# Host 级（全局）：3 个 skill 装到 ~/.dsh/skills/，任何项目的会话都能召唤 Scout
scripts\install.ps1

# Project 级（按项目）：skill 装到 <dir>/.dsh/skills/，只在该项目会话生效
scripts\install.ps1 -Project <目标项目目录>

# 自检：核对已装副本与源文件一致（SHA256）
scripts\selfcheck.ps1                       # 查 host 级
scripts\selfcheck.ps1 -Project <目录>       # 查项目级

装完后 skill 在 DSH 会话中可被直接召唤；Scout 角色文件（AGENTS.md）与全部模板随装落在 kit 目录（~/.dsh/req-scout/ 或 <project>/.dsh/req-scout/）。项目已有自己的 AGENTS.md 时不会被覆盖。

2. 手动加载（不装也能用）

把本仓库（至少 AGENTS.md + skills/ + templates/）交给任何支持 AGENTS.md 的 AI（Claude / OpenClaw / 其他 agent），AI 启动后即扮演需求 Scout。

3. 选入口

对话开始按领域选入口（skills/entries/）：

• swe-flow：常规软件开发——六层提问（意图→功能→交互→数据→约束→边界），交互层做到线框/交互流程级
• game-flow：游戏软件开发——八步流水线：构想 → 系统分解 → R1 玩法构思（纯设计不碰实现）→ 整合筛选 → R2 详细设计 → 交互设计（操作输入+游戏 UI）→ MVP 验证 → 技术交接。MVP 验证分层：决策/数值/经济/节奏类声称用文字冒险+数值展示跑团验证；手感/实时操作类无法文字验证，显式写边界（@anchor.idk 形态）推迟到灰盒原型——不硬凑验证，不假装验过。

3. 对话挖需求

Scout 按入口流程分层推进。每轮对话后：

1. Scout 整理草稿（scout-notes.md：客户原话 S: / 推测 I: / 未决问题 ?）
2. 召唤 Judge（加载 skills/judge-review/SKILL.md 的隔离 subagent）审核
3. Judge 返回五段式技术报告：可实现 / 不可实现 / 模糊点 / 矛盾 / 缺失
4. Scout 把报告翻译成您能懂的问题，继续下一轮对话

循环直到：Judge 说「模糊点清零、技术层可落地」+ 您逐条确认 → 产出需求文档。

4. 产出并交接

按 templates/requirements-doc.md 输出已确认需求文档 + 技术约束规范，交给 Anchorlaw 实施。您的确认 = Anchorlaw 的实施授权。

项目结构

req-scout/
├── AGENTS.md                    ← Scout 角色定义（灵魂文件：发散者铁律/工作流程/入口选择）
├── docs/
│   └── requirements-protocol.md ← 需求协议全文（判据体系/产出契约/Anchorlaw 映射）
├── skills/
│   ├── judge-review/SKILL.md    ← Judge 角色定义（收敛者铁律/五段式报告）
│   └── entries/
│       ├── swe-flow/SKILL.md    ← 入口1：常规软件开发（六层提问）
│       └── game-flow/SKILL.md   ← 入口2：游戏开发（八步流水线 + 内置游戏设计知识库）
├── templates/
│   ├── scout-notes.md           ← Scout 草稿格式（交 Judge 的输入）
│   ├── judge-report.md          ← Judge 五段式技术报告格式
│   ├── requirements-doc.md      ← 最终需求文档（Anchorlaw stage-0 输入契约）
│   ├── game-systems-map.md      ← 游戏系统分解图（game-flow 第 2 步）
│   ├── gameplay-design-r1.md    ← R1 玩法构思卡（game-flow 第 3 步）
│   ├── gameplay-design-r2.md    ← R2 玩法详细设计（game-flow 第 5 步）
│   ├── game-ui-interaction.md   ← 游戏交互设计（game-flow 第 6 步，操作输入+UI）
│   ├── ui-interaction.md        ← 软件交互设计卡（swe-flow 第 3 层）
│   └── mvp-validation.md        ← MVP 验证记录（game-flow 第 7 步，方向 A 分层）
├── scripts/
│   ├── install.ps1              ← DSH 安装接口（host 级 / -Project 级双模式，幂等）
│   └── selfcheck.ps1            ← 安装自检（SHA256 比对源文件）
├── examples/                    ← 示例（进行中）
├── LICENSE
└── README.md

与 Anchorlaw 的接口细节

req-scout 产出	Anchorlaw 消费
声称清单（条件+行为）	Judge 推导验收判据（§15.4 criteria-first）
验证方案草案	将来绑定 @anchor.test（§5.1）
边界清单（what+source）	@anchor.idk 认知边界锚（§5.2）
source（需求来源）	锚的溯源起点（§5.5）
客户确认	host handover = 实施授权（§16.1）

对接原则：Anchorlaw 的 Judge 拿到需求文档时，推导验收判据是机械翻译，不是重新诠释。

方法论根基

本协议在工程设计之上，融合了唯物实践论的认识论判据：

• 第一律（实践锚定剃刀）：声称必可检验——不可翻译成验证断言的声称不许进清单
• 模糊空间 = 逃逸通道：逐条识别、逐条锁定
• Δ 自指一致性：术语操作化 + 需求间矛盾检测
• 诚实性纪律：半操作化标注 / 全称附范围 / 假设≠需求 / 接口标注
• 负反馈认识论：需求确认 = 「暂无未解决反例」，不是「需求完美」

许可证

MIT