From d372fd82f9d3735b6db2cfbe0149434ddf513c75 Mon Sep 17 00:00:00 2001 From: zfc Date: Fri, 23 Jan 2026 11:27:09 +0800 Subject: [PATCH] feat: Add 19 Claude Code skills for document workflow MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- .claude/skills/iter/SKILL.md | 209 +++++++++++++++++++++ .claude/skills/md/SKILL.md | 112 +++++++++++ .claude/skills/mf/SKILL.md | 111 +++++++++++ .claude/skills/mp/SKILL.md | 144 ++++++++++++++ .claude/skills/mr/SKILL.md | 95 ++++++++++ .claude/skills/mt/SKILL.md | 132 +++++++++++++ .claude/skills/mu/SKILL.md | 114 ++++++++++++ .claude/skills/rd/SKILL.md | 101 ++++++++++ .claude/skills/rf/SKILL.md | 96 ++++++++++ .claude/skills/rp/SKILL.md | 177 ++++++++++++++++++ .claude/skills/rr/SKILL.md | 111 +++++++++++ .claude/skills/rt/SKILL.md | 115 ++++++++++++ .claude/skills/ru/SKILL.md | 105 +++++++++++ .claude/skills/up/SKILL.md | 78 ++++++++ .claude/skills/wd/SKILL.md | 323 ++++++++++++++++++++++++++++++++ .claude/skills/wf/SKILL.md | 234 +++++++++++++++++++++++ .claude/skills/wp/SKILL.md | 318 +++++++++++++++++++++++++++++++ .claude/skills/wt/SKILL.md | 128 +++++++++++++ .claude/skills/wu/SKILL.md | 352 +++++++++++++++++++++++++++++++++++ .gitignore | 15 ++ README.md | 169 +++++++++++++++++ 21 files changed, 3239 insertions(+) create mode 100644 .claude/skills/iter/SKILL.md create mode 100644 .claude/skills/md/SKILL.md create mode 100644 .claude/skills/mf/SKILL.md create mode 100644 .claude/skills/mp/SKILL.md create mode 100644 .claude/skills/mr/SKILL.md create mode 100644 .claude/skills/mt/SKILL.md create mode 100644 .claude/skills/mu/SKILL.md create mode 100644 .claude/skills/rd/SKILL.md create mode 100644 .claude/skills/rf/SKILL.md create mode 100644 .claude/skills/rp/SKILL.md create mode 100644 .claude/skills/rr/SKILL.md create mode 100644 .claude/skills/rt/SKILL.md create mode 100644 .claude/skills/ru/SKILL.md create mode 100644 .claude/skills/up/SKILL.md create mode 100644 .claude/skills/wd/SKILL.md create mode 100644 .claude/skills/wf/SKILL.md create mode 100644 .claude/skills/wp/SKILL.md create mode 100644 .claude/skills/wt/SKILL.md create mode 100644 .claude/skills/wu/SKILL.md create mode 100644 .gitignore create mode 100644 README.md diff --git a/.claude/skills/iter/SKILL.md b/.claude/skills/iter/SKILL.md new file mode 100644 index 0000000..51db384 --- /dev/null +++ b/.claude/skills/iter/SKILL.md @@ -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 + + +新增内容... + +``` + +或修改现有内容： + +```markdown + + +修改后的内容 +``` + +**更新位置**： +- Bug 修复 → 更新对应功能的验收标准 +- 功能迭代 → 在 3.2 功能详情添加/修改功能点 +- 技术重构 → 在 4.x 非功能需求或 7.1 技术约束中说明 + +### 4.2 更新 tasks.md + +新增任务使用标记： + +```markdown + +| T-xxx | {任务名} | {描述} | {依赖} | {优先级} | {验收标准} | +``` + +**任务 ID 规则**： +- 查找现有最大 ID，递增分配 +- 格式：T-xxx（三位数字） + +### 4.3 标记规范 + +所有变更使用 `` 前缀，区分于 `/mp` `/mt` 的标记： + +- `` +- 便于追溯迭代历史 + +## 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` 等 | diff --git a/.claude/skills/md/SKILL.md b/.claude/skills/md/SKILL.md new file mode 100644 index 0000000..47303bd --- /dev/null +++ b/.claude/skills/md/SKILL.md @@ -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 + +新增内容... + +``` + +对于行内新增： + +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +```markdown + +修改后的内容 +``` + +### 3.4 与 FeatureSummary 一致性 + +- 开发任务必须覆盖所有功能 +- 技术方案必须支撑功能需求 +- 阶段划分必须合理 + +## 4. 执行修改 + +| 修改类型 | 处理方式 | +|----------|----------| +| 新增开发任务 | 在对应阶段表格中添加行 | +| 修改技术方案 | 更新技术方案章节，添加 MODIFIED 标记 | +| 调整阶段划分 | 移动任务到新阶段，标记变更 | +| 新增风险项 | 在风险管理表格中添加行 | +| 修改里程碑 | 更新里程碑表格 | + +## 5. 保存并验证 + +1. 保存修改后的文档到 `doc/DevelopmentPlan.md` +2. 使用 git diff 展示变更内容 +3. 向用户确认修改是否符合预期 + +## 6. 输出摘要 + +向用户展示修改摘要： + +- 修改位置（章节/行号） +- 修改类型（新增/修改/删除） +- 修改内容概要 +- 与 FeatureSummary 的一致性确认 + +--- + +## 注意事项 + +- DevelopmentPlan 依赖于 FeatureSummary，修改时需确保与上游一致 +- 修改后，下游文档（UIDesign、tasks）可能需要同步更新 +- 技术方案修改需谨慎评估影响范围 +- 建议修改完成后运行 `/ru` 检查下游一致性 + +## 标记清理 + +用户确认修改无误后，可手动删除标记或保留作为变更历史参考。 diff --git a/.claude/skills/mf/SKILL.md b/.claude/skills/mf/SKILL.md new file mode 100644 index 0000000..fa10e2d --- /dev/null +++ b/.claude/skills/mf/SKILL.md @@ -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 + +新增内容... + +``` + +对于行内新增： + +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +```markdown + +修改后的内容 +``` + +### 3.4 与 PRD 一致性 + +- 所有功能必须来源于 PRD +- 修改后的功能描述必须与 PRD 一致 +- 优先级必须与 PRD 匹配 + +## 4. 执行修改 + +| 修改类型 | 处理方式 | +|----------|----------| +| 新增功能 | 在对应模块表格中添加行 | +| 修改描述 | 更新功能描述，添加 MODIFIED 标记 | +| 修改优先级 | 更新优先级列 | +| 新增模块 | 在功能清单中添加新章节 | +| 删除功能 | 标记为删除而非直接移除 | + +## 5. 保存并验证 + +1. 保存修改后的文档到 `doc/FeatureSummary.md` +2. 使用 git diff 展示变更内容 +3. 向用户确认修改是否符合预期 + +## 6. 输出摘要 + +向用户展示修改摘要： + +- 修改位置（章节/行号） +- 修改类型（新增/修改/删除） +- 修改内容概要 +- 与 PRD 的一致性确认 + +--- + +## 注意事项 + +- FeatureSummary 依赖于 PRD，修改时需确保与上游一致 +- 修改后，下游文档（DevelopmentPlan 等）可能需要同步更新 +- 建议修改完成后运行 `/rd` 检查下游一致性 + +## 标记清理 + +用户确认修改无误后，可手动删除标记或保留作为变更历史参考。 diff --git a/.claude/skills/mp/SKILL.md b/.claude/skills/mp/SKILL.md new file mode 100644 index 0000000..5fdeb3f --- /dev/null +++ b/.claude/skills/mp/SKILL.md @@ -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 + +新增内容... + +``` + +对于行内新增，使用： +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +对于修改的内容，保留原文作为注释： + +```markdown + +修改后的内容 +``` + +### 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` 检查下游文档一致性 + +## 标记清理 + +当用户确认修改无误后，可手动删除 `` 和 `` 标记，或保留作为变更历史参考。 + +通过 git 可追溯完整修改历史。 + +## 质量检查 + +修改 PRD 后，自查以下项目： + +- [ ] 修改内容与 RequirementsDoc 一致 +- [ ] 新增用户故事有唯一 ID +- [ ] 新增功能点关联到用户故事 +- [ ] 新增功能点有明确优先级和验收标准 +- [ ] 标记格式正确（`` / ``） +- [ ] 文档结构完整，格式一致 diff --git a/.claude/skills/mr/SKILL.md b/.claude/skills/mr/SKILL.md new file mode 100644 index 0000000..8dd9ad8 --- /dev/null +++ b/.claude/skills/mr/SKILL.md @@ -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 + +新增内容... + +``` + +对于行内新增，使用： +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +对于修改的内容，保留原文作为注释： + +```markdown + +修改后的内容 +``` + +## 4. 执行修改 + +按照用户指令修改文档： + +1. 定位到需要修改的位置 +2. 执行增量修改 +3. 添加相应的标记 +4. 保持文档格式一致性 + +## 5. 保存并验证 + +1. 保存修改后的文档到 `doc/RequirementsDoc.md` +2. 使用 git diff 展示变更内容 +3. 向用户确认修改是否符合预期 + +## 6. 输出摘要 + +向用户展示修改摘要： +- 修改位置（章节/行号） +- 修改类型（新增/修改/删除） +- 修改内容概要 + +--- + +## 注意事项 + +- RequirementsDoc 是文档链源头，修改会影响所有下游文档 +- 修改前确认用户意图，避免误改 +- 保持现有文档风格（标题层级、表格格式、列表样式） +- 重大修改建议先运行 `/rr` 评审确认影响范围 +- 修改完成后，建议用户检查下游文档是否需要同步更新 + +## 标记清理 + +当用户确认修改无误后，可手动删除 `` 和 `` 标记，或保留作为变更历史参考。 + +通过 git 可追溯完整修改历史。 diff --git a/.claude/skills/mt/SKILL.md b/.claude/skills/mt/SKILL.md new file mode 100644 index 0000000..670c00a --- /dev/null +++ b/.claude/skills/mt/SKILL.md @@ -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 + +新增内容... + +``` + +对于行内新增： + +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +```markdown + +修改后的内容 +``` + +### 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 唯一且格式正确 +- [ ] 无循环依赖 +- [ ] 验收标准明确 +- [ ] 覆盖所有上游功能 +- [ ] 标记格式正确 diff --git a/.claude/skills/mu/SKILL.md b/.claude/skills/mu/SKILL.md new file mode 100644 index 0000000..e0d6061 --- /dev/null +++ b/.claude/skills/mu/SKILL.md @@ -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 + +新增内容... + +``` + +对于行内新增： + +```markdown +原有内容 新增内容 +``` + +### 3.3 修改内容标记 + +```markdown + +修改后的内容 +``` + +### 3.4 与 DevelopmentPlan 一致性 + +- 页面设计必须覆盖所有功能模块 +- 交互流程必须支撑功能需求 +- 设计规范必须统一 + +## 4. 执行修改 + +| 修改类型 | 处理方式 | +|----------|----------| +| 新增页面 | 在页面设计章节添加新子章节 | +| 修改布局 | 更新布局描述，添加 MODIFIED 标记 | +| 修改组件 | 更新组件表格 | +| 修改交互 | 更新交互说明 | +| 新增状态 | 在状态列表中添加项目 | +| 修改设计规范 | 更新设计规范章节 | + +## 5. 保存并验证 + +1. 保存修改后的文档到 `doc/UIDesign.md` +2. 使用 git diff 展示变更内容 +3. 向用户确认修改是否符合预期 + +## 6. 输出摘要 + +向用户展示修改摘要： + +- 修改位置（章节/行号） +- 修改类型（新增/修改/删除） +- 修改内容概要 +- 与 DevelopmentPlan 的一致性确认 + +--- + +## 注意事项 + +- UIDesign 依赖于 DevelopmentPlan，修改时需确保与上游一致 +- 修改后，下游文档（tasks）可能需要同步更新 +- 页面修改需考虑对用户流程的影响 +- 设计规范修改需检查所有页面的一致性 +- 建议修改完成后运行 `/rt` 检查下游一致性 + +## 标记清理 + +用户确认修改无误后，可手动删除标记或保留作为变更历史参考。 diff --git a/.claude/skills/rd/SKILL.md b/.claude/skills/rd/SKILL.md new file mode 100644 index 0000000..665117c --- /dev/null +++ b/.claude/skills/rd/SKILL.md @@ -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` 修改 diff --git a/.claude/skills/rf/SKILL.md b/.claude/skills/rf/SKILL.md new file mode 100644 index 0000000..ad3e464 --- /dev/null +++ b/.claude/skills/rf/SKILL.md @@ -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` 修改 diff --git a/.claude/skills/rp/SKILL.md b/.claude/skills/rp/SKILL.md new file mode 100644 index 0000000..befe913 --- /dev/null +++ b/.claude/skills/rp/SKILL.md @@ -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 的优先级划分不一致 diff --git a/.claude/skills/rr/SKILL.md b/.claude/skills/rr/SKILL.md new file mode 100644 index 0000000..7967a9b --- /dev/null +++ b/.claude/skills/rr/SKILL.md @@ -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. 输出摘要 + +向用户展示评审摘要： +- 发现的问题数量（按严重程度分类） +- 评审结论 +- 报告文件路径 + +--- + +## 注意事项 + +- 评审时保持客观，聚焦于文档质量而非业务判断 +- 问题描述要具体，给出明确的位置引用 +- 建议要可操作，避免模糊表述 +- 不要修改原文档，只输出评审报告 diff --git a/.claude/skills/rt/SKILL.md b/.claude/skills/rt/SKILL.md new file mode 100644 index 0000000..7db4e44 --- /dev/null +++ b/.claude/skills/rt/SKILL.md @@ -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` 修改 diff --git a/.claude/skills/ru/SKILL.md b/.claude/skills/ru/SKILL.md new file mode 100644 index 0000000..8fbc125 --- /dev/null +++ b/.claude/skills/ru/SKILL.md @@ -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` 修改 diff --git a/.claude/skills/up/SKILL.md b/.claude/skills/up/SKILL.md new file mode 100644 index 0000000..4b1ca96 --- /dev/null +++ b/.claude/skills/up/SKILL.md @@ -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 ` 时，执行以下步骤： + +## 1. 识别目标 Skill + +**如果用户提供了参数 `$ARGUMENTS`**： +- 直接使用指定的 skill 名称作为更新目标 + +**如果没有提供参数**： +分析当前对话历史，找出最近使用的 skill： +- 搜索对话中的 `` 标签，识别调用过的 skill +- 如果找到多个 skill，让用户确认要更新哪一个 +- 如果没有找到任何 skill 调用记录，提示用户先使用一个 skill + +## 2. 收集用户反馈 + +向用户询问以下问题（使用 AskUserQuestion 工具）： + +**问题 1：这次使用体验如何？** +- 很好，skill 完全满足需求 +- 基本满足，但有改进空间 +- 不太满意，需要较大调整 + +**问题 2：具体需要改进的方面？**（多选） +- 执行步骤不够清晰 +- 缺少某些功能 +- 输出格式需要调整 +- 提示词需要优化 +- 其他（用户自定义输入） + +## 3. 分析优化点 + +基于用户反馈和本次 skill 使用过程，分析以下方面： + +1. **执行流程**：哪些步骤可以简化或合并？ +2. **指令清晰度**：哪些指令描述不够明确？ +3. **遗漏功能**：有哪些场景没有覆盖到？ +4. **输出质量**：输出格式是否符合用户预期？ + +## 4. 定位 Skill 文件 + +按以下优先级搜索 skill 文件： +1. 项目级：`.claude/skills//SKILL.md` +2. 用户级：`~/.claude/skills//SKILL.md` + +## 5. 更新 Skill + +读取现有的 SKILL.md 文件内容，根据分析结果进行更新： + +- 保持 frontmatter 格式不变（除非需要修改 description） +- 优化执行步骤的描述 +- 添加缺失的功能说明 +- 改进提示词的表达方式 +- 添加必要的注意事项或边界情况处理 + +## 6. 确认更新 + +在更新前，向用户展示： +- 修改前后的对比（diff 格式） +- 说明每处修改的原因 + +用户确认后才执行实际的文件更新。 + +## 注意事项 + +- 如果 skill 文件不存在或路径无法确定，提示用户手动指定路径 +- 更新时保持 skill 的原有风格和结构 +- 重大修改需要用户明确确认 +- 保留原有的有效内容，只做增量优化 diff --git a/.claude/skills/wd/SKILL.md b/.claude/skills/wd/SKILL.md new file mode 100644 index 0000000..9343961 --- /dev/null +++ b/.claude/skills/wd/SKILL.md @@ -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 关联 diff --git a/.claude/skills/wf/SKILL.md b/.claude/skills/wf/SKILL.md new file mode 100644 index 0000000..c8ac3c4 --- /dev/null +++ b/.claude/skills/wf/SKILL.md @@ -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 中的功能 diff --git a/.claude/skills/wp/SKILL.md b/.claude/skills/wp/SKILL.md new file mode 100644 index 0000000..e647daf --- /dev/null +++ b/.claude/skills/wp/SKILL.md @@ -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 中的重要需求 +- [ ] 文档结构完整，无空章节（或标注"待补充"） diff --git a/.claude/skills/wt/SKILL.md b/.claude/skills/wt/SKILL.md new file mode 100644 index 0000000..253fe91 --- /dev/null +++ b/.claude/skills/wt/SKILL.md @@ -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...） +- 每个任务必须有明确的验收标准 +- 任务粒度要适中，可在合理时间内完成 +- 依赖关系要明确，避免循环依赖 +- 任务应可直接执行，无歧义 diff --git a/.claude/skills/wu/SKILL.md b/.claude/skills/wu/SKILL.md new file mode 100644 index 0000000..3b17b58 --- /dev/null +++ b/.claude/skills/wu/SKILL.md @@ -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 原型图** +- [ ] **原型图展示了完整的页面结构** +- [ ] **用户流程有流程图** +- [ ] 每个页面都有状态说明 +- [ ] 组件清单完整 +- [ ] 交互说明清晰 +- [ ] 设计规范统一 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..1323208 --- /dev/null +++ b/.gitignore @@ -0,0 +1,15 @@ +# 文档目录（各项目自己生成） +doc/ + +# 其他开发文件 +write-skills/ +.codex/ + +# macOS +.DS_Store + +# IDE +.idea/ +.vscode/ +*.swp +*.swo diff --git a/README.md b/README.md new file mode 100644 index 0000000..9abdbeb --- /dev/null +++ b/README.md @@ -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 + +新增内容... + + + +修改后的内容 + + +迭代变更内容 +``` + +## License + +MIT