Menü
质量门禁通过后使用 — 独立管理测试环境生命周期，执行黑盒验收测试，生成 ISO/IEC/IEEE 29119 合规测试用例文档
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
启动 VibeFlow 本地看板，实时查看阶段、功能、产物和最近事件。
查看 VibeFlow 项目当前状态（阶段、进度、待处理项）。
VibeFlow框架入口。运行 /vibeflow 开始新项目或继续现有工作流。
测试阶段的真实浏览器验证底座。用于页面交互、表单、路由、前端 API、视觉状态和运行时问题验证。优先使用 Playwright MCP 做真实交互验证，使用 Chrome DevTools MCP 做运行时诊断；MCP 不可用时回退到本地 Playwright CLI 脚本。
在此仓库中用于在会话开始时路由整个VibeFlow生命周期的工作。
系统测试通过后且工作流要求 UI QA 时使用 — 运行浏览器导向的 QA 验证并生成报告
| name | vibeflow-feature-st |
| description | 质量门禁通过后使用 — 独立管理测试环境生命周期，执行黑盒验收测试，生成 ISO/IEC/IEEE 29119 合规测试用例文档 |
在 TDD 实现和质量门禁通过后，为已完成的功能执行黑盒验收测试。此技能独立管理自己的环境生命周期（启动 -> 测试 -> 清理），并生成 ISO/IEC/IEEE 29119 合规的测试用例文档。
启动宣告： "正在使用 vibeflow-feature-st 运行黑盒验收测试。"
TDD（vibeflow-tdd）已从内部验证了实现。此技能从外部验证 — 如用户或外部系统般：
规则： 如果一个测试用例需要阅读源代码才能确定预期结果，它不是黑盒测试 — 仅使用 SRS 规格重写。
.vibeflow/guides/services.md）.vibeflow/guides/services.md — 定位"启动所有服务"章节.vibeflow/logs/session-log.md.vibeflow/guides/services.md为什么强制：留下运行的服务会在后续 ST 循环中造成端口冲突。
读取目标功能的所有输入工件：
docs/changes/<change-id>/tasks.md"ui": true）对每个 verification_step，生成一个或多个测试用例。
类别分配规则：
| 类别 | 缩写 | 何时生成 |
|---|---|---|
功能 | FUNC | 始终 — 每个功能的正常路径 + 错误路径 |
边界 | BNDRY | 始终 — 极端情况、限制、空/最大/零值 |
UI | UI | 仅当 "ui": true — Chrome DevTools 交互 + 视觉验证 |
安全 | SEC | 当功能处理用户输入、认证或外部数据 |
无障碍 | A11Y | 仅当 "ui": true — WCAG 2.1 AA 检查 |
性能 | PERF | 仅当追溯到有性能指标的 NFR-xxx |
最低覆盖：
verification_step 必须映射到至少一个测试用例用例 ID 格式：
ST-{类别}-{功能ID(3位)}-{序号(3位)}
示例：ST-FUNC-005-001、ST-UI-005-002、ST-SEC-012-001
测试用例内容规则：
evaluate_script() 自动错误检测list_console_messages 控制台错误门禁输出文件：docs/test-cases/feature-{id}-{slug}.md
文档结构：
追溯矩阵的"结果"列初始为 PENDING。步骤 4 执行后更新为 PASS/FAIL。
硬性要求：必须逐一执行 docs/test-cases/feature-{id}-{slug}.md 中定义的测试用例
任何用例失败时：
AskUserQuestion 报告用户：失败用例 ID、步骤详情、实际 vs 预期调用者： vibeflow-build-work（步骤 9）
依赖： 质量门禁通过
产出： docs/test-cases/feature-{id}-{slug}.md（含执行结果）
链接到： vibeflow-spec-review（通过 Work 步骤 10）