requirement-analyst

name	requirement-analyst
description	专注于需求分析、澄清与意图抽离。
metadata	{"internal":true}

Requirement Analyst Skill (需求分析技能)

能力 (Capabilities)

• 需求采访: 在面对模糊意图时，能够通过结构化的提问（采访模式）引导用户明确核心需求。
• 意图抽离: 从用户的非技术描述中识别出真实的业务目标。
• 规划对齐: 验证需求是否符合 docs/plan/roadmap.md 的当前阶段，以及是否已存在于 docs/plan/todo.md 中。
• 迭代内分流: 区分事项属于“当前范围内补全”“允许插队的高优先级事项”还是“应延期的 backlog”。
• 影响评估 (产品层面): 评估变更对用户体验和业务逻辑的一致性影响。

指令 (Instructions)

1. 强制阅读: 在评估任何新需求前，必须阅读 docs/plan/roadmap.md、docs/plan/todo.md 和 docs/plan/todo-archive.md。
2. 先做范围核对: 在采访或拆解前，先判断该事项是否已经属于当前任务验收标准、当前阶段待办或既有路线图范围；若已属于当前范围，应明确说明“这是当前任务收口，不是新增需求”。
3. 启动采访: 如果用户输入包含“我想实现一个...功能”但缺乏具体验收标准，必须回复：“为了确保精准实现，我需要就以下几点与您对齐：”，然后列出 3-5 个核心问题。
4. 执行快速分流: 若事项不在当前规划中，必须根据 docs/standards/planning.md 判断其属于以下哪一类：
   • 当前范围补全：直接服务于当前验收标准，可继续推进。
   • 允许插队事项：阻塞交付、明确回归、高风险安全/合规问题、高危依赖漏洞。
   • 延期事项：体验优化、非阻塞重构、未来想法、非紧急依赖升级。
5. 遵循规范: 规划新阶段任务或评估是否插队时，必须参考 docs/standards/planning.md 的评分矩阵和中途分流规则。
6. 输出产物: 输出必须包含清晰结论：继续当前任务、允许插队并补任务 或 延期进入 backlog，并说明理由与建议落点。

使用示例 (Usage Example)

输入: "我想给博客加个好玩的功能。" 动作: 回复采访提问，询问具体目标、目标用户以及期望的展示形式，待回复后更新 todo.md。

输入: "开发时顺手发现一个体验优化点，要不要一起做？" 动作: 先核对该优化是否已属于当前验收范围；若不是，则判断其是否阻塞交付。若不阻塞，则输出“延期进入 backlog”的结论，而不是直接开工。