prd-crafter-pro

name: prd-crafter-pro description: 多角色协作 PRD 专家 (v5.0)。支持递归任务拆解、多角色视角、批判性审查和技术评审门禁。生成用户版和研发版两套 PRD。

PRD Crafter Pro (The Orchestrator)

本技能通过多角色协作生成高质量 PRD，支持递归任务拆解和技术评审门禁。

0. 核心参数

1. 角色定义 (Role Definitions)

🎨 产品专家 (Product Expert)

职责: 从用户需求出发，定义产品功能和体验。 关注点:

• 用户痛点是什么？
• 核心功能有哪些？
• MVP 范围如何界定？
• 用户体验如何保证？

输出: 功能列表、用户故事、优先级排序

📚 行业专家 (Domain Expert)

职责: 提供特定行业的专业知识。 触发条件: 根据需求自动识别行业（教育、金融、医疗、电商...） 关注点:

• 行业最佳实践是什么？
• 有哪些行业特殊要求？
• 竞品是如何解决的？
• 有哪些潜在的合规风险？

输出: 行业洞察、最佳实践建议、风险提示

🔍 批判者 (Critic)

职责: 用批判性思维审查 PRD，找出漏洞和不足。 关注点:

• 是否有逻辑矛盾？
• 是否有遗漏的边界情况？
• 用户体验是否合理？
• 技术实现是否可行？

输出: 问题清单、改进建议

👨‍💻 技术总监 (Tech Lead)

职责: 从技术角度评估 PRD 的可行性。 关注点:

• 现有架构能否支持？
• 技术风险有哪些？
• 工作量预估多少？
• 是否需要技术预研？

输出: 可行性评估、风险清单、工作量预估

2. 工作流程 (Workflow)

Phase 1: 需求澄清 (Requirement Clarification)

与 prd-crafter-lite 相同的门禁机制

1. 检查需求是否模糊
2. 如有歧义，列出问题清单强制反问
3. 用户回答后才继续

Phase 2: 多角色规划 (Multi-Role Planning)

Step 2.1: 产品专家视角

## 🎨 产品专家分析

### 用户痛点
- [Pain Point 1]
- [Pain Point 2]

### 核心功能
1. [Feature 1] - 优先级: P0
2. [Feature 2] - 优先级: P1
...

### 用户故事
- 作为 [角色]，我希望 [功能]，以便 [价值]

Step 2.2: 行业专家视角

## 📚 行业专家分析

### 识别行业: [教育/金融/医疗/...]

### 行业最佳实践
- [Practice 1]
- [Practice 2]

### 竞品参考
- [Competitor 1]: 优点/缺点
- [Competitor 2]: 优点/缺点

### 风险提示
- ⚠️ [Risk 1]

Step 2.3: 批判者视角

## 🔍 批判性审查

### 发现的问题
1. ❓ [Issue 1] - 建议: [Solution]
2. ❓ [Issue 2] - 建议: [Solution]

### 遗漏的边界情况
- [Edge Case 1]
- [Edge Case 2]

### 改进建议
- [Improvement 1]

Phase 3: 生成用户版 PRD (User-Facing PRD)

概要性质，面向用户确认，只呈现核心关注点

# PRD: [项目名称] (用户版)

> 版本: 1.0 | 日期: YYYY-MM-DD | 状态: 待确认

## 1. 项目概述
[一段话描述项目目标和价值]

## 2. 核心功能 (5-10条)
| 功能 | 描述 | 优先级 |
|-----|------|-------|
| [F1] | [简述] | P0 |
| [F2] | [简述] | P1 |
...

## 3. 关键设计决策
| 决策点 | 选择 | 理由 |
|-------|------|-----|
| [D1] | [Option] | [Why] |
...

## 4. 不做什么 (Out of Scope)
- [Excluded 1]
- [Excluded 2]

## 5. 风险与挑战
- ⚠️ [Risk 1]
- ⚠️ [Risk 2]

---
**请确认以上内容，说 "Go" 进入技术评审**

Phase 4: 用户确认门禁 (User Confirmation Gate)

• Yes/Go/OK: 进入技术评审
• 修改 [内容]: 返回 Phase 2 调整
• 取消: 终止流程

Phase 5: 技术总监评审 (Tech Review)

## 👨‍💻 技术评审报告

### 可行性评估
| 维度 | 评分 | 说明 |
|-----|------|-----|
| 架构兼容性 | ✅/⚠️/❌ | [说明] |
| 技术复杂度 | ✅/⚠️/❌ | [说明] |
| 工作量 | [X人天] | [说明] |

### 技术风险
1. 🔴 [High Risk] - 缓解措施: [Mitigation]
2. 🟡 [Medium Risk] - 缓解措施: [Mitigation]

### 技术预研需求
- [ ] [Research Item 1]
- [ ] [Research Item 2]

### 评审结论
- ✅ **通过**: 可以进入开发
- ⚠️ **有条件通过**: 需要先解决 [Issue]
- ❌ **驳回**: 原因 [Reason]，建议 [Suggestion]

评审结果处理:

• ✅ 通过 → 进入 Phase 6
• ⚠️/❌ 驳回 → 返回 Phase 2 (计数器 +1，最多 3 次)
• 3 次驳回 → 标记为 BLOCKED，人工介入

Phase 6: 生成研发版 PRD (Development PRD)

详细技术规格，包含第一层任务拆解 (10个大任务)

# PRD: [项目名称] (研发版)

> 版本: 1.0 | 日期: YYYY-MM-DD | 状态: 已确认

## 1. 技术背景
[现有架构说明、技术栈、依赖关系]

## 2. 任务拆解 (第1层 - 10个大任务)

| ID | 任务 | 描述 | 预估 | 依赖 |
|----|------|------|-----|------|
| T-001 | [Task 1] | [Description] | Xh | - |
| T-002 | [Task 2] | [Description] | Xh | T-001 |
...
| T-010 | [Task 10] | [Description] | Xh | T-009 |

## 3. 风险缓解计划
[技术风险的具体缓解措施]

## 4. 测试策略
[每个任务的验收标准]

## 5. 里程碑
| Milestone | 包含任务 | 预计完成 |
|-----------|---------|---------|
| M1 | T-001 ~ T-003 | Day 1 |
| M2 | T-004 ~ T-007 | Day 2 |
| M3 | T-008 ~ T-010 | Day 3 |

3. 递归任务拆解 (Recursive Decomposition)

在执行阶段，每个任务在开始前会进行即时拆解：

第 1 层: 大任务 (已在研发版 PRD 中定义)

T-001: 实现用户登录模块

第 2 层: 子任务 (执行 T-001 前拆解)

T-001 拆解:
├── T-001.1: 创建登录页面 UI
├── T-001.2: 实现表单验证逻辑
├── T-001.3: 对接登录 API
├── T-001.4: 实现 Token 存储
└── T-001.5: 编写单元测试

第 3 层: 原子任务 (执行 T-001.1 前拆解)

T-001.1 拆解:
├── T-001.1.1: 创建 LoginScreen widget
├── T-001.1.2: 添加用户名输入框
├── T-001.1.3: 添加密码输入框
├── T-001.1.4: 添加登录按钮
└── T-001.1.5: 应用主题样式

拆解判断逻辑

IF 任务可以在 1 小时内完成 AND 不需要中间测试点:
    → 直接执行 (原子任务)
ELSE:
    → 继续拆解

4. 输出文件

5. 与其他模块的集成

• feature-flow: 研发版 PRD 确认后自动触发
• evolution-engine: 任务完成后自动学习
• context-manager: 全程维护状态和进度