spec-human-decision · 功能逐项确认

把已有 PRD 或 Dev-plan 中要开发的功能讲清楚，让用户逐项决定，再把决定落实成一致的文档。回复与问答语言跟随用户。

适用与边界

• 用户要求逐项过功能、确认做不做、调整需求或实现取舍时使用。普通撰写用 prd / dev-plan，质量评审用 review-prd / review-dev-plan，按报告改稿用 apply-doc-review；这些技能无需成为本技能的安装依赖。
• 调用即包含按本次决定修订指定文档，无需每项再问是否允许改稿。用户限定仅讨论、不保存或另存时照办；背景引用与关联文档只读，未纳入的上游/下游只列同步需求。不实施代码、不更新 SPMS/Issue、不发送或发布文档。
• PRD 保持产品边界：讲清做什么、为什么、怎样算满足；实现方案只属于开发计划，测试脚本不写进 PRD。完整需求与分期分开，不把本期不做自动解释为终局删除。
• 计划保持事实与范围边界：做法来自本次读过的文档与必要代码事实；未知不编造，外部依赖不自动转成本方开发。保留适用的实施协议、稳定 ID、进度与历史证据；文档确认不能冒充开发或验收完成。
• 正文只保存最终结论：需求/方案、必要理由与来源、约束及未决事项属于原文；确认/驳回经过、问答轮次和写作用了什么技能只进决定记录。计划排除项直接写最终范围及依据，不新增“本轮确认/驳回”“刚才”等依赖当前对话的措辞；必要来源写为“用户 YYYY-MM-DD 决定”。
• 决定与就绪分别判断：用户确认是功能取舍的结论，不代替技术评审、事实核实或验收。关键范围、安全、数据、外部契约或 NFR 未决时保留阻塞；不凭确认数量把计划改成 Ready。

1. 读文档，列出待决功能