feat: Add 19 Claude Code skills for document workflow
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
commit
d372fd82f9
209
.claude/skills/iter/SKILL.md
Normal file
209
.claude/skills/iter/SKILL.md
Normal 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
112
.claude/skills/md/SKILL.md
Normal 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
111
.claude/skills/mf/SKILL.md
Normal 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
144
.claude/skills/mp/SKILL.md
Normal 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
95
.claude/skills/mr/SKILL.md
Normal 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
132
.claude/skills/mt/SKILL.md
Normal 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
114
.claude/skills/mu/SKILL.md
Normal 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
101
.claude/skills/rd/SKILL.md
Normal 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
96
.claude/skills/rf/SKILL.md
Normal 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
177
.claude/skills/rp/SKILL.md
Normal 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
111
.claude/skills/rr/SKILL.md
Normal 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
115
.claude/skills/rt/SKILL.md
Normal 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
105
.claude/skills/ru/SKILL.md
Normal 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
78
.claude/skills/up/SKILL.md
Normal 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
323
.claude/skills/wd/SKILL.md
Normal 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
234
.claude/skills/wf/SKILL.md
Normal 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
318
.claude/skills/wp/SKILL.md
Normal 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
128
.claude/skills/wt/SKILL.md
Normal 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
352
.claude/skills/wu/SKILL.md
Normal 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
15
.gitignore
vendored
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
# 文档目录（各项目自己生成）
|
||||||
|
doc/
|
||||||
|
|
||||||
|
# 其他开发文件
|
||||||
|
write-skills/
|
||||||
|
.codex/
|
||||||
|
|
||||||
|
# macOS
|
||||||
|
.DS_Store
|
||||||
|
|
||||||
|
# IDE
|
||||||
|
.idea/
|
||||||
|
.vscode/
|
||||||
|
*.swp
|
||||||
|
*.swo
|
||||||
169
README.md
Normal file
169
README.md
Normal 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
|
||||||
Loading…
x
Reference in New Issue
Block a user