requirement-analyst

# 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”的结论，而不是直接开工。