neo-clarification

需求澄清规范

应用反转与生成模式。严格遵循此流程，将用户原始、混乱的抱怨和截图转化为清晰、结构化的系统规范。

---

1. 感知阶段

1. 信息提取：

   • 仔细阅读用户的文本，并检查附带的截图或日志。
   • 过滤情绪化内容、挫折感和责怪。
   • 将客观事实（当前发生或可见的情况）与用户期望（用户想要完成的目标）分开。

2. 识别系统边界：

   • 确定反馈所涉及的范围、领域和潜在技术层（例如，前端渲染、网络 API、数据库状态、权限组）。

---

2. 推理阶段

1. 加载分析框架：

   • 开始推理前，务必阅读外部分析指南： 5w1h-framework.md

2. 重建上下文（5W1H）：

   • 将提取出的事实对应到 5W1H 框架（Who、Where、When、What、Why、How）。
   • 针对 UI 异常或系统行为的根本原因，提出合乎逻辑的假设。

3. 识别信息缺口：

   • 找出关键信息缺失之处（例如，浏览器环境、具体操作步骤、参数、错误日志）。
   • 准备一份要询问用户的澄清问题清单。

---

3. 执行阶段

严格使用**繁体中文（台湾）**生成结构化的「需求转译与澄清报告」。请遵循以下步骤：

1. 加载输出模板：

   • 阅读以下文件中的标准 Markdown 结构： clarification-template.md

2. 编写报告：

   • 使用繁体中文填写模板。
   • 上下文还原：简洁呈现客观事实，不使用带有情绪色彩的形容词。
   • 用户故事：使用严格格式：「身为……我想要……以便于……」
   • 系统需求与假设：为开发团队指出关键的渲染、API 和验证检查点。
   • 待确认问题：列出 2 至 10 个礼貌、明确且有助于解决问题的澄清问题。

3. 自我验证：

   • 主动使用非交互式 Python 脚本验证报告：

     uv run skills/neo-clarification/scripts/validate-requirements.py -i <path_to_saved_report>
     

     （或者，在最终输出前自行确认所有章节均已包含，且问题数量在 2 至 10 个之间。）

---

4. 沟通指南

• 保持共情与中立：承认用户遇到困难，但在正式报告中绝不认同系统「损坏」或「一团糟」。应使用中立、客观的描述。
• 严格禁止猜测：不要臆造用户未提及的功能。如有疑问，请提出澄清问题。