requirements-analysis

Files (1)

• SKILL.md

SKILL.md (first lines)

# 需求分析元技能

先把原始诉求整理为可以开发、可以验收的需求。读取用户材料与相关项目事实，识别业务目标、遗漏、矛盾和不合理假设；代码能查明的先查，不把问题全部交回用户。区分用户已确认、源码事实、模型推断和待澄清事项。发现矛盾时解释影响并给出可选方案，不自行替用户决定范围。

新任务以 `status.artifact_requirements` 和 `status.requirements` 为准执行以下闭环：

1. 对影响本期范围、业务规则或验收结果的问题，用 `clarify_requirement` 的 `clarification_questions` 每批询问 1–3 个关键问题。宿主保存真实用户答复；不能把“建议本期不做”写成“用户确认不做”。用户明确接受的接口待联调等边界可以保留，并写清责任和限制。
   需要交给产品／技术负责人填写的材料时，使用 `write_requirement_material` 在任务专属目录生成 HTML、Markdown、JSON 等文本材料。挂载 Skill 可通过 `material_template` 引用本节点已实际加载的 Skill HTML 资产，只替换指定 JSON 数据区，无需运行脚本。材料路径、版本和指纹由宿主登记；材料生成、页面填完或回填 JSON 都不代表需求已批准。收集并核对实际反馈后再完善需求总结。已有人工修改保留，改用新版本文件名；不再作为本期依据的旧材料可 `retire_requirement_material` 停用，原文件保留。
2. 使用 `record artifact=requirement` 写目标、本期范围、非目标、流程与规则、异常边界、验收条件、外部依赖及已接受假设；字段严格按快照。验收条件应描述可观察的输入和结果，不能仅写“实现完成”“编译通过”。明确小改使用精简总结；含糊需求不能为了省流程归为低复杂度。
3. 调用 `prepare_requirement` 生成可审阅的需求总结，默认 `.dsh/tasks/<task_id>/requirement.md`，项目可指定普通 Markdown 路径。向用户展示文档和本期范围；已有清晰规格可引用整理，不重复访谈，不臆测缺失信息。
4. 调用 `confirm_requirement expected_hash=<本版返回值>`，由宿主展示全文并收集用户确认。用户要求修改就先修订或澄清，再生成新版本；取消或无答复保持当前阶段，不原样反复申请。确认前不实施、不执行项目命令；自动工具权限不代表需求确认。
5. 仅当前版本已确认才交接到下一阶段。之后改变范围、业务规则或验收条件，先 `revise revision_kind=requirement` 返回需求所属阶段，修订并重新确认；不要沿用旧版同意。

任务返回 `execution_blocker` 时按提示新建任务，不给旧台账补造确认，也不迁移旧需求回执；历史记录保持只读。

交接给下一元技能：用户确认的需求文档版本、明确的验收条件、受影响的业务路径以及已接受的待联调约束。需求文档和任务 JSON 分别负责人工审阅与流程状态；不要把实现步骤伪装成需求，也不保证已穷尽所有潜在业务问题。

项目已有业务能力图谱时，只读取与本需求相关的能力、入口和业务规则，并核对其源码证据。将“代码已确认”“根据代码推导”“待业务确认”分别标明；不能把目录名或接口名直接当作产品能力。需要定位调用链时，可用项目已有的代码索引辅助查找，并以源码核对；没有索引就搜索和阅读源码。已有经确认的需求规格可作为输入，记录来源路径；不为普通需求自动安装外部工具或建立另一套规格台账。

From godv61/dsh-task-engine, MIT.

More from godv61/dsh-task-engine