一键导入
vibeflow-quality
TDD 循环后使用 — 强制覆盖率门禁、变异测试门禁和新鲜验证证据,方可标记功能为通过
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
TDD 循环后使用 — 强制覆盖率门禁、变异测试门禁和新鲜验证证据,方可标记功能为通过
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
启动 VibeFlow 本地看板,实时查看阶段、功能、产物和最近事件。
查看 VibeFlow 项目当前状态(阶段、进度、待处理项)。
VibeFlow框架入口。运行 /vibeflow 开始新项目或继续现有工作流。
测试阶段的真实浏览器验证底座。用于页面交互、表单、路由、前端 API、视觉状态和运行时问题验证。优先使用 Playwright MCP 做真实交互验证,使用 Chrome DevTools MCP 做运行时诊断;MCP 不可用时回退到本地 Playwright CLI 脚本。
在此仓库中用于在会话开始时路由整个VibeFlow生命周期的工作。
系统测试通过后且工作流要求 UI QA 时使用 — 运行浏览器导向的 QA 验证并生成报告
| name | vibeflow-quality |
| description | TDD 循环后使用 — 强制覆盖率门禁、变异测试门禁和新鲜验证证据,方可标记功能为通过 |
三道顺序门禁,全部必须通过后功能才能被标记为 "passing"。没有捷径,没有例外。
启动宣告: "正在使用 vibeflow-quality 运行质量门禁。"
没有新鲜验证证据就不能声称完成
如果你在这条消息中没有运行验证命令,你不能声称它通过了。
从 .vibeflow/work-config.json 读取质量门禁阈值:
line_coverage_minbranch_coverage_minmutation_score_min如 work-config.json 不存在,从 feature-list.json 的 quality_gates 读取。
TDD Green(所有测试通过)后,运行覆盖率工具。
必需证据:
- 覆盖率工具输出,显示行 % 和分支 %
- 行覆盖率 >= 阈值
- 分支覆盖率 >= 阈值
- 未覆盖行列表(如有,附理由)
- 实际运行的命令
TDD Refactor 后,对变更文件运行变异测试。
{changed_files} 为实际路径)增量 vs 全量:
| 场景 | 范围 |
|---|---|
| 每个功能(常规) | 增量 — 仅变更文件 |
| 项目里程碑(每 5-10 个功能) | 全量 — 整个代码库 |
标记功能为 "passing" 前的最终门禁。
1. 识别 -> 获取测试/覆盖率/变异测试命令
2. 运行 -> 执行每个命令(新鲜的,在此消息中 — 不是之前缓存的)
3. 阅读 -> 每个的完整输出:
- 检查退出码
- 计数测试 通过/失败/跳过
- 读取覆盖率百分比
- 读取变异得分
4. 验证 -> 所有输出都确认声称?
- 所有测试通过(0 失败)?
- 覆盖率 >= 阈值?
- 变异得分 >= 阈值?
5. 然后声称 -> 仅现在:
- 标记功能 "status": "passing"
- 报告结果及证据
如任何步骤失败 -> 停止。不标记为 passing。先修复问题。
如果当前 feature 合同的 custom_rules.files 非空,质量门禁阶段必须补跑项目规则的可执行检查,而不是只看代码“感觉上像是符合规范”。
对当前功能的变更文件运行:
python scripts/vibeflow_rules.py --project-root . --stage build --language <language> --file-scope <changed-file> --file-scope <changed-file> --design-path docs/changes/<change-id>/design.md --evaluate-checks --format markdown
要求:
passingIssues:,先修复,再重新执行Warnings: 需要在功能报告中说明为什么可以接受,或转成后续改进项如果你发现自己使用以下任何词语,停止并重新验证:
| 红线 | 必需行动 |
|---|---|
| "应该通过" | 立即运行测试 |
| "可能可以" | 立即执行并验证 |
| "看起来在工作" | 获取具体测试输出 |
| "我相信这是正确的" | 运行验证命令 |
| "看起来不错" | 运行自动化测试 |
| "基于实现来看" | 测试验证行为,不是代码 |
| "测试应该是绿的" | 运行测试并读取输出 |
| "我已验证"(无输出) | 展示实际输出 |
| "覆盖率可能够了" | 立即运行覆盖率工具 |
| "变异得分应该够高" | 立即运行变异测试 |
| 事件 | 验证什么 |
|---|---|
| TDD Green 后 | 完整测试套件输出 |
| 覆盖率门禁后 | 覆盖率报告(行% + 分支%) |
| TDD Refactor 后 | 完整测试套件(仍然通过) |
| 变异门禁后 | 变异报告(得分%) |
| 标记 "passing" 前 | 以上全部 + verification_steps |
| Git 提交前 | 完整测试套件(不提交破损代码) |
| 反模式 | 正确做法 |
|---|---|
| 写代码后不运行测试就标记 "passing" | 运行测试,读取输出,然后标记 |
| 相信重构没有破坏任何东西 | 每次重构后重新运行完整套件 |
| 只读测试输出的摘要行 | 读取完整输出 |
| 对未覆盖代码运行变异测试 | 先通过覆盖率门禁 |
| 会话开始时跳过重新验证 | 始终冒烟测试已通过功能 |
调用者: vibeflow-build-work(步骤 8) 依赖: TDD 循环完成(vibeflow-tdd 通过 — 测试存在且通过) 产出: 新鲜验证证据(测试输出、覆盖率 %、变异得分) 链接到: vibeflow-feature-st(通过 Work 步骤 9)