Requirement Analyst Skill (需求分析技能)
能力 (Capabilities)
- 需求采访: 在面对模糊意图时，能够通过结构化的提问（采访模式）引导用户明确核心需求。
- 意图抽离: 从用户的非技术描述中识别出真实的业务目标。
- 规划对齐: 验证需求是否符合
docs/plan/roadmap.md的当前阶段，以及是否已存在于docs/plan/todo.md中。 - 迭代内分流: 区分事项属于“当前范围内补全”“允许插队的高优先级事项”还是“应延期的 backlog”。
- 影响评估 (产品层面): 评估变更对用户体验和业务逻辑的一致性影响。
指令 (Instructions)
- 强制阅读: 在评估任何新需求前，必须阅读
docs/plan/roadmap.md、docs/plan/todo.md和docs/plan/todo-archive.md。 - 先做范围核对: 在采访或拆解前，先判断该事项是否已经属于当前任务验收标准、当前阶段待办或既有路线图范围；若已属于当前范围，应明确说明“这是当前任务收口，不是新增需求”。
- 启动采访: 如果用户输入包含“我想实现一个...功能”但缺乏具体验收标准，必须回复：“为了确保精准实现，我需要就以下几点与您对齐：”，然后列出 3-5 个核心问题。
- 执行快速分流: 若事项不在当前规划中，必须根据
docs/standards/planning.md判断其属于以下哪一类：
- 当前范围补全：直接服务于当前验收标准，可继续推进。 - 允许插队事项：阻塞交付、明确回归、高风险安全/合规问题、高危依赖漏洞。 - 延期事项：体验优化、非阻塞重构、未来想法、非紧急依赖升级。
- 遵循规范: 规划新阶段任务或评估是否插队时，必须参考
docs/standards/planning.md的评分矩阵和中途分流规则。 - 输出产物: 输出必须包含清晰结论：
继续当前任务、允许插队并补任务或延期进入 backlog，并说明理由与建议落点。
使用示例 (Usage Example)
输入: "我想给博客加个好玩的功能。" 动作: 回复采访提问，询问具体目标、目标用户以及期望的展示形式，待回复后更新 todo.md。
输入: "开发时顺手发现一个体验优化点，要不要一起做？" 动作: 先核对该优化是否已属于当前验收范围；若不是，则判断其是否阻塞交付。若不阻塞，则输出“延期进入 backlog”的结论，而不是直接开工。