需求处理器 (Requirement Processor)

当用户提出新功能/变更需求时，使用此 Skill 标准化处理流程。

核心理念

1. 先理解再动手 — 需求未澄清前不写代码
2. 文档先行 — 所有需求必须有结构化文档
3. 分阶段实施 — 按 P0/P1/P2 优先级拆解
4. 闭环迭代 — 实施后更新文档，复盘经验

Workflow

Step 1: 需求澄清 (Clarify)

收到需求后，首先要确认以下信息。如果用户未明确说明，主动询问：

• 背景与现状： 当前系统或项目是什么状态？
• 核心目标： 用户真正想解决什么问题？
• 边界约束： 有无技术限制（架构、语言、部署方式）？
• 优先级： 哪些功能是必须的（P0），哪些可以后做（P1-P2）？
• 用户画像： 谁会用这个功能？单用户还是多用户？

📌 不需要一次性全问完 — 根据需求复杂度判断，简单需求 1-2 个问题即可。

Step 2: 现状调研 (Survey)

在写文档前，先确认：

• 项目当前已有的功能、数据模型、API
• 当前架构和部署方式（纯前端/全栈/微服务等）
• 有哪些相关代码文件需要阅读
• 用户是否已有相关配置或基础设施（域名、数据库、认证方案等）

阅读关键文件（如路由、组件、数据层、配置文件），记录现有设计决策。

Step 3: 需求文档输出 (Document)

使用以下模板结构输出 requirements.md：

# 项目 — 需求文档

> **日期：** YYYY-MM-DD
> **版本：** v1 草案

## 1. 背景与现状

### 1.1 当前状态
（架构、技术栈、部署方式、已有功能）

### 1.2 痛点
| 问题 | 说明 |
|------|------|

### 1.3 目标
（一句话概括要做什么）

## 2. 整体架构

### 2.1 架构图（文本 + 推荐架构）

### 2.2 关键决策
| 决策点 | 选项 | 推荐 | 理由 |
|--------|------|------|------|

## 3. 功能需求

按模块分类，每个功能有：ID、功能描述、优先级（P0/P1/P2）

## 4. 数据模型

### ER 图（文本格式）

### DDL / 类型定义

## 5. API 设计

| 方法 | 路径 | 说明 | 认证 | 权限 |

## 6. 前端变更概览

- 新增页面/组件清单
- 路由设计
- 状态管理变更
- 关键类型定义

## 7. 安全考虑

（认证方式、密码策略、权限校验、防护措施）

## 8. 实施阶段

### Phase 1 — 基础（P0）
### Phase 2 — 增强（P0-P1）
### Phase 3 — 优化（P1-P2）

## 9. 部署方案

（Docker 编排、环境变量、Nginx 配置等）

## 10. 未解决问题 / 待决策事项

Step 4: 用户确认 (Validate)

将需求文档发送给用户并提问：

• 整体方向是否符合预期？
• 优先级排序是否合理？
• 有无遗漏或误解的功能？
• 分阶段方案能否接受？

记录用户反馈，更新文档。

Step 5: 实施规划 (Plan)

根据确认后的需求文档：

• 以实际文件为单位制定实施步骤
• 评估工作量（文件数、估算行数、预期工时）
• 确定当前会话的实施范围（全部或仅 Phase 1）
• 开始编码实现

Step 6: 复盘迭代 (Iterate)

实施完成后：

• 记录实施过程中的经验教训
• 更新需求文档（标记已实现的功能、更新架构信息）
• 向用户汇报完成情况和剩余待办
• 更新此 SKILL 的 references/ 目录中的经验笔记
• 向用户提出改进此 Skill 的建议

输出物规范

1. 需求文档保存为 项目名-requirements.md（如 worktime-auth-requirements.md）
2. 文档附在回复中供用户查看
3. 实施后文档保留在项目目录，作为后续开发参考

参考资料（可选扩展）

• references/requirement-templates/ — 各类型需求的文档模板
• references/experience-notes/ — 每次实施后的经验总结
• references/decision-log/ — 架构决策记录（ADR 格式）

⚖️ 权限声明

此技能为纯文档/流程技能，不修改系统配置或执行外部命令。