kol-insight/.claude/skills/wd/SKILL.md

name	description
wd	从上游文档生成 DevelopmentPlan.md，包含技术方案和开发排期。

Write DevelopmentPlan

文档定位：DevelopmentPlan 是「执行蓝图」文档，偏技术语言和时间约束。定义技术架构、实现方案、开发阶段、里程碑，是开发团队的行动指南。

当用户调用 /wd 时，执行以下步骤：

1. 读取源文档

读取以下文件：

1. doc/RequirementsDoc.md - 必须存在
2. doc/PRD.md - 必须存在
3. doc/FeatureSummary.md - 必须存在

如果文件不存在，提示用户：

缺少上游文档，请先确保 RequirementsDoc.md、PRD.md 和 FeatureSummary.md 存在。

如果已存在 doc/DevelopmentPlan.md，同时读取作为参考（保持风格一致）。

2. 分析开发需求

从上游文档中提取以下信息：

2.1 功能需求

• 从 FeatureSummary 获取功能清单和契约
• 从 PRD 获取功能详情和验收标准

2.2 技术约束

• 从 PRD 获取技术约束
• 从 RequirementsDoc 获取技术决策

2.3 优先级排序

• 按 P0 → P1 → P2 顺序规划开发
• 考虑功能依赖关系

3. 生成 DevelopmentPlan

按以下结构生成文档：

# {产品名称} - 开发计划

## 文档信息

| 项目 | 内容 |
|------|------|
| 版本 | v1.0 |
| 创建日期 | {YYYY-MM-DD} |
| 来源文档 | FeatureSummary.md |

## 1. 项目概述

### 1.1 项目目标

{从 PRD 提取的项目目标}

### 1.2 技术栈

| 层级 | 技术选型 | 版本 | 说明 |
|------|----------|------|------|
| 前端 | {技术} | {版本} | {说明} |
| 后端 | {技术} | {版本} | {说明} |
| 数据库 | {技术} | {版本} | {说明} |
| 基础设施 | {技术} | {版本} | {说明} |

### 1.3 开发原则

{开发规范和原则}

## 2. 技术架构

### 2.1 系统架构图

**【必须】使用架构图展示系统整体结构：**

┌─────────────────────────────────────────────────────────┐ │ 客户端层 │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ Web App │ │ Mobile App │ │ │ └──────┬───────┘ └──────┬───────┘ │ └─────────┼─────────────────┼─────────────────────────────┘ │ │ ▼ ▼ ┌─────────────────────────────────────────────────────────┐ │ API 网关层 │ │ ┌──────────────────────────────────────────────────┐ │ │ │ API Gateway / Load Balancer │ │ │ └──────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────┐ │ 服务层 │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ 服务 A │ │ 服务 B │ │ 服务 C │ │ │ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │ └────────┼───────────────┼───────────────┼────────────────┘ │ │ │ ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────┐ │ 数据层 │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ 数据库 │ │ 缓存 │ │ 消息队列 │ │ │ └────────────┘ └────────────┘ └────────────┘ │ └─────────────────────────────────────────────────────────┘

### 2.2 模块依赖图

**【必须】使用依赖图展示模块间关系：**

┌──────────────┐ │ 模块 A │ │ (核心模块) │ └──────┬───────┘ │ ┌───┴───┐ ▼ ▼ ┌──────┐ ┌──────┐ │模块B │ │模块C │ └──┬───┘ └──┬───┘ │ │ ▼ ▼ ┌──────────────┐ │ 模块 D │ │ (基础设施) │ └──────────────┘

### 2.3 数据流图

**【必须】使用数据流图展示关键数据流转：**

用户请求 ──▶ API Gateway ──▶ 服务A ──▶ 数据库 │ ▼ 缓存层 │ ▼ 服务B ──▶ 外部API

## 3. 开发阶段

### 3.1 阶段时间线

**【必须】使用时间线展示开发阶段：**

 Phase 1           Phase 2           Phase 3
    │                 │                 │

{起止日期} {起止日期} {起止日期} │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ 基础 │ ────▶ │ 核心 │ ────▶ │ 优化 │ │ 架构 │ │ 功能 │ │ 扩展 │ └─────────┘ └─────────┘ └─────────┘

交付物: 交付物: 交付物: • {交付1} • {交付1} • {交付1} • {交付2} • {交付2} • {交付2}

### 3.2 Phase 1: {阶段名称}

**目标**: {阶段目标}

**时间**: {起止日期}

| 任务ID | 任务 | 描述 | 依赖 | 优先级 | 关联功能 |
|--------|------|------|------|--------|----------|
| T-001 | {任务名} | {描述} | - | P0 | F-001 |
| T-002 | {任务名} | {描述} | T-001 | P0 | F-002 |

**阶段依赖图：**

T-001 ──▶ T-002 ──▶ T-003 │ └──▶ T-004

{重复以上结构覆盖所有阶段}

## 4. 技术方案

### 4.1 {模块名称}

**功能**: {功能描述}

**技术选型**:

| 组件 | 技术 | 选型理由 |
|------|------|----------|
| {组件} | {技术} | {理由} |

**架构设计**:

┌─────────────────────────────────────┐ │ {模块名称} │ ├─────────────────────────────────────┤ │ ┌─────────┐ ┌─────────┐ │ │ │ 组件A │ ───▶ │ 组件B │ │ │ └─────────┘ └─────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌─────────────────────────┐ │ │ │ 数据层 │ │ │ └─────────────────────────┘ │ └─────────────────────────────────────┘

**接口设计**:

| 接口 | 方法 | 路径 | 说明 |
|------|------|------|------|
| {接口名} | GET/POST | /api/xxx | {说明} |

**实现要点**:

- {技术要点1}
- {技术要点2}

{重复以上结构覆盖所有模块}

## 5. 风险管理

| 风险 | 可能性 | 影响 | 应对措施 | 负责人 |
|------|--------|------|----------|--------|
| {风险} | 高/中/低 | 高/中/低 | {措施} | {负责人} |

## 6. 里程碑

**【必须】使用里程碑图展示关键节点：**

M1 M2 M3 M4 │ │ │ │ ▼ ▼ ▼ ▼ ◆───────────────◆───────────────◆───────────────◆ │ │ │ │ {日期} {日期} {日期} {日期} {里程碑名} {里程碑名} {里程碑名} {里程碑名}

| 里程碑 | 日期 | 目标 | 交付物 | 验收标准 |
|--------|------|------|--------|----------|
| M1 | {日期} | {目标} | {交付物} | {标准} |

## 7. 资源需求

| 角色 | 人数 | 职责 | 参与阶段 |
|------|------|------|----------|
| {角色} | {人数} | {职责} | Phase 1-2 |

4. 保存文档

将生成的 DevelopmentPlan 保存到 doc/DevelopmentPlan.md。

如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。

5. 输出摘要

向用户展示生成摘要：

• DevelopmentPlan 文件路径
• 开发阶段数量
• 技术方案模块数量
• 建议的下一步操作（运行 /rd 评审）

---

可视化输出要求

DevelopmentPlan 作为「执行蓝图」文档，需要清晰传达技术方案和时间安排，必须包含：

章节	可视化形式	必要性
2.1 系统架构图	架构图（ASCII）	必须
2.2 模块依赖图	依赖图（ASCII）	必须
2.3 数据流图	数据流图（ASCII）	必须
3.1 阶段时间线	时间线（ASCII）	必须
3.x 阶段依赖图	任务依赖图	必须
4.x 模块架构	模块架构图	建议
6. 里程碑	里程碑图	必须

注意事项

• DevelopmentPlan 使用技术语言，面向开发团队
• 开发计划必须覆盖 FeatureSummary 所有功能
• 技术方案要具体可执行，避免过于抽象
• 阶段划分要合理，考虑依赖关系
• 时间安排要务实，预留缓冲
• 风险评估要全面，有应对措施

质量检查

生成 DevelopmentPlan 后，自查以下项目：

• 覆盖 FeatureSummary 所有功能
• 系统架构图清晰展示整体结构
• 模块依赖图清晰展示依赖关系
• 数据流图展示关键数据流转
• 开发阶段有时间线图
• 每个阶段有任务依赖图
• 里程碑有里程碑图
• 技术方案具体可执行
• 任务 ID 唯一（T-xxx）
• 任务与功能 ID 关联