zhangfucai/spec-coding-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Add 19 Claude Code skills for document workflow

Browse Source 
Skills included:
- Review (6): rr, rp, rf, rd, ru, rt
- Write (5): wp, wf, wd, wu, wt
- Modify (6): mr, mp, mf, md, mu, mt
- Utils (2): iter, up

Supports complete document lifecycle:
RequirementsDoc → PRD → FeatureSummary → DevelopmentPlan → UIDesign → tasks

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
zfc 2026-01-23 11:27:09 +08:00
commit d372fd82f9
21 changed files with 3239 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

209
.claude/skills/iter/SKILL.md Normal file
View File

@ -0,0 +1,209 @@
---
name: iter
description: 迭代变更入口，调研问题后更新 PRD.md 和 tasks.md，支持 Bug 修复、功能迭代、技术重构。
---
# Iterate - 迭代变更
> **定位**：1-100 阶段的变更入口。项目已上线，需要修复问题或迭代功能时，通过此 skill 调研、澄清、更新文档。
当用户调用 `/iter` 或 `/iter <问题描述>` 时，执行以下步骤：
## 1. 获取变更描述
如果用户提供了参数，使用该描述。否则询问：
> 请描述需要迭代的内容（Bug/功能/重构）
**示例输入**：
- "登录验证存在漏洞，token 过期后仍可访问"
- "列表页需要增加按时间筛选功能"
- "用户模块性能太差，需要重构缓存策略"
## 2. 调研分析
### 2.1 读取现有文档
读取以下文件了解当前状态：
1. `doc/PRD.md` - 了解产品定义
2. `doc/tasks.md` - 了解任务现状
### 2.2 调研相关代码（可选）
根据问题描述，定位相关代码文件：
- 搜索关键词定位文件
- 读取相关模块代码
- 分析现有实现
### 2.3 分析变更类型
| 类型 | 特征 | 影响范围 |
|------|------|----------|
| Bug/漏洞 | 现有功能不符合预期 | 修复逻辑，可能涉及安全 |
| 功能迭代 | 在现有功能上增加/调整 | 新增或修改功能点 |
| 技术重构 | 不改功能，优化实现 | 性能、架构、代码质量 |
## 3. 澄清确认
**【必须】向用户提出澄清问题**，确保理解准确：
### 3.1 问题理解确认
向用户确认：
> 我理解的变更需求是：{一句话总结}
>
> 变更类型：{Bug修复 / 功能迭代 / 技术重构}
>
> 影响范围：{涉及的模块/功能}
### 3.2 方案选择（如有多种）
如果有多种解决方案，列出选项让用户选择：
```
方案 A：{描述}
- 优点：...
- 缺点：...
方案 B：{描述}
- 优点：...
- 缺点：...
请选择方案，或说明其他想法。
```
### 3.3 边界确认
确认变更边界：
> 本次变更**包含**：
> - {范围1}
> - {范围2}
>
> 本次变更**不包含**：
> - {排除项}
>
> 是否确认？
## 4. 用户确认后执行
**只有用户明确确认后**，才执行以下更新：
### 4.1 更新 PRD.md
使用增量修改标记：
```markdown
<!-- ITER: {日期} - {变更简述} -->
<!-- NEW START -->
新增内容...
<!-- NEW END -->
```
或修改现有内容：
```markdown
<!-- ITER: {日期} - {变更简述} -->
<!-- MODIFIED: 原内容为 "xxx" -->
修改后的内容
```
**更新位置**：
- Bug 修复 → 更新对应功能的验收标准
- 功能迭代 → 在 3.2 功能详情添加/修改功能点
- 技术重构 → 在 4.x 非功能需求或 7.1 技术约束中说明
### 4.2 更新 tasks.md
新增任务使用标记：
```markdown
<!-- ITER: {日期} - {变更简述} -->
| T-xxx | {任务名} | {描述} | {依赖} | {优先级} | {验收标准} |
```
**任务 ID 规则**：
- 查找现有最大 ID，递增分配
- 格式：T-xxx（三位数字）
### 4.3 标记规范
所有变更使用 `<!-- ITER: -->` 前缀，区分于 `/mp` `/mt` 的标记：
- `<!-- ITER: 2026-01-23 - 修复登录验证漏洞 -->`
- 便于追溯迭代历史
## 5. 输出摘要
完成后向用户展示：
```
## 迭代变更完成
**变更类型**: {Bug修复 / 功能迭代 / 技术重构}
**变更摘要**: {一句话描述}
**已更新文档**:
- doc/PRD.md: {更新位置}
- doc/tasks.md: 新增任务 T-xxx
**新增任务**:
| ID | 任务 | 优先级 |
|----|------|--------|
| T-xxx | {任务名} | P0/P1/P2 |
**下一步**:
- 执行任务 T-xxx
- 或运行 `/rp` `/rt` 评审变更
```
---
## 工作流示意
```
用户描述问题
│
▼
┌─────────────┐
│ 调研分析 │ ──▶ 读取 PRD、tasks、相关代码
└──────┬──────┘
│
▼
┌─────────────┐
│ 澄清确认 │ ──▶ 提问 → 用户回答 → 确认方案
└──────┬──────┘
│
▼ 用户确认
┌─────────────┐
│ 更新文档 │ ──▶ PRD.md + tasks.md
└──────┬──────┘
│
▼
┌─────────────┐
│ 输出摘要 │
└─────────────┘
```
## 注意事项
- **必须先澄清确认**，不要假设用户意图
- 变更范围要明确，避免 scope creep
- 优先级根据问题严重程度判断：
- 安全漏洞 → P0
- 功能 Bug → P0/P1
- 功能迭代 → P1/P2
- 技术重构 → P1/P2
- 只更新 PRD + tasks，保持轻量
- 如需更新其他文档，提示用户手动运行 `/mf` `/md` 等
## 与其他 skill 的关系
| 场景 | 使用 skill |
|------|------------|
| 迭代变更入口 | `/iter`（本 skill） |
| 需要更新 FeatureSummary | `/iter` 后运行 `/mf` |
| 需要更新 DevelopmentPlan | `/iter` 后运行 `/md` |
| 需要评审变更 | `/iter` 后运行 `/rp` `/rt` |
| 从头生成文档 | 使用 `/wp` `/wf` `/wd` 等 |

112
.claude/skills/md/SKILL.md Normal file
View File

@ -0,0 +1,112 @@
---
name: md
description: 增量修改 DevelopmentPlan.md，根据用户指令在现有内容基础上更新开发计划。
---
# Modify DevelopmentPlan
当用户调用 `/md` 时，执行以下步骤：
## 1. 读取目标文档
读取以下文件：
1. `doc/DevelopmentPlan.md` - 目标文档（必须存在）
2. `doc/FeatureSummary.md` - 上游参考文档
3. `doc/review-DevelopmentPlan-claude.md` - 评审报告（如果存在，自动作为修改依据）
如果 DevelopmentPlan.md 不存在，提示用户：
> DevelopmentPlan.md 不存在，请先使用 `/wd` 生成开发计划。
## 2. 确定修改来源
按以下优先级确定修改内容：
### 2.1 用户提供了修改指令
如果用户在调用 `/md` 时附带了参数或说明，直接使用该指令。
### 2.2 自动检测评审报告
如果用户未提供修改指令，**自动检测** `doc/review-DevelopmentPlan-claude.md` 是否存在：
- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认：
> 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？
- **不存在**：询问用户：
> 请说明需要修改的内容，或先运行 `/rd` 生成评审报告。
## 3. 修改原则
### 3.1 增量修改
- 保留原有内容结构和格式
- 仅修改/新增指定部分
- 不删除未明确要求删除的内容
### 3.2 新增内容标记
对于新增的段落或章节：
```markdown
<!-- NEW START -->
新增内容...
<!-- NEW END -->
```
对于行内新增：
```markdown
原有内容 <!-- NEW --> 新增内容
```
### 3.3 修改内容标记
```markdown
<!-- MODIFIED: 原内容为 "xxx" -->
修改后的内容
```
### 3.4 与 FeatureSummary 一致性
- 开发任务必须覆盖所有功能
- 技术方案必须支撑功能需求
- 阶段划分必须合理
## 4. 执行修改
| 修改类型 | 处理方式 |
|----------|----------|
| 新增开发任务 | 在对应阶段表格中添加行 |
| 修改技术方案 | 更新技术方案章节，添加 MODIFIED 标记 |
| 调整阶段划分 | 移动任务到新阶段，标记变更 |
| 新增风险项 | 在风险管理表格中添加行 |
| 修改里程碑 | 更新里程碑表格 |
## 5. 保存并验证
1. 保存修改后的文档到 `doc/DevelopmentPlan.md`
2. 使用 git diff 展示变更内容
3. 向用户确认修改是否符合预期
## 6. 输出摘要
向用户展示修改摘要：
- 修改位置（章节/行号）
- 修改类型（新增/修改/删除）
- 修改内容概要
- 与 FeatureSummary 的一致性确认
---
## 注意事项
- DevelopmentPlan 依赖于 FeatureSummary，修改时需确保与上游一致
- 修改后，下游文档（UIDesign、tasks）可能需要同步更新
- 技术方案修改需谨慎评估影响范围
- 建议修改完成后运行 `/ru` 检查下游一致性
## 标记清理
用户确认修改无误后，可手动删除标记或保留作为变更历史参考。

111
.claude/skills/mf/SKILL.md Normal file
View File

@ -0,0 +1,111 @@
---
name: mf
description: 增量修改 FeatureSummary.md，根据用户指令在现有内容基础上更新功能摘要。
---
# Modify FeatureSummary
当用户调用 `/mf` 时，执行以下步骤：
## 1. 读取目标文档
读取以下文件：
1. `doc/FeatureSummary.md` - 目标文档（必须存在）
2. `doc/PRD.md` - 上游参考文档
3. `doc/review-FeatureSummary-claude.md` - 评审报告（如果存在，自动作为修改依据）
如果 FeatureSummary.md 不存在，提示用户：
> FeatureSummary.md 不存在，请先使用 `/wf` 生成功能摘要。
## 2. 确定修改来源
按以下优先级确定修改内容：
### 2.1 用户提供了修改指令
如果用户在调用 `/mf` 时附带了参数或说明，直接使用该指令。
### 2.2 自动检测评审报告
如果用户未提供修改指令，**自动检测** `doc/review-FeatureSummary-claude.md` 是否存在：
- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认：
> 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？
- **不存在**：询问用户：
> 请说明需要修改的内容，或先运行 `/rf` 生成评审报告。
## 3. 修改原则
### 3.1 增量修改
- 保留原有内容结构和格式
- 仅修改/新增指定部分
- 不删除未明确要求删除的内容
### 3.2 新增内容标记
对于新增的段落或章节：
```markdown
<!-- NEW START -->
新增内容...
<!-- NEW END -->
```
对于行内新增：
```markdown
原有内容 <!-- NEW --> 新增内容
```
### 3.3 修改内容标记
```markdown
<!-- MODIFIED: 原内容为 "xxx" -->
修改后的内容
```
### 3.4 与 PRD 一致性
- 所有功能必须来源于 PRD
- 修改后的功能描述必须与 PRD 一致
- 优先级必须与 PRD 匹配
## 4. 执行修改
| 修改类型 | 处理方式 |
|----------|----------|
| 新增功能 | 在对应模块表格中添加行 |
| 修改描述 | 更新功能描述，添加 MODIFIED 标记 |
| 修改优先级 | 更新优先级列 |
| 新增模块 | 在功能清单中添加新章节 |
| 删除功能 | 标记为删除而非直接移除 |
## 5. 保存并验证
1. 保存修改后的文档到 `doc/FeatureSummary.md`
2. 使用 git diff 展示变更内容
3. 向用户确认修改是否符合预期
## 6. 输出摘要
向用户展示修改摘要：
- 修改位置（章节/行号）
- 修改类型（新增/修改/删除）
- 修改内容概要
- 与 PRD 的一致性确认
---
## 注意事项
- FeatureSummary 依赖于 PRD，修改时需确保与上游一致
- 修改后，下游文档（DevelopmentPlan 等）可能需要同步更新
- 建议修改完成后运行 `/rd` 检查下游一致性
## 标记清理
用户确认修改无误后，可手动删除标记或保留作为变更历史参考。

144
.claude/skills/mp/SKILL.md Normal file
View File

@ -0,0 +1,144 @@
---
name: mp
description: 增量修改 PRD.md，根据用户指令在现有内容基础上更新产品需求文档。
---
# Modify PRD
当用户调用 `/mp` 时，执行以下步骤：
## 1. 读取目标文档
读取以下文件：
1. `doc/PRD.md` - 目标文档（必须存在）
2. `doc/RequirementsDoc.md` - 上游参考文档
3. `doc/review-PRD-claude.md` - 评审报告（如果存在，自动作为修改依据）
如果 PRD.md 不存在，提示用户：
> PRD.md 不存在，请先使用 `/wp` 生成产品需求文档。
## 2. 确定修改来源
按以下优先级确定修改内容：
### 2.1 用户提供了修改指令
如果用户在调用 `/mp` 时附带了参数或说明，直接使用该指令。
### 2.2 自动检测评审报告
如果用户未提供修改指令，**自动检测** `doc/review-PRD-claude.md` 是否存在：
- **存在**：读取评审报告，提取其中的问题清单（Critical / Major / Minor），作为本次修改的依据。向用户确认：
> 检测到评审报告 `doc/review-PRD-claude.md`，包含 X 个问题。是否根据评审报告进行修改？
- **不存在**：询问用户：
> 请说明需要修改的内容，或先运行 `/rp` 生成评审报告。
### 2.3 支持的修改来源
- 具体的修改描述（如"在功能需求中增加用户权限管理模块"）
- 评审报告（自动检测或手动指定路径）
- 对应的 RequirementsDoc 变更（如"/mr 已更新需求，请同步 PRD"）
## 3. 修改原则
### 3.1 增量修改
- 保留原有内容结构和格式
- 仅修改/新增指定部分
- 不删除未明确要求删除的内容
### 3.2 新增内容标记
对于新增的段落或章节，使用 HTML 注释标记：
```markdown
<!-- NEW START -->
新增内容...
<!-- NEW END -->
```
对于行内新增，使用：
```markdown
原有内容 <!-- NEW --> 新增内容
```
### 3.3 修改内容标记
对于修改的内容，保留原文作为注释：
```markdown
<!-- MODIFIED: 原内容为 "xxx" -->
修改后的内容
```
### 3.4 与 RequirementsDoc 一致性
- 所有 PRD 内容必须可追溯到 RequirementsDoc
- 如果修改涉及新功能，先确认 RequirementsDoc 中已有对应需求
- 如果 RequirementsDoc 未包含相关需求，提醒用户先更新需求文档
## 4. 执行修改
按照用户指令修改文档：
1. 定位到需要修改的位置
2. 执行增量修改
3. 添加相应的标记
4. 保持文档格式一致性
5. 确保修改内容与 RequirementsDoc 一致
### 4.1 修改类型处理
| 修改类型 | 处理方式 |
|----------|----------|
| 新增功能点 | 在对应功能模块表格中添加行，关联用户故事 |
| 新增用户故事 | 在 2.2 用户故事列表中添加，分配 US-xxx ID |
| 修改优先级 | 更新功能点优先级，必要时调整用户故事分类 |
| 修改验收标准 | 更新对应功能点的验收标准列 |
| 新增模块 | 在 3.2 功能详情中添加新的子章节 |
| 修改非功能需求 | 在对应章节更新指标或要求 |
## 5. 保存并验证
1. 保存修改后的文档到 `doc/PRD.md`
2. 使用 git diff 展示变更内容
3. 向用户确认修改是否符合预期
## 6. 输出摘要
向用户展示修改摘要：
- 修改位置（章节/行号）
- 修改类型（新增/修改/删除）
- 修改内容概要
- 与 RequirementsDoc 的一致性确认
---
## 注意事项
- PRD 依赖于 RequirementsDoc，修改时需确保与上游文档一致
- 修改 PRD 后，下游文档（FeatureSummary、DevelopmentPlan 等）可能需要同步更新
- 保持现有文档风格（标题层级、表格格式、列表样式）
- 用户故事 ID 必须唯一且连续（US-001, US-002...）
- 所有功能点必须关联到用户故事
- 重大修改建议先运行 `/rp` 评审确认影响范围
- 修改完成后，建议用户运行 `/rf` 检查下游文档一致性
## 标记清理
当用户确认修改无误后，可手动删除 `<!-- NEW -->` 和 `<!-- MODIFIED -->` 标记，或保留作为变更历史参考。
通过 git 可追溯完整修改历史。
## 质量检查
修改 PRD 后，自查以下项目：
- [ ] 修改内容与 RequirementsDoc 一致
- [ ] 新增用户故事有唯一 ID
- [ ] 新增功能点关联到用户故事
- [ ] 新增功能点有明确优先级和验收标准
- [ ] 标记格式正确（`<!-- NEW -->` / `<!-- MODIFIED -->`）
- [ ] 文档结构完整，格式一致

95
.claude/skills/mr/SKILL.md Normal file
View File

@ -0,0 +1,95 @@
---
name: mr
description: 增量修改 RequirementsDoc.md，根据用户指令在现有内容基础上更新需求文档。
---
# Modify RequirementsDoc
当用户调用 `/mr` 时，执行以下步骤：
## 1. 读取目标文档
读取 `doc/RequirementsDoc.md` 文件。
如果文件不存在，提示用户：
> RequirementsDoc.md 不存在，请先使用人工方式创建需求文档。
## 2. 获取修改指令
向用户确认修改内容。用户应提供以下信息之一：
- 具体的修改描述（如"在第3节增加性能需求"）
- 评审报告路径（如 `doc/review-RequirementsDoc-claude.md`）
- 直接的修改内容
如果用户未提供修改指令，询问：
> 请说明需要修改的内容，或提供评审报告路径。
## 3. 修改原则
### 3.1 增量修改
- 保留原有内容结构和格式
- 仅修改/新增指定部分
- 不删除未明确要求删除的内容
### 3.2 新增内容标记
对于新增的段落或章节，使用 HTML 注释标记：
```markdown
<!-- NEW START -->
新增内容...
<!-- NEW END -->
```
对于行内新增，使用：
```markdown
原有内容 <!-- NEW --> 新增内容
```
### 3.3 修改内容标记
对于修改的内容，保留原文作为注释：
```markdown
<!-- MODIFIED: 原内容为 "xxx" -->
修改后的内容
```
## 4. 执行修改
按照用户指令修改文档：
1. 定位到需要修改的位置
2. 执行增量修改
3. 添加相应的标记
4. 保持文档格式一致性
## 5. 保存并验证
1. 保存修改后的文档到 `doc/RequirementsDoc.md`
2. 使用 git diff 展示变更内容
3. 向用户确认修改是否符合预期
## 6. 输出摘要
向用户展示修改摘要：
- 修改位置（章节/行号）
- 修改类型（新增/修改/删除）
- 修改内容概要
---
## 注意事项
- RequirementsDoc 是文档链源头，修改会影响所有下游文档
- 修改前确认用户意图，避免误改
- 保持现有文档风格（标题层级、表格格式、列表样式）
- 重大修改建议先运行 `/rr` 评审确认影响范围
- 修改完成后，建议用户检查下游文档是否需要同步更新
## 标记清理
当用户确认修改无误后，可手动删除 `<!-- NEW -->` 和 `<!-- MODIFIED -->` 标记，或保留作为变更历史参考。
通过 git 可追溯完整修改历史。

132
.claude/skills/mt/SKILL.md Normal file
View File

@ -0,0 +1,132 @@
---
name: mt
description: 增量修改 tasks.md，根据用户指令在现有内容基础上更新任务列表。
---
# Modify Tasks
当用户调用 `/mt` 时，执行以下步骤：
## 1. 读取目标文档
读取以下文件：
1. `doc/tasks.md` - 目标文档（必须存在）
2. `doc/UIDesign.md` - 上游参考文档
3. `doc/DevelopmentPlan.md` - 上游参考文档
4. `doc/review-tasks-claude.md` - 评审报告（如果存在，自动作为修改依据）
如果 tasks.md 不存在，提示用户：
> tasks.md 不存在，请先使用 `/wt` 生成任务列表。
## 2. 确定修改来源
按以下优先级确定修改内容：
### 2.1 用户提供了修改指令
如果用户在调用 `/mt` 时附带了参数或说明，直接使用该指令。
### 2.2 自动检测评审报告
如果用户未提供修改指令，**自动检测** `doc/review-tasks-claude.md` 是否存在：
- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认：
> 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？
- **不存在**：询问用户：
> 请说明需要修改的内容，或先运行 `/rt` 生成评审报告。
## 3. 修改原则
### 3.1 增量修改
- 保留原有内容结构和格式
- 仅修改/新增指定部分
- 不删除未明确要求删除的内容
### 3.2 新增内容标记
对于新增的段落或章节：
```markdown
<!-- NEW START -->
新增内容...
<!-- NEW END -->
```
对于行内新增：
```markdown
原有内容 <!-- NEW --> 新增内容
```
### 3.3 修改内容标记
```markdown
<!-- MODIFIED: 原内容为 "xxx" -->
修改后的内容
```
### 3.4 与上游文档一致性
- 任务必须覆盖 DevelopmentPlan 所有开发项
- 任务必须覆盖 UIDesign 所有页面实现
- 任务依赖关系必须合理
## 4. 执行修改
| 修改类型 | 处理方式 |
|----------|----------|
| 新增任务 | 在对应阶段表格中添加行，分配新 ID |
| 修改描述 | 更新任务描述，添加 MODIFIED 标记 |
| 修改优先级 | 更新优先级列 |
| 修改依赖 | 更新依赖列，检查循环依赖 |
| 修改验收标准 | 更新验收标准列 |
| 调整阶段 | 移动任务到新阶段，更新依赖图 |
### 4.1 任务 ID 规则
- 新增任务 ID 必须唯一
- ID 格式：T-XXX（三位数字，如 T-001）
- 在现有最大 ID 基础上递增
## 5. 保存并验证
1. 保存修改后的文档到 `doc/tasks.md`
2. 使用 git diff 展示变更内容
3. 向用户确认修改是否符合预期
## 6. 输出摘要
向用户展示修改摘要：
- 修改位置（章节/行号）
- 修改类型（新增/修改/删除）
- 修改内容概要
- 新增/修改的任务 ID 列表
- 与上游文档的一致性确认
---
## 注意事项
- tasks.md 是文档链末端，修改不影响其他文档
- 任务 ID 必须唯一，不可重复使用已删除的 ID
- 修改依赖关系时需检查是否产生循环依赖
- 验收标准必须具体可测试
- 任务粒度要适中
## 标记清理
用户确认修改无误后，可手动删除标记或保留作为变更历史参考。
## 质量检查
修改 tasks 后，自查以下项目：
- [ ] 任务 ID 唯一且格式正确
- [ ] 无循环依赖
- [ ] 验收标准明确
- [ ] 覆盖所有上游功能
- [ ] 标记格式正确

114
.claude/skills/mu/SKILL.md Normal file
View File

@ -0,0 +1,114 @@
---
name: mu
description: 增量修改 UIDesign.md，根据用户指令在现有内容基础上更新 UI 设计文档。
---
# Modify UIDesign
当用户调用 `/mu` 时，执行以下步骤：
## 1. 读取目标文档
读取以下文件：
1. `doc/UIDesign.md` - 目标文档（必须存在）
2. `doc/DevelopmentPlan.md` - 上游参考文档
3. `doc/review-UIDesign-claude.md` - 评审报告（如果存在，自动作为修改依据）
如果 UIDesign.md 不存在，提示用户：
> UIDesign.md 不存在，请先使用 `/wu` 生成 UI 设计文档。
## 2. 确定修改来源
按以下优先级确定修改内容：
### 2.1 用户提供了修改指令
如果用户在调用 `/mu` 时附带了参数或说明，直接使用该指令。
### 2.2 自动检测评审报告
如果用户未提供修改指令，**自动检测** `doc/review-UIDesign-claude.md` 是否存在：
- **存在**：读取评审报告，提取其中的问题清单，作为本次修改的依据。向用户确认：
> 检测到评审报告，包含 X 个问题。是否根据评审报告进行修改？
- **不存在**：询问用户：
> 请说明需要修改的内容，或先运行 `/ru` 生成评审报告。
## 3. 修改原则
### 3.1 增量修改
- 保留原有内容结构和格式
- 仅修改/新增指定部分
- 不删除未明确要求删除的内容
### 3.2 新增内容标记
对于新增的段落或章节：
```markdown
<!-- NEW START -->
新增内容...
<!-- NEW END -->
```
对于行内新增：
```markdown
原有内容 <!-- NEW --> 新增内容
```
### 3.3 修改内容标记
```markdown
<!-- MODIFIED: 原内容为 "xxx" -->
修改后的内容
```
### 3.4 与 DevelopmentPlan 一致性
- 页面设计必须覆盖所有功能模块
- 交互流程必须支撑功能需求
- 设计规范必须统一
## 4. 执行修改
| 修改类型 | 处理方式 |
|----------|----------|
| 新增页面 | 在页面设计章节添加新子章节 |
| 修改布局 | 更新布局描述，添加 MODIFIED 标记 |
| 修改组件 | 更新组件表格 |
| 修改交互 | 更新交互说明 |
| 新增状态 | 在状态列表中添加项目 |
| 修改设计规范 | 更新设计规范章节 |
## 5. 保存并验证
1. 保存修改后的文档到 `doc/UIDesign.md`
2. 使用 git diff 展示变更内容
3. 向用户确认修改是否符合预期
## 6. 输出摘要
向用户展示修改摘要：
- 修改位置（章节/行号）
- 修改类型（新增/修改/删除）
- 修改内容概要
- 与 DevelopmentPlan 的一致性确认
---
## 注意事项
- UIDesign 依赖于 DevelopmentPlan，修改时需确保与上游一致
- 修改后，下游文档（tasks）可能需要同步更新
- 页面修改需考虑对用户流程的影响
- 设计规范修改需检查所有页面的一致性
- 建议修改完成后运行 `/rt` 检查下游一致性
## 标记清理
用户确认修改无误后，可手动删除标记或保留作为变更历史参考。

101
.claude/skills/rd/SKILL.md Normal file
View File

@ -0,0 +1,101 @@
---
name: rd
description: 评审 DevelopmentPlan.md，检查技术可行性和与上游文档一致性，输出结构化评审报告。
---
# Review DevelopmentPlan
当用户调用 `/rd` 时，执行以下步骤：
## 1. 读取文档
读取以下文件：
1. `doc/DevelopmentPlan.md` - 目标文档（必须存在）
2. `doc/FeatureSummary.md` - 上游参照文档
如果 DevelopmentPlan.md 不存在，提示用户：
> DevelopmentPlan.md 不存在，请先使用 `/wd` 生成开发计划。
## 2. 评审维度
### 2.1 与 FeatureSummary 一致性检查
- 开发任务是否覆盖所有功能模块
- 技术方案是否支撑功能需求
- 排期是否合理
### 2.2 技术可行性检查
- 技术方案是否可行
- 技术栈选择是否合理
- 是否存在技术风险
- 依赖关系是否明确
### 2.3 完整性检查
- 是否有明确的里程碑划分
- 是否有资源分配说明
- 是否有风险应对措施
## 3. 生成评审报告
输出到 `doc/review-DevelopmentPlan-claude.md`，结构如下：
```markdown
# DevelopmentPlan 评审报告
## 概要
| 项目 | 内容 |
|------|------|
| 评审时间 | {YYYY-MM-DD HH:MM} |
| 目标文档 | doc/DevelopmentPlan.md |
| 参照文档 | doc/FeatureSummary.md |
| 问题统计 | X 个严重 / Y 个一般 / Z 个建议 |
## 功能覆盖分析
| FeatureSummary 功能 | DevelopmentPlan 对应 | 状态 |
|---------------------|----------------------|------|
| {功能名} | {对应任务/模块} | ✅/⚠️/❌ |
## 技术风险分析
| 风险项 | 影响范围 | 严重程度 | 建议措施 |
|--------|----------|----------|----------|
| {风险} | {范围} | 高/中/低 | {措施} |
## 问题清单
### 严重问题 (Critical)
{问题列表，含位置引用}
### 一般问题 (Major)
{问题列表，含位置引用}
### 改进建议 (Minor)
{建议列表}
## 评审结论
{通过 / 需修改后通过 / 不通过}
### 下一步行动
- [ ] {待办事项}
```
## 4. 输出规范
- 输出语言：中文
- 问题分级：Critical / Major / Minor
- 包含文件引用（如 `doc/DevelopmentPlan.md:28`）
- 技术风险需明确影响范围和应对建议
---
## 注意事项
- 只做评审，不修改原文档
- 重点关注技术可行性和风险
- 评审报告保存后，建议用户根据问题运行 `/md` 修改

96
.claude/skills/rf/SKILL.md Normal file
View File

@ -0,0 +1,96 @@
---
name: rf
description: 评审 FeatureSummary.md，对比 PRD 检查一致性，输出结构化评审报告。
---
# Review FeatureSummary
当用户调用 `/rf` 时，执行以下步骤：
## 1. 读取文档
读取以下文件：
1. `doc/FeatureSummary.md` - 目标文档（必须存在）
2. `doc/PRD.md` - 上游参照文档
如果 FeatureSummary.md 不存在，提示用户：
> FeatureSummary.md 不存在，请先使用 `/wf` 生成功能摘要。
## 2. 评审维度
### 2.1 与 PRD 一致性检查
- 功能模块是否完整覆盖 PRD 3.2 功能详情
- 功能描述是否与 PRD 一致
- 优先级标注是否与 PRD 匹配
### 2.2 完整性检查
- 每个功能模块是否有清晰的描述
- 是否遗漏 PRD 中的功能点
- 功能分类是否合理
### 2.3 质量检查
- 描述是否简洁准确
- 是否有冗余或重复内容
- 格式是否规范统一
## 3. 生成评审报告
输出到 `doc/review-FeatureSummary-claude.md`，结构如下：
```markdown
# FeatureSummary 评审报告
## 概要
| 项目 | 内容 |
|------|------|
| 评审时间 | {YYYY-MM-DD HH:MM} |
| 目标文档 | doc/FeatureSummary.md |
| 参照文档 | doc/PRD.md |
| 问题统计 | X 个严重 / Y 个一般 / Z 个建议 |
## 覆盖度分析
| PRD 功能模块 | FeatureSummary 对应 | 状态 |
|--------------|---------------------|------|
| {模块名} | {对应位置} | ✅/⚠️/❌ |
**覆盖率**: X/Y 完全覆盖
## 问题清单
### 严重问题 (Critical)
{问题列表，含位置引用}
### 一般问题 (Major)
{问题列表，含位置引用}
### 改进建议 (Minor)
{建议列表}
## 评审结论
{通过 / 需修改后通过 / 不通过}
### 下一步行动
- [ ] {待办事项}
```
## 4. 输出规范
- 输出语言：中文
- 问题分级：Critical / Major / Minor
- 包含文件引用（如 `doc/FeatureSummary.md:15`）
- 问题按严重性排序
---
## 注意事项
- 只做评审，不修改原文档
- 重点检查与 PRD 的一致性
- 评审报告保存后，建议用户根据问题运行 `/mf` 修改

177
.claude/skills/rp/SKILL.md Normal file
View File

@ -0,0 +1,177 @@
---
name: rp
description: 评审 PRD.md，对比 RequirementsDoc 检查一致性，输出结构化评审报告。
---
# Review PRD
当用户调用 `/rp` 时，执行以下步骤：
## 1. 读取文档
读取以下文件：
- 目标文档：`doc/PRD.md`
- 上游文档：`doc/RequirementsDoc.md`
如果 PRD.md 不存在，提示用户：
> PRD.md 不存在，请先使用 `/wp` 生成 PRD。
如果 RequirementsDoc.md 不存在，提示用户：
> RequirementsDoc.md 不存在，无法进行一致性检查。请先创建需求文档。
## 2. 评审维度
PRD 位于文档链的第二层，需要对比上游 RequirementsDoc 进行评审。
### 2.1 与 RequirementsDoc 的一致性
- [ ] PRD 是否覆盖了 RequirementsDoc 中的所有功能需求
- [ ] PRD 是否覆盖了 RequirementsDoc 中的所有非功能需求
- [ ] PRD 中是否有 RequirementsDoc 中未提及的需求（需标注来源）
- [ ] 术语定义是否与 RequirementsDoc 一致
- [ ] 优先级划分是否与 RequirementsDoc 一致
### 2.2 用户故事质量
- [ ] 所有用户故事是否有唯一 ID（US-xxx）
- [ ] 用户故事是否符合格式：作为{角色}，我想要{功能}，以便{价值}
- [ ] 用户角色是否明确定义
- [ ] 验收标准是否具体可测试
- [ ] 用户旅程是否完整描述核心流程
### 2.3 功能需求完整性
- [ ] 功能架构是否清晰（模块划分合理）
- [ ] 所有功能点是否关联到用户故事
- [ ] 功能点是否有明确的优先级
- [ ] 功能点是否有验收标准
- [ ] 是否遗漏边界情况和异常处理
### 2.4 非功能需求
- [ ] 性能需求是否有量化指标
- [ ] 安全需求是否明确
- [ ] 兼容性需求是否完整
- [ ] 可用性需求是否可验证
### 2.5 文档结构
- [ ] 文档结构是否完整（无空章节）
- [ ] 格式是否统一（表格、列表、标题层级）
- [ ] 术语表是否完整
## 3. 生成评审报告
按以下格式输出评审报告：
```markdown
# PRD 评审报告
## 概要
| 项目 | 内容 |
|------|------|
| 评审时间 | {YYYY-MM-DD HH:mm} |
| 目标文档 | doc/PRD.md |
| 参照文档 | doc/RequirementsDoc.md |
| 问题统计 | {critical} 个严重 / {major} 个一般 / {minor} 个建议 |
## 一致性检查
### 需求覆盖分析
| RequirementsDoc 需求项 | PRD 对应位置 | 状态 |
|------------------------|--------------|------|
| {需求1} | {PRD章节/用户故事ID} | ✅ 已覆盖 / ⚠️ 部分覆盖 / ❌ 未覆盖 |
### 差异说明
{列出 PRD 中新增的、RequirementsDoc 未提及的内容，需说明来源或理由}
## 问题清单
### 严重问题 (Critical)
> 必须修复，否则影响后续文档生成
1. **[位置: doc/PRD.md:行号]** 问题描述
- 现状：...
- 与 RequirementsDoc 的差异：...
- 建议：...
### 一般问题 (Major)
> 建议修复，可提升文档质量
1. **[位置]** 问题描述
- 建议：...
### 改进建议 (Minor)
> 可选优化项
1. **[位置]** 建议内容
## 用户故事评估
| 评估项 | 结果 |
|--------|------|
| 用户故事总数 | {数量} |
| 符合格式规范 | {数量} / {总数} |
| 有验收标准 | {数量} / {总数} |
| 关联功能点 | {数量} / {总数} |
### 用户故事问题
{列出不符合规范的用户故事}
## 评审结论
{通过 / 需修改后通过 / 不通过}
**结论说明**：
- 通过：PRD 与 RequirementsDoc 一致，可进入下一阶段
- 需修改后通过：存在问题但不影响整体理解，修复后可继续
- 不通过：存在严重一致性问题或遗漏，需重新生成
### 下一步行动
- [ ] 行动项1
- [ ] 行动项2
```
## 4. 保存报告
将评审报告保存到 `doc/review-PRD-claude.md`。
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
## 5. 输出摘要
向用户展示评审摘要：
- 一致性检查结果（覆盖率）
- 发现的问题数量（按严重程度分类）
- 用户故事评估结果
- 评审结论
- 报告文件路径
---
## 注意事项
- 评审时保持客观，聚焦于文档质量和一致性
- 问题描述要具体，给出明确的位置引用（如 `doc/PRD.md:42`）
- 一致性检查要逐项对比，不能遗漏
- 建议要可操作，避免模糊表述
- 不要修改原文档，只输出评审报告
## 常见问题模式
在评审时重点关注以下常见问题：
1. **需求遗漏**：RequirementsDoc 中有但 PRD 中没有的需求
2. **需求偏离**：PRD 中的描述与 RequirementsDoc 不一致
3. **凭空添加**：PRD 中有但 RequirementsDoc 中没有的需求（需要来源说明）
4. **用户故事缺陷**：格式不规范、缺少验收标准、角色不明确
5. **功能孤立**：功能点未关联到任何用户故事
6. **优先级冲突**：PRD 与 RequirementsDoc 的优先级划分不一致

111
.claude/skills/rr/SKILL.md Normal file
View File

@ -0,0 +1,111 @@
---
name: rr
description: 评审 RequirementsDoc.md，检查需求文档的完整性、清晰度和可执行性，输出结构化评审报告。
---
# Review RequirementsDoc
当用户调用 `/rr` 时，执行以下步骤：
## 1. 读取目标文档
读取 `doc/RequirementsDoc.md` 文件。
如果文件不存在，提示用户：
> RequirementsDoc.md 不存在，请先创建需求文档。
## 2. 评审维度
RequirementsDoc 是文档链的源头，没有上游依赖。重点检查以下维度：
### 2.1 完整性
- [ ] 产品概述是否清晰（定位、目标用户、核心价值）
- [ ] 功能需求是否完整列出
- [ ] 非功能需求是否涵盖（性能、安全、兼容性）
- [ ] 数据规范是否明确（输入输出格式、字段定义）
- [ ] 边界条件和异常情况是否考虑
### 2.2 清晰度
- [ ] 术语定义是否一致，无歧义
- [ ] 用例描述是否具体可理解
- [ ] 优先级是否明确标注
- [ ] 是否有模糊表述（"等"、"可能"、"应该"等）
### 2.3 可执行性
- [ ] 需求是否可被验证（有明确的验收标准）
- [ ] 技术约束是否合理
- [ ] 依赖项是否明确
### 2.4 结构规范
- [ ] 文档结构是否清晰（章节划分合理）
- [ ] 格式是否统一（表格、列表、标题层级）
## 3. 生成评审报告
按以下格式输出评审报告：
```markdown
# RequirementsDoc 评审报告
## 概要
| 项目 | 内容 |
|------|------|
| 评审时间 | {YYYY-MM-DD HH:mm} |
| 目标文档 | doc/RequirementsDoc.md |
| 问题统计 | {critical} 个严重 / {major} 个一般 / {minor} 个建议 |
## 问题清单
### 严重问题 (Critical)
> 必须修复，否则影响后续文档生成
1. **[位置: 第X节/第Y行]** 问题描述
- 现状：...
- 建议：...
### 一般问题 (Major)
> 建议修复，可提升文档质量
1. **[位置]** 问题描述
- 建议：...
### 改进建议 (Minor)
> 可选优化项
1. **[位置]** 建议内容
## 评审结论
{通过 / 需修改后通过 / 不通过}
### 下一步行动
- [ ] 行动项1
- [ ] 行动项2
```
## 4. 保存报告
将评审报告保存到 `doc/review-RequirementsDoc-claude.md`。
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
## 5. 输出摘要
向用户展示评审摘要：
- 发现的问题数量（按严重程度分类）
- 评审结论
- 报告文件路径
---
## 注意事项
- 评审时保持客观，聚焦于文档质量而非业务判断
- 问题描述要具体，给出明确的位置引用
- 建议要可操作，避免模糊表述
- 不要修改原文档，只输出评审报告

115
.claude/skills/rt/SKILL.md Normal file
View File

@ -0,0 +1,115 @@
---
name: rt
description: 评审 tasks.md，检查任务完整性和与上游文档一致性，输出结构化评审报告。
---
# Review Tasks
当用户调用 `/rt` 时，执行以下步骤：
## 1. 读取文档
读取以下文件：
1. `doc/tasks.md` - 目标文档（必须存在）
2. `doc/UIDesign.md` - 上游参照文档
3. `doc/DevelopmentPlan.md` - 上游参照文档
如果 tasks.md 不存在，提示用户：
> tasks.md 不存在，请先使用 `/wt` 生成任务列表。
## 2. 评审维度
### 2.1 与上游文档一致性检查
- 任务是否覆盖 DevelopmentPlan 所有开发项
- 任务是否覆盖 UIDesign 所有页面实现
- 任务优先级是否与功能优先级匹配
### 2.2 任务完整性检查
- 每个任务是否有明确的描述
- 任务粒度是否合适（不过大也不过小）
- 任务依赖关系是否明确
- 验收标准是否清晰
### 2.3 可执行性检查
- 任务是否可直接开始执行
- 是否有阻塞项未说明
- 估时是否合理（如有）
## 3. 生成评审报告
输出到 `doc/review-tasks-claude.md`，结构如下：
```markdown
# Tasks 评审报告
## 概要
| 项目 | 内容 |
|------|------|
| 评审时间 | {YYYY-MM-DD HH:MM} |
| 目标文档 | doc/tasks.md |
| 参照文档 | doc/UIDesign.md, doc/DevelopmentPlan.md |
| 问题统计 | X 个严重 / Y 个一般 / Z 个建议 |
## 覆盖度分析
### DevelopmentPlan 覆盖
| 开发项 | 对应任务 | 状态 |
|--------|----------|------|
| {开发项} | {任务ID/名称} | ✅/⚠️/❌ |
### UIDesign 覆盖
| UI 页面 | 对应任务 | 状态 |
|---------|----------|------|
| {页面名} | {任务ID/名称} | ✅/⚠️/❌ |
**总覆盖率**: X/Y
## 任务质量分析
| 检查项 | 通过数 | 总数 |
|--------|--------|------|
| 有明确描述 | X | Y |
| 有验收标准 | X | Y |
| 粒度合适 | X | Y |
## 问题清单
### 严重问题 (Critical)
{问题列表，含位置引用}
### 一般问题 (Major)
{问题列表，含位置引用}
### 改进建议 (Minor)
{建议列表}
## 评审结论
{通过 / 需修改后通过 / 不通过}
### 下一步行动
- [ ] {待办事项}
```
## 4. 输出规范
- 输出语言：中文
- 问题分级：Critical / Major / Minor
- 包含文件引用（如 `doc/tasks.md:12`）
- 任务问题需说明对开发执行的影响
---
## 注意事项
- 只做评审，不修改原文档
- 重点检查任务覆盖度和可执行性
- tasks.md 是文档链末端，必须覆盖所有上游功能
- 评审报告保存后，建议用户根据问题运行 `/mt` 修改

105
.claude/skills/ru/SKILL.md Normal file
View File

@ -0,0 +1,105 @@
---
name: ru
description: 评审 UIDesign.md，对比 DevelopmentPlan 检查设计一致性，输出结构化评审报告。
---
# Review UIDesign
当用户调用 `/ru` 时，执行以下步骤：
## 1. 读取文档
读取以下文件：
1. `doc/UIDesign.md` - 目标文档（必须存在）
2. `doc/DevelopmentPlan.md` - 上游参照文档
如果 UIDesign.md 不存在，提示用户：
> UIDesign.md 不存在，请先使用 `/wu` 生成 UI 设计文档。
## 2. 评审维度
### 2.1 与 DevelopmentPlan 一致性检查
- UI 页面是否覆盖所有功能模块
- 交互流程是否与开发计划匹配
- 页面结构是否支撑功能需求
### 2.2 设计完整性检查
- 页面列表是否完整
- 每个页面是否有清晰的布局描述
- 交互说明是否充分
- 状态变化是否考虑全面（加载、错误、空状态等）
### 2.3 可用性检查
- 用户流程是否顺畅
- 信息架构是否合理
- 是否有一致的设计规范
## 3. 生成评审报告
输出到 `doc/review-UIDesign-claude.md`，结构如下：
```markdown
# UIDesign 评审报告
## 概要
| 项目 | 内容 |
|------|------|
| 评审时间 | {YYYY-MM-DD HH:MM} |
| 目标文档 | doc/UIDesign.md |
| 参照文档 | doc/DevelopmentPlan.md |
| 问题统计 | X 个严重 / Y 个一般 / Z 个建议 |
## 页面覆盖分析
| DevelopmentPlan 功能 | UIDesign 页面 | 状态 |
|----------------------|---------------|------|
| {功能名} | {对应页面} | ✅/⚠️/❌ |
**覆盖率**: X/Y 完全覆盖
## 设计一致性检查
| 检查项 | 结果 |
|--------|------|
| 页面命名规范 | ✅/❌ |
| 布局风格统一 | ✅/❌ |
| 交互模式一致 | ✅/❌ |
## 问题清单
### 严重问题 (Critical)
{问题列表，含位置引用}
### 一般问题 (Major)
{问题列表，含位置引用}
### 改进建议 (Minor)
{建议列表}
## 评审结论
{通过 / 需修改后通过 / 不通过}
### 下一步行动
- [ ] {待办事项}
```
## 4. 输出规范
- 输出语言：中文
- 问题分级：Critical / Major / Minor
- 包含文件引用（如 `doc/UIDesign.md:45`）
- 设计问题需说明影响的用户体验
---
## 注意事项
- 只做评审，不修改原文档
- 重点检查页面覆盖度和设计一致性
- 评审报告保存后，建议用户根据问题运行 `/mu` 修改

78
.claude/skills/up/SKILL.md Normal file
View File

@ -0,0 +1,78 @@
---
name: update
aliases: [up]
description: 收集用户反馈并更新最近使用的 skill。可通过 /update 或 /up 调用。在用完某个 skill 后调用此命令来优化该 skill。
disable-model-invocation: true
argument-hint: [skill-name]
---
# Skill 更新助手
当用户调用 `/up` 或 `/up <skill-name>` 时，执行以下步骤：
## 1. 识别目标 Skill
**如果用户提供了参数 `$ARGUMENTS`**：
- 直接使用指定的 skill 名称作为更新目标
**如果没有提供参数**：
分析当前对话历史，找出最近使用的 skill：
- 搜索对话中的 `<command-name>` 标签，识别调用过的 skill
- 如果找到多个 skill，让用户确认要更新哪一个
- 如果没有找到任何 skill 调用记录，提示用户先使用一个 skill
## 2. 收集用户反馈
向用户询问以下问题（使用 AskUserQuestion 工具）：
**问题 1：这次使用体验如何？**
- 很好，skill 完全满足需求
- 基本满足，但有改进空间
- 不太满意，需要较大调整
**问题 2：具体需要改进的方面？**（多选）
- 执行步骤不够清晰
- 缺少某些功能
- 输出格式需要调整
- 提示词需要优化
- 其他（用户自定义输入）
## 3. 分析优化点
基于用户反馈和本次 skill 使用过程，分析以下方面：
1. **执行流程**：哪些步骤可以简化或合并？
2. **指令清晰度**：哪些指令描述不够明确？
3. **遗漏功能**：有哪些场景没有覆盖到？
4. **输出质量**：输出格式是否符合用户预期？
## 4. 定位 Skill 文件
按以下优先级搜索 skill 文件：
1. 项目级：`.claude/skills/<skill-name>/SKILL.md`
2. 用户级：`~/.claude/skills/<skill-name>/SKILL.md`
## 5. 更新 Skill
读取现有的 SKILL.md 文件内容，根据分析结果进行更新：
- 保持 frontmatter 格式不变（除非需要修改 description）
- 优化执行步骤的描述
- 添加缺失的功能说明
- 改进提示词的表达方式
- 添加必要的注意事项或边界情况处理
## 6. 确认更新
在更新前，向用户展示：
- 修改前后的对比（diff 格式）
- 说明每处修改的原因
用户确认后才执行实际的文件更新。
## 注意事项
- 如果 skill 文件不存在或路径无法确定，提示用户手动指定路径
- 更新时保持 skill 的原有风格和结构
- 重大修改需要用户明确确认
- 保留原有的有效内容，只做增量优化

323
.claude/skills/wd/SKILL.md Normal file
View File

@ -0,0 +1,323 @@
---
name: wd
description: 从上游文档生成 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
按以下结构生成文档：
```markdown
# {产品名称} - 开发计划
## 文档信息
| 项目 | 内容 |
|------|------|
| 版本 | 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 关联

234
.claude/skills/wf/SKILL.md Normal file
View File

@ -0,0 +1,234 @@
---
name: wf
description: 从 RequirementsDoc.md 和 PRD.md 生成 FeatureSummary.md，提供功能全貌概览。
---
# Write FeatureSummary
> **文档定位**：FeatureSummary 是「功能契约」文档，是产品与开发的桥梁。精确定义功能边界、输入输出、依赖关系，确保双方对"做什么"达成共识。
当用户调用 `/wf` 时，执行以下步骤：
## 1. 读取源文档
读取以下文件：
1. `doc/RequirementsDoc.md` - 必须存在
2. `doc/PRD.md` - 必须存在
如果文件不存在，提示用户：
> 缺少上游文档，请先确保 RequirementsDoc.md 和 PRD.md 存在。
如果已存在 `doc/FeatureSummary.md`，同时读取作为参考（保持风格一致）。
## 2. 分析功能需求
从 PRD 中提取以下信息：
### 2.1 功能模块
- 从 PRD 3.1 功能架构提取模块结构
- 从 PRD 3.2 功能详情提取各模块功能点
### 2.2 功能分类
按以下维度整理功能：
- 按模块分组
- 按优先级标注（P0/P1/P2）
- 按用户角色关联
### 2.3 功能边界
明确每个功能的：
- 输入：触发条件、输入数据
- 输出：预期结果、输出数据
- 边界：不包含什么、异常情况
## 3. 生成 FeatureSummary
按以下结构生成文档：
```markdown
# {产品名称} - 功能摘要
## 文档信息
| 项目 | 内容 |
|------|------|
| 版本 | v1.0 |
| 创建日期 | {YYYY-MM-DD} |
| 来源文档 | PRD.md |
## 1. 功能总览
### 1.1 功能统计
| 类别 | 数量 |
|------|------|
| 功能模块 | X 个 |
| P0 功能 | X 个 |
| P1 功能 | X 个 |
| P2 功能 | X 个 |
### 1.2 功能架构图
**【必须】使用模块图展示功能架构和模块关系：**
```
┌─────────────────────────────────────────────────┐
│ {产品名称} │
├─────────────────────────────────────────────────┤
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 模块A │ │ 模块B │ │ 模块C │ │
│ │ ──────── │ │ ──────── │ │ ──────── │ │
│ │ • 功能1 │ │ • 功能1 │ │ • 功能1 │ │
│ │ • 功能2 │ │ • 功能2 │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────┘
```
### 1.3 模块依赖关系
**【必须】使用依赖图展示模块间关系：**
```
┌──────────┐
│ 模块A │
└────┬─────┘
│ 依赖
▼
┌──────────┐ ┌──────────┐
│ 模块B │ ◀── │ 模块C │
└──────────┘ └──────────┘
```
## 2. 功能清单
### 2.1 {模块名称}
**模块职责**: {一句话描述模块职责}
#### 功能列表
| ID | 功能 | 描述 | 优先级 | 关联用户故事 |
|----|------|------|--------|--------------|
| F-001 | {功能名} | {简要描述} | P0 | US-xxx |
#### 功能契约详情
**F-001: {功能名}**
| 契约项 | 说明 |
|--------|------|
| **触发条件** | {什么情况下触发此功能} |
| **输入** | {输入数据/参数} |
| **处理逻辑** | {核心处理步骤} |
| **输出** | {输出结果/返回值} |
| **异常情况** | {可能的错误及处理} |
| **边界说明** | {不包含什么、限制条件} |
{重复以上结构覆盖所有功能}
{重复以上结构覆盖所有模块}
## 3. 功能依赖矩阵
**【必须】使用矩阵表格展示功能间依赖：**
| 功能 | 依赖 F-001 | 依赖 F-002 | 依赖 F-003 |
|------|------------|------------|------------|
| F-001 | - | | |
| F-002 | ✓ | - | |
| F-003 | | ✓ | - |
说明：
- ✓ 表示行功能依赖列功能
- 空白表示无依赖
## 4. 功能流程图
**【必须】使用流程图展示核心功能流程：**
### 4.1 {核心流程名称}
```
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ F-001 │ ──▶ │ F-002 │ ──▶ │ F-003 │ ──▶ │ 完成 │
│ {功能} │ │ {功能} │ │ {功能} │ │ │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
│
▼ 异常
┌─────────┐
│ 错误处理 │
└─────────┘
```
## 5. 版本规划
| 版本 | 包含功能 | 功能ID | 目标 |
|------|----------|--------|------|
| MVP | {功能列表} | F-001, F-002 | {目标} |
| v1.1 | {功能列表} | F-003, F-004 | {目标} |
| v2.0 | {功能列表} | F-005+ | {目标} |
## 6. 接口契约预览
> 详细接口定义在 DevelopmentPlan 中，此处仅列出关键接口
| 功能 | 接口类型 | 简要说明 |
|------|----------|----------|
| F-001 | API | {说明} |
| F-002 | Event | {说明} |
```
## 4. 保存文档
将生成的 FeatureSummary 保存到 `doc/FeatureSummary.md`。
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
## 5. 输出摘要
向用户展示生成摘要：
- FeatureSummary 文件路径
- 功能模块数量
- 各优先级功能数量
- 建议的下一步操作（运行 `/rf` 评审）
---
## 可视化输出要求
FeatureSummary 作为「功能契约」文档，需要精确传达功能定义，**必须包含**：
| 章节 | 可视化形式 | 必要性 |
|------|------------|--------|
| 1.2 功能架构图 | 模块图（ASCII） | **必须** |
| 1.3 模块依赖关系 | 依赖图（ASCII） | **必须** |
| 3. 功能依赖矩阵 | 矩阵表格 | **必须** |
| 4. 功能流程图 | 流程图（ASCII） | **必须** |
## 注意事项
- FeatureSummary 是产品与开发的**桥梁**，语言要精确、无歧义
- 功能摘要必须完全来源于 PRD，不要臆造功能
- 每个功能必须有明确的**输入、输出、边界**
- 功能 ID 必须唯一（F-xxx 格式）
- 优先级必须与 PRD 一致
- 功能依赖关系必须明确，避免循环依赖
## 质量检查
生成 FeatureSummary 后，自查以下项目：
- [ ] 所有功能都有唯一 ID（F-xxx）
- [ ] 所有功能都有契约详情（输入/输出/边界）
- [ ] **功能架构图清晰展示模块结构**
- [ ] **模块依赖图清晰展示依赖关系**
- [ ] **功能依赖矩阵完整**
- [ ] **核心流程有流程图**
- [ ] 优先级与 PRD 一致
- [ ] 无遗漏 PRD 中的功能

318
.claude/skills/wp/SKILL.md Normal file
View File

@ -0,0 +1,318 @@
---
name: wp
description: 从 RequirementsDoc.md 生成 PRD.md，将需求文档转化为结构化的产品需求文档。
---
# Write PRD
> **文档定位**：PRD 是「价值主张」文档，使用业务语言描述产品要解决什么问题、为谁创造什么价值。面向产品、业务、管理层沟通。
当用户调用 `/wp` 时，执行以下步骤：
## 1. 读取源文档
读取 `doc/RequirementsDoc.md` 文件。
如果文件不存在，提示用户：
> RequirementsDoc.md 不存在，请先创建需求文档。
如果已存在 `doc/PRD.md`，同时读取作为参考（保持风格一致）。
## 2. 分析需求文档
从 RequirementsDoc 中提取以下信息：
### 2.1 产品定位
- 产品名称
- 目标用户
- 核心价值主张
- 竞品对比（如有）
### 2.2 功能需求
- 功能模块划分
- 各模块详细需求
- 功能优先级（P0/P1/P2）
### 2.3 非功能需求
- 性能要求
- 安全要求
- 兼容性要求
- 可用性要求
### 2.4 约束条件
- 技术约束
- 业务约束
- 时间约束
## 3. 生成 PRD
按以下结构生成 PRD 文档：
```markdown
# {产品名称} - 产品需求文档 (PRD)
## 文档信息
| 项目 | 内容 |
|------|------|
| 版本 | v1.0 |
| 创建日期 | {YYYY-MM-DD} |
| 状态 | 草稿 |
## 1. 产品概述
### 1.1 产品背景
{从 RequirementsDoc 提取，说明产品解决的问题和市场机会}
### 1.2 产品定位
{目标用户、核心价值、差异化优势}
### 1.3 产品目标
| 目标 | 指标 | 衡量方式 |
|------|------|----------|
| {业务目标} | {量化指标} | {如何衡量} |
## 2. 用户故事
PRD 以用户故事为核心驱动，所有功能需求都应对应到具体的用户故事。
### 2.1 用户角色定义
| 角色 | 描述 | 核心目标 | 痛点 |
|------|------|----------|------|
| {角色1} | {角色描述} | {核心目标} | {当前痛点} |
### 2.2 用户故事列表
按优先级排列的用户故事：
#### P0 - 核心故事
| ID | 用户故事 | 验收标准 |
|----|----------|----------|
| US-001 | 作为{角色}，我想要{功能}，以便{价值} | {验收标准} |
#### P1 - 重要故事
| ID | 用户故事 | 验收标准 |
|----|----------|----------|
| US-xxx | 作为{角色}，我想要{功能}，以便{价值} | {验收标准} |
#### P2 - 次要故事
| ID | 用户故事 | 验收标准 |
|----|----------|----------|
| US-xxx | 作为{角色}，我想要{功能}，以便{价值} | {验收标准} |
### 2.3 用户旅程
**【必须】使用流程图展示核心用户旅程：**
```
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 触发点 │ ──▶ │ 关键步骤 │ ──▶ │ 目标达成 │
│ {描述} │ │ {描述} │ │ {描述} │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
▼ ▼ ▼
{用户感受} {用户感受} {用户感受}
```
{描述用户完成核心任务的完整流程，从触发点到目标达成}
## 3. 功能需求
> 功能需求与用户故事的对应关系
### 3.1 功能架构
**【必须】使用树状图或模块图展示功能架构：**
```
{产品名称}
├── {模块A}
│ ├── {功能A1}
│ └── {功能A2}
├── {模块B}
│ ├── {功能B1}
│ └── {功能B2}
└── {模块C}
└── {功能C1}
```
### 3.2 功能详情
#### 3.2.1 {模块名称}
| 功能点 | 描述 | 关联用户故事 | 优先级 | 验收标准 |
|--------|------|--------------|--------|----------|
| {功能1} | {描述} | US-001 | P0 | {标准} |
{重复以上结构覆盖所有模块}
## 4. 非功能需求
### 4.1 性能需求
| 指标 | 要求 | 说明 |
|------|------|------|
| {响应时间} | {要求} | {场景说明} |
### 4.2 安全需求
{数据安全、访问控制、合规要求}
### 4.3 兼容性需求
| 平台/环境 | 支持版本 |
|-----------|----------|
| {平台} | {版本} |
### 4.4 可用性需求
{SLA、故障恢复、监控告警}
## 5. 数据需求
### 5.1 数据模型
**【建议】使用 ER 图或表格展示核心实体关系：**
```
┌──────────┐ ┌──────────┐
│ 实体A │ 1───n │ 实体B │
├──────────┤ ├──────────┤
│ 字段1 │ │ 字段1 │
│ 字段2 │ │ 字段2 │
└──────────┘ └──────────┘
```
### 5.2 数据规范
| 字段 | 类型 | 说明 | 校验规则 |
|------|------|------|----------|
| {字段名} | {类型} | {说明} | {规则} |
## 6. 接口需求
### 6.1 外部接口
| 接口 | 用途 | 提供方 |
|------|------|--------|
| {接口名} | {用途} | {第三方} |
### 6.2 内部接口
{模块间接口规范}
## 7. 约束与依赖
### 7.1 技术约束
| 约束 | 说明 | 影响 |
|------|------|------|
| {约束} | {说明} | {影响范围} |
### 7.2 业务约束
{法规、政策、合同限制}
### 7.3 外部依赖
{第三方服务、团队依赖}
## 8. 里程碑规划
**【建议】使用时间线展示里程碑：**
```
Phase 1 Phase 2 Phase 3
│ │ │
▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐
│ MVP │ ────▶ │ v1.1 │ ────▶ │ v2.0 │
└──────┘ └──────┘ └──────┘
{日期} {日期} {日期}
```
| 阶段 | 目标 | 交付物 |
|------|------|--------|
| {阶段1} | {目标} | {交付物} |
## 9. 风险评估
| 风险 | 可能性 | 影响 | 应对措施 |
|------|--------|------|----------|
| {风险1} | 高/中/低 | 高/中/低 | {措施} |
## 附录
### A. 术语表
| 术语 | 定义 |
|------|------|
| {术语} | {定义} |
### B. 参考文档
- RequirementsDoc.md
```
## 4. 保存文档
将生成的 PRD 保存到 `doc/PRD.md`。
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
## 5. 输出摘要
向用户展示生成摘要：
- PRD 文件路径
- 包含的功能模块数量
- 主要章节概览
- 建议的下一步操作（运行 `/rp` 评审）
---
## 可视化输出要求
PRD 作为「价值主张」文档，需要便于业务沟通理解，**必须包含**：
| 章节 | 可视化形式 | 必要性 |
|------|------------|--------|
| 2.3 用户旅程 | 流程图（ASCII） | **必须** |
| 3.1 功能架构 | 树状图/模块图 | **必须** |
| 5.1 数据模型 | ER 图 | 建议 |
| 8. 里程碑规划 | 时间线 | 建议 |
## 注意事项
- PRD 使用**业务语言**，避免过多技术术语
- PRD 内容必须完全来源于 RequirementsDoc，不要臆造需求
- 如果 RequirementsDoc 信息不完整，在对应章节标注"待补充"
- 保持语言风格与现有文档一致
- 优先级标注遵循 P0 > P1 > P2 规则
- 验收标准要具体可测试
## 质量检查
生成 PRD 后，自查以下项目：
- [ ] 所有用户故事都有唯一 ID（US-xxx）
- [ ] 所有用户故事都符合格式：作为{角色}，我想要{功能}，以便{价值}
- [ ] 所有功能点都关联到用户故事
- [ ] 所有功能点都有明确的优先级
- [ ] 所有功能点都有验收标准
- [ ] **用户旅程有流程图**
- [ ] **功能架构有模块图**
- [ ] 非功能需求有量化指标
- [ ] 无遗漏 RequirementsDoc 中的重要需求
- [ ] 文档结构完整，无空章节（或标注"待补充"）

128
.claude/skills/wt/SKILL.md Normal file
View File

@ -0,0 +1,128 @@
---
name: wt
description: 从上游文档生成 tasks.md，创建可直接执行的任务列表。
---
# Write Tasks
当用户调用 `/wt` 时，执行以下步骤：
## 1. 读取源文档
读取以下文件：
1. `doc/RequirementsDoc.md` - 必须存在
2. `doc/PRD.md` - 必须存在
3. `doc/FeatureSummary.md` - 必须存在
4. `doc/DevelopmentPlan.md` - 必须存在
5. `doc/UIDesign.md` - 必须存在
如果文件不存在，提示用户：
> 缺少上游文档，请确保所有上游文档存在。
如果已存在 `doc/tasks.md`，同时读取作为参考（保持风格一致）。
## 2. 分析任务需求
从上游文档中提取以下信息：
### 2.1 开发任务
- 从 DevelopmentPlan 获取开发阶段和任务
- 从 UIDesign 获取页面实现任务
### 2.2 任务依赖
- 分析任务间的依赖关系
- 确定任务执行顺序
### 2.3 验收标准
- 从 PRD 获取功能验收标准
- 转化为任务级别的完成标准
## 3. 生成 Tasks
按以下结构生成文档：
```markdown
# {产品名称} - 任务列表
## 文档信息
| 项目 | 内容 |
|------|------|
| 版本 | v1.0 |
| 创建日期 | {YYYY-MM-DD} |
| 来源文档 | UIDesign.md, DevelopmentPlan.md |
## 1. 任务总览
| 统计项 | 数量 |
|--------|------|
| 总任务数 | X |
| P0 任务 | X |
| P1 任务 | X |
| P2 任务 | X |
## 2. Phase 1 任务
### 2.1 {模块/功能名}
| ID | 任务 | 描述 | 优先级 | 依赖 | 验收标准 |
|----|------|------|--------|------|----------|
| T-001 | {任务名} | {描述} | P0 | - | {标准} |
| T-002 | {任务名} | {描述} | P0 | T-001 | {标准} |
{重复以上结构覆盖所有模块}
## 3. Phase 2 任务
{同上结构}
## 4. Phase N 任务
{同上结构}
## 5. 任务依赖图
```
T-001 (基础设施)
├── T-002 (功能A)
│ └── T-005 (功能A优化)
└── T-003 (功能B)
└── T-004 (功能B扩展)
```
## 6. 执行检查清单
- [ ] T-001: {任务名}
- [ ] T-002: {任务名}
{所有任务的检查清单}
```
## 4. 保存文档
将生成的 tasks 保存到 `doc/tasks.md`。
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
## 5. 输出摘要
向用户展示生成摘要：
- tasks 文件路径
- 任务总数
- 各阶段任务分布
- 建议的下一步操作（运行 `/rt` 评审）
---
## 注意事项
- 任务必须覆盖 DevelopmentPlan 和 UIDesign 所有内容
- 任务 ID 必须唯一（T-001, T-002...）
- 每个任务必须有明确的验收标准
- 任务粒度要适中，可在合理时间内完成
- 依赖关系要明确，避免循环依赖
- 任务应可直接执行，无歧义

352
.claude/skills/wu/SKILL.md Normal file
View File

@ -0,0 +1,352 @@
---
name: wu
description: 从上游文档生成 UIDesign.md，覆盖所有用户界面设计。
---
# Write UIDesign
> **文档定位**：UIDesign 是「界面蓝图」文档，用 ASCII 原型图精确传达页面布局、组件结构、交互流程，是前端开发的直接参考。
当用户调用 `/wu` 时，执行以下步骤：
## 1. 读取源文档
读取以下文件：
1. `doc/RequirementsDoc.md` - 必须存在
2. `doc/PRD.md` - 必须存在
3. `doc/FeatureSummary.md` - 必须存在
4. `doc/DevelopmentPlan.md` - 必须存在
如果文件不存在，提示用户：
> 缺少上游文档，请确保所有上游文档存在。
如果已存在 `doc/UIDesign.md`，同时读取作为参考（保持风格一致）。
## 2. 分析 UI 需求
从上游文档中提取以下信息：
### 2.1 页面需求
- 从 PRD 用户旅程分析所需页面
- 从 FeatureSummary 获取功能对应的界面
- 从 DevelopmentPlan 获取技术实现约束
### 2.2 用户流程
- 主要用户旅程
- 页面跳转关系
- 交互流程
## 3. 生成 UIDesign
按以下结构生成文档：
```markdown
# {产品名称} - UI 设计文档
## 文档信息
| 项目 | 内容 |
|------|------|
| 版本 | v1.0 |
| 创建日期 | {YYYY-MM-DD} |
| 来源文档 | DevelopmentPlan.md |
## 1. 设计概述
### 1.1 设计原则
{UI 设计原则和规范}
### 1.2 页面总览
| 页面ID | 页面名称 | 描述 | 对应功能 | 优先级 |
|--------|----------|------|----------|--------|
| P-001 | {页面名} | {描述} | F-001 | P0 |
### 1.3 页面导航图
**【必须】使用导航图展示页面跳转关系：**
```
┌─────────────┐
│ 首页 │
│ P-001 │
└──────┬──────┘
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 功能A页 │ │ 功能B页 │ │ 设置页 │
│ P-002 │ │ P-003 │ │ P-004 │
└──────┬──────┘ └─────────────┘ └─────────────┘
│
▼
┌─────────────┐
│ 详情页 │
│ P-005 │
└─────────────┘
```
## 2. 页面设计
### 2.1 P-001: {页面名称}
**页面信息**
| 属性 | 值 |
|------|-----|
| 页面ID | P-001 |
| 对应功能 | F-001, F-002 |
| 入口 | {从哪些页面可进入} |
| 出口 | {可跳转到哪些页面} |
**【必须】页面布局 - ASCII 原型图**
```
┌────────────────────────────────────────────────────────┐
│ ┌─────────────────────────────────────────────────┐ │
│ │ Header │ │
│ │ [Logo] [Nav Item] [Nav Item] [用户]│ │
│ └─────────────────────────────────────────────────┘ │
├────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────┐ ┌───────────────────────────┐ │
│ │ │ │ │ │
│ │ Sidebar │ │ Main Content │ │
│ │ │ │ │ │
│ │ • Menu Item 1 │ │ ┌─────────────────────┐ │ │
│ │ • Menu Item 2 │ │ │ Card 1 │ │ │
│ │ • Menu Item 3 │ │ │ [Title] │ │ │
│ │ │ │ │ [Description...] │ │ │
│ │ │ │ │ [Action Button] │ │ │
│ │ │ │ └─────────────────────┘ │ │
│ │ │ │ │ │
│ │ │ │ ┌─────────────────────┐ │ │
│ │ │ │ │ Card 2 │ │ │
│ │ │ │ └─────────────────────┘ │ │
│ │ │ │ │ │
│ └──────────────────┘ └───────────────────────────┘ │
│ │
├────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────┐ │
│ │ Footer │ │
│ └─────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘
```
**组件清单**
| 组件ID | 组件名称 | 类型 | 说明 | 交互 |
|--------|----------|------|------|------|
| C-001 | Header | 导航栏 | 顶部固定 | 点击 Logo 回首页 |
| C-002 | Sidebar | 侧边栏 | 左侧固定 | 点击菜单切换内容 |
| C-003 | Card | 卡片 | 内容展示 | 点击进入详情 |
**交互说明**
| 触发 | 动作 | 结果 |
|------|------|------|
| 点击 Card | 跳转 | 进入详情页 P-005 |
| 点击 Menu Item | 切换 | 更新 Main Content |
**页面状态**
| 状态 | 说明 | 展示 |
|------|------|------|
| 默认 | 正常加载完成 | 显示数据列表 |
| 加载中 | 数据请求中 | 骨架屏/Loading |
| 空状态 | 无数据 | 空状态插图+引导文案 |
| 错误 | 请求失败 | 错误提示+重试按钮 |
**空状态原型**
```
┌─────────────────────────────────────┐
│ │
│ ┌─────────────┐ │
│ │ (空图标) │ │
│ └─────────────┘ │
│ │
│ 暂无数据 │
│ │
│ [去添加数据] │
│ │
└─────────────────────────────────────┘
```
{重复以上结构覆盖所有页面}
## 3. 用户流程
### 3.1 {流程名称}
**【必须】使用流程图展示用户操作流程：**
```
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Step 1 │ ──▶ │ Step 2 │ ──▶ │ Step 3 │ ──▶ │ 完成 │
│ {操作} │ │ {操作} │ │ {操作} │ │ │
│ P-001 │ │ P-002 │ │ P-003 │ │ P-004 │
└─────────┘ └────┬────┘ └─────────┘ └─────────┘
│
▼ 取消
┌─────────┐
│ 返回 │
│ P-001 │
└─────────┘
```
**流程步骤**
| 步骤 | 页面 | 用户操作 | 系统响应 |
|------|------|----------|----------|
| 1 | P-001 | {操作} | {响应} |
| 2 | P-002 | {操作} | {响应} |
## 4. 组件规范
### 4.1 基础组件
**Button 按钮**
```
主按钮: ┌──────────────┐
│ 确认提交 │ (填充色背景)
└──────────────┘
次按钮: ┌──────────────┐
│ 取消 │ (边框样式)
└──────────────┘
禁用态: ┌──────────────┐
│ 不可点击 │ (灰色)
└──────────────┘
```
**Input 输入框**
```
默认态: ┌────────────────────────┐
│ 请输入... │
└────────────────────────┘
聚焦态: ┌────────────────────────┐
│ 输入内容 │ (高亮边框)
└────────────────────────┘
错误态: ┌────────────────────────┐
│ 错误输入 │ (红色边框)
└────────────────────────┘
⚠ 错误提示信息
```
### 4.2 业务组件
{项目特有的业务组件}
## 5. 设计规范
### 5.1 色彩规范
| 用途 | 色值 | 示例 |
|------|------|------|
| 主色 | #1890FF | 主按钮、链接 |
| 成功 | #52C41A | 成功提示 |
| 警告 | #FAAD14 | 警告提示 |
| 错误 | #FF4D4F | 错误提示 |
| 文字主色 | #262626 | 标题 |
| 文字次色 | #8C8C8C | 描述 |
### 5.2 字体规范
| 用途 | 字号 | 字重 |
|------|------|------|
| 大标题 | 24px | Bold |
| 标题 | 18px | Medium |
| 正文 | 14px | Regular |
| 辅助文字 | 12px | Regular |
### 5.3 间距规范
| 间距 | 值 | 用途 |
|------|-----|------|
| xs | 4px | 紧凑间距 |
| sm | 8px | 小间距 |
| md | 16px | 标准间距 |
| lg | 24px | 大间距 |
| xl | 32px | 特大间距 |
### 5.4 响应式断点
| 断点 | 宽度 | 布局说明 |
|------|------|----------|
| Mobile | < 768px | 单栏布局 |
| Tablet | 768px - 1024px | 双栏布局 |
| Desktop | > 1024px | 多栏布局 |
```
## 4. 保存文档
将生成的 UIDesign 保存到 `doc/UIDesign.md`。
如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。
## 5. 输出摘要
向用户展示生成摘要：
- UIDesign 文件路径
- 页面数量
- 用户流程数量
- 建议的下一步操作（运行 `/ru` 评审）
---
## 可视化输出要求
UIDesign 作为「界面蓝图」文档，**必须大量使用 ASCII 原型图**：
| 章节 | 可视化形式 | 必要性 |
|------|------------|--------|
| 1.3 页面导航图 | 导航关系图（ASCII） | **必须** |
| 2.x 页面布局 | **ASCII 原型图** | **必须（每页）** |
| 2.x 空状态 | ASCII 原型图 | 建议 |
| 3.x 用户流程 | 流程图（ASCII） | **必须** |
| 4.x 组件规范 | 组件示意图 | **必须** |
**ASCII 原型图要求**：
- 每个页面**必须**有完整的布局原型图
- 原型图要体现：页面结构、组件位置、内容区域
- 使用 `┌ ┐ └ ┘ ─ │ ├ ┤ ┬ ┴ ┼` 等字符绘制边框
- 使用 `[ ]` 表示按钮
- 使用 `▼ ▶ ◀ ▲` 表示方向/展开
- 关键交互点要标注
## 注意事项
- UI 设计必须覆盖 DevelopmentPlan 所有功能模块
- **每个页面必须有 ASCII 原型图**
- 页面设计要考虑各种状态（默认、加载、空、错误）
- 交互说明要清晰具体
- 设计规范要统一一致
- 页面 ID 格式：P-xxx
- 组件 ID 格式：C-xxx
## 质量检查
生成 UIDesign 后，自查以下项目：
- [ ] 覆盖 DevelopmentPlan 所有功能模块
- [ ] **页面导航图清晰展示页面关系**
- [ ] **每个页面都有 ASCII 原型图**
- [ ] **原型图展示了完整的页面结构**
- [ ] **用户流程有流程图**
- [ ] 每个页面都有状态说明
- [ ] 组件清单完整
- [ ] 交互说明清晰
- [ ] 设计规范统一

15
.gitignore vendored Normal file
View File

@ -0,0 +1,15 @@
# 文档目录（各项目自己生成）
doc/
# 其他开发文件
write-skills/
.codex/
# macOS
.DS_Store
# IDE
.idea/
.vscode/
*.swp
*.swo

169
README.md Normal file
View File

@ -0,0 +1,169 @@
# Spec Coding Skills
一套 Claude Code Skills，支持产品文档工作流的完整生命周期管理。
## 功能概览
```
RequirementsDoc ──▶ PRD ──▶ FeatureSummary ──▶ DevelopmentPlan ──▶ UIDesign ──▶ tasks
│ │ │ │ │ │
/rr /rp /rf /rd /ru /rt ← Review
/mr /mp /mf /md /mu /mt ← Modify
/wp /wf /wd /wu /wt ← Write
```
### Skills 列表
| 类型 | 命令 | 描述 |
|------|------|------|
| **Review** | `/rr` | 评审 RequirementsDoc.md |
| | `/rp` | 评审 PRD.md |
| | `/rf` | 评审 FeatureSummary.md |
| | `/rd` | 评审 DevelopmentPlan.md |
| | `/ru` | 评审 UIDesign.md |
| | `/rt` | 评审 tasks.md |
| **Write** | `/wp` | 从 RequirementsDoc 生成 PRD |
| | `/wf` | 从 PRD 生成 FeatureSummary |
| | `/wd` | 从 FeatureSummary 生成 DevelopmentPlan |
| | `/wu` | 从 DevelopmentPlan 生成 UIDesign |
| | `/wt` | 从 DevelopmentPlan 生成 tasks |
| **Modify** | `/mr` | 增量修改 RequirementsDoc |
| | `/mp` | 增量修改 PRD（自动读取评审报告） |
| | `/mf` | 增量修改 FeatureSummary |
| | `/md` | 增量修改 DevelopmentPlan |
| | `/mu` | 增量修改 UIDesign |
| | `/mt` | 增量修改 tasks |
| **辅助** | `/iter` | 迭代变更入口（Bug/功能/重构） |
| | `/up` | 文档升级迁移 |
## 安装方式
### 方式 1：Git Submodule（推荐）
```bash
# 在你的项目根目录执行
git submodule add https://git.internal.intelligrow.cn/intelligrow/spec-coding-skills.git .spec-coding-skills
# 创建符号链接
mkdir -p .claude
ln -s ../.spec-coding-skills/.claude/skills .claude/skills
# 提交变更
git add .gitmodules .spec-coding-skills .claude/skills
git commit -m "Add spec-coding-skills as submodule"
```
### 方式 2：直接复制
```bash
# 克隆仓库
git clone https://git.internal.intelligrow.cn/intelligrow/spec-coding-skills.git /tmp/spec-coding-skills
# 复制 skills 到你的项目
mkdir -p .claude
cp -r /tmp/spec-coding-skills/.claude/skills .claude/
# 清理
rm -rf /tmp/spec-coding-skills
```
## 更新 Skills
### Submodule 方式
```bash
# 更新到最新版本
git submodule update --remote .spec-coding-skills
git add .spec-coding-skills
git commit -m "Update spec-coding-skills"
```
### 直接复制方式
重新执行复制命令覆盖即可。
## 使用示例
### 0-1 阶段：从需求到开发
```bash
# 1. 创建需求文档
# 手动编写 doc/RequirementsDoc.md
# 2. 生成 PRD
/wp
# 3. 评审 PRD
/rp
# 4. 根据评审修改 PRD
/mp
# 5. 生成后续文档
/wf # → FeatureSummary
/wd # → DevelopmentPlan
/wu # → UIDesign
/wt # → tasks
```
### 1-100 阶段：持续迭代
```bash
# 发现问题或需要新功能
/iter
# 按提示描述问题，AI 会：
# 1. 调研分析
# 2. 向你澄清确认
# 3. 更新 PRD 和 tasks
```
## 文档定位
| 文档 | 定位 | 受众 |
|------|------|------|
| PRD | 「价值主张」- 业务语言描述产品价值 | 产品、业务、管理层 |
| FeatureSummary | 「功能契约」- 精确定义功能边界 | 产品与开发的桥梁 |
| DevelopmentPlan | 「执行蓝图」- 技术方案和排期 | 开发团队 |
| UIDesign | 「界面蓝图」- ASCII 原型图 | 前端开发 |
| tasks | 「任务清单」- 可执行的开发任务 | 开发执行 |
## 目录结构
```
your-project/
├── .claude/
│ └── skills/ # ← Skills 安装位置
│ ├── rr/
│ ├── rp/
│ ├── ...
│ └── iter/
├── doc/ # ← 文档输出位置
│ ├── RequirementsDoc.md
│ ├── PRD.md
│ ├── FeatureSummary.md
│ ├── DevelopmentPlan.md
│ ├── UIDesign.md
│ └── tasks.md
└── ...
```
## 标记规范
Skills 使用注释标记追踪文档变更：
```markdown
<!-- NEW START -->
新增内容...
<!-- NEW END -->
<!-- MODIFIED: 原内容为 "xxx" -->
修改后的内容
<!-- ITER: 2024-01-23 - 修复登录验证漏洞 -->
迭代变更内容
```
## License
MIT