بنقرة واحدة
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)