sync: add d8d-inc-plan skill + format cleanups #41
@@ -338,31 +338,6 @@ Story 验证全部通过 ≠ 用户能正常使用系统。旅程模式弥补这
|
||||
```
|
||||
触发操作(如 sendCode)→ Toast 显示数据
|
||||
↓
|
||||
1. browser_snapshot 捕获 Toast → 记录数据(Toast 可能在几秒内消失)
|
||||
↓ (Toast 已消失)
|
||||
2. browser_console_messages(level="info") → 查找 console.log('[DEV] ...') 记录
|
||||
↓ (console 无记录 → FAIL #14)
|
||||
3. browser_network_requests(static=false) → 从 API 响应中提取数据
|
||||
↓ (network 未捕获)
|
||||
4. curl/API 直接查询回退:
|
||||
├── 验证码: 重新 POST /api/auth/send-code(注意频率限制)或查 Redis sms:${phone}
|
||||
└── 其他: 查询对应 API 获取最新数据
|
||||
```
|
||||
|
||||
**⛔ 如果回退链 1-3 全部失败且源码无 console.log → FAIL #14 → AUTO-FIX(添加 console.log + 自动填充)**
|
||||
|
||||
**注意**:仅适用于下一步骤立即需要的数据。订单号、支付结果等后续页面自然显示的不在此列。
|
||||
|
||||
**规则 E3.6:即时使用数据必须可回溯(⛔ 强制)**
|
||||
|
||||
操作成功后产生的即时使用数据(验证码等),如果仅通过 Toast 传递,下一步骤无法获取 → 流程卡死。
|
||||
|
||||
这不是所有 Toast 都是问题,仅当三条件同时满足时才触发修复(见 R6 场景 B)。
|
||||
|
||||
**回退链(按优先级)**:
|
||||
```
|
||||
触发即时使用数据操作后:
|
||||
↓
|
||||
1. browser_snapshot → 如果 Toast 包含关键数据 → 立即记录
|
||||
↓ (Toast 已消失)
|
||||
2. browser_console_messages(level="info") → 查找 console.log 记录
|
||||
@@ -454,7 +429,7 @@ Story 验证全部通过 ≠ 用户能正常使用系统。旅程模式弥补这
|
||||
- [ ] 截图文件名**必须**包含 `.png` 扩展名(`journey-epic-N-M-step-S.png`)
|
||||
- [ ] 截图**必须**保存到 `tests/e2e/screenshots/` 目录,不能保存到当前工作目录
|
||||
- [ ] **每个截图文件必须是真正的 PNG 图片** → `file <path>` 检测输出必须包含 "PNG image data"
|
||||
- [ ] **强制:每截一张图立刻检查** → `browser_take_screenshot` 完成后**立刻**执行 `file` 检测格式,失败立刻重截
|
||||
- [ ] **强制:每截一张图立刻检查** → `browser_take_screenshot` 完成后立刻执行 `file` 检测格式,失败立刻重截
|
||||
- [ ] 每个用户步骤完成 → `browser_take_screenshot` + `file` 格式验证 + `analyze_image` → 视觉验证关卡
|
||||
- [ ] 旅程最终完成 → `browser_take_screenshot` 最终截图 + `browser_network_requests` 资源检查
|
||||
- [ ] 违反任意一条 → 中断补全,不能继续
|
||||
@@ -512,6 +487,8 @@ Story 验证全部通过 ≠ 用户能正常使用系统。旅程模式弥补这
|
||||
result: "pass|fail"
|
||||
- check: "file_format_validation"
|
||||
result: "pass|fail"
|
||||
executed_at: "{ISO timestamp}"
|
||||
note: "{备注}"
|
||||
```
|
||||
c. 步骤级 GATE 检查(6 项,任一 FAIL → 阻断):
|
||||
├── G1: screenshot_consistency — screenshot_path 文件存在
|
||||
@@ -562,8 +539,8 @@ Story 验证全部通过 ≠ 用户能正常使用系统。旅程模式弥补这
|
||||
**Pencil MCP 模式(优先)**:
|
||||
- 读取 pipeline-context.md 获取设计文件路径(如 VividSpark1.2.pen)
|
||||
- mcp__pencil__batch_get → 搜索与当前状态匹配的帧
|
||||
- 搜索关键词: "{Page}-{State}" 如 "Dashboard-Modal", "Login-Error"
|
||||
- 或按 frame 类型和名称模式匹配
|
||||
- 搜索关键词: "{Page}-{State}" 如 "Dashboard-Modal", "Login-Error", "Upload-Loading"
|
||||
- 或按 frame 类型和名称模式匹配
|
||||
- 如找到匹配帧 → mcp__pencil__export_nodes 导出设计截图
|
||||
|
||||
**HTML 原型模式(回退)**:
|
||||
|
||||
@@ -150,7 +150,7 @@ visual_diff_pencil_mapping:
|
||||
```
|
||||
原理:代码中存在的页面一定要对比,不能因为自动映射失败就漏掉。
|
||||
1. 读取 app/mini-program/src/pages.json
|
||||
2. 提取所有 pages 和 subpackages 中的页面路径
|
||||
2. 提取 all pages 和 subpackages 中的页面路径
|
||||
3. 对每个页面路径:
|
||||
- 提取页面名 = 路径倒数第二段("pages/withdraw/index" → "withdraw")
|
||||
- 检查当前映射表中是否已有该页面
|
||||
@@ -292,7 +292,7 @@ PVD-1 PER-PAGE LOOP:
|
||||
if node.name != null && node.name != "":
|
||||
resultList.push({path: path + node.name, node: node})
|
||||
for each child in node.children:
|
||||
collectNamedNodes(child, path + node.name + ".", resultList)
|
||||
collectNamedNodes(child, path + node.name + ".", result);
|
||||
|
||||
**强制要求**: **任何层级**只要节点有 name 属性,都必须提取并检查。**不允许只检查顶层不检查深层**。
|
||||
|
||||
|
||||
89
.claude/skills/d8d-inc-plan/SKILL.md
Normal file
89
.claude/skills/d8d-inc-plan/SKILL.md
Normal file
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: d8d-inc-plan
|
||||
description: BMAD 项目增量需求规划 - 自动识别需要更新哪些BMAD产物(PRD/Epic/UX/Journey/原型/代码),生成完整详细的计划
|
||||
---
|
||||
|
||||
# BMAD 增量需求规划技能
|
||||
|
||||
## 功能描述
|
||||
|
||||
当项目已经有完整的 BMAD 文档体系(PRD, Epics, UX, 用户旅程, 原型),用户提出**新的增量需求**时,技能自动:
|
||||
|
||||
1. 读取现有 BMAD 文档结构和格式约定
|
||||
2. 探索现有代码库结构
|
||||
3. 根据新增需求,识别**所有需要更新**的产物
|
||||
4. 严格遵循现有 BMAD 格式,生成**完整详细**的更新计划
|
||||
5. 写入计划文件,自动进入计划模式等待批准
|
||||
|
||||
省去每次增量需求都要手动重复说明"更新需求文档、故事、旅程、原型、代码",标准化流程提高效率。
|
||||
|
||||
## 使用场景
|
||||
|
||||
- 现有 BMAD 项目新增功能模块
|
||||
- 现有功能迭代优化需要文档同步更新
|
||||
- Bug修复涉及文档更新需要完整规划
|
||||
- 新增技能工具类功能需要标准化规划
|
||||
|
||||
## 快速开始
|
||||
|
||||
```
|
||||
用户: "新增功能:在UI界面可配置三大地图API Key,数据库优先 .env兜底,请帮我规划"
|
||||
```
|
||||
|
||||
## 执行流程
|
||||
|
||||
### 1. 探索阶段
|
||||
- 读取 `_bmad-output/planning-artifacts/` 下现有文档:
|
||||
- `prd.md` - 需求文档
|
||||
- `epics.md` - Epic & Story 分解
|
||||
- `ux-design-specification.md` - UX 设计规范
|
||||
- 读取 `_bmad-output/implementation-artifacts/` 下现有旅程文档:
|
||||
- `epic-*.md` - 各Epic用户旅程
|
||||
- `journey-coverage-report.md` - 旅程覆盖报告
|
||||
- 读取 `prototype/` 下静态原型
|
||||
- 识别现有格式约定(章节编号、标题层级、代码块格式、验收标准写法)
|
||||
|
||||
### 2. 分析阶段
|
||||
- 理解用户新增需求
|
||||
- 识别**哪些产物需要更新**:
|
||||
- PRD 是否需要新增功能章节?
|
||||
- Epics 是否需要新增 Epic?
|
||||
- UX 设计规范 是否需要新增交互旅程?
|
||||
- 是否需要新建用户旅程文档?
|
||||
- 旅程覆盖报告 是否需要更新?
|
||||
- 静态原型 是否需要更新预览?
|
||||
- 哪些代码文件需要修改/新建?
|
||||
|
||||
### 3. 生成计划阶段
|
||||
- 严格遵循现有格式写出每一步更新内容
|
||||
- 对文档更新,给出**具体插入位置**和**完整内容片段**
|
||||
- 对代码更新,给出**文件路径**和**代码结构**
|
||||
- 输出完整的文件变更清单
|
||||
- 给出验证测试步骤
|
||||
|
||||
### 4. 写入计划文件
|
||||
- 写入计划到 `/home/d8d-claude/.claude/plans/{random-slug}.md`
|
||||
- 自动触发计划模式等待用户批准
|
||||
|
||||
## 输出格式要求
|
||||
|
||||
计划文件必须包含:
|
||||
- **Context** - 需求背景和问题描述
|
||||
- **完整更新范围** - 列出所有需要更新的产物
|
||||
- **详细更新内容** - 每个产物更新什么内容,给出具体片段
|
||||
- **代码实现步骤** - 每个文件做什么修改
|
||||
- **完整文件变更清单** - 表格形式列出所有变更
|
||||
- **验证测试步骤** - 分点列出验证要点
|
||||
|
||||
## 格式约定遵循
|
||||
|
||||
- 文档更新:遵循现有 PRD/Epics/UX 章节编号
|
||||
- 用户旅程:遵循 `epic-X-journeys.md` 格式(旅程 → 用户步骤 → 技术验证 → 验收标准)
|
||||
- 代码:遵循项目现有代码风格(命名、导入顺序、错误处理)
|
||||
- 技能:遵循 `.claude/skills/{skill-name}/SKILL.md` 格式
|
||||
|
||||
## 依赖要求
|
||||
|
||||
- 项目已经完成 BMAD 初始化,有完整的 `_bmad-output/` 文档结构
|
||||
- 用户已经明确提出增量需求
|
||||
- 技能只负责**生成计划**,不执行实际代码变更;计划批准后由开发技能执行
|
||||
Reference in New Issue
Block a user