Menü
feature-list.json 存在且部分功能仍失败时使用 — 驱动功能通过完整 TDD 管线、质量门禁和代码审查
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-build-work |
| description | feature-list.json 存在且部分功能仍失败时使用 — 驱动功能通过完整 TDD 管线、质量门禁和代码审查 |
通过每次循环实现一个功能来执行多会话软件项目。每个循环遵循严格管线：Orient -> Gate -> Plan -> TDD -> Quality -> ST 验收 -> Review -> Persist。
在 Claude Code 插件的默认路径中，本 skill 是 Build 自动继续链路的核心内部子步骤。只有在调试单个阶段、重跑某个功能、或处理失败恢复时，才把它当成显式入口。
启动宣告： "正在使用 vibeflow-build-work。让我先定位当前状态。"
核心原则： 每个子步骤有其专属 skill。严格遵循编排顺序。
每次循环一个功能，主会话上下文顺序执行。
适用场景：
使用 Agent 工具同时启动多个 subagent，每个 subagent 在独立 200k token 上下文中执行一个 feature。
适用场景：
启动并行模式：
在调用 build-work 时明确告知模式选择：
请使用并行模式执行所有 failing features。
或
请使用顺序模式执行。
默认模式为 Sequential（更稳定）。
.vibeflow/workflow.yaml 是步骤启用的权威来源。在执行前读取它，跳过标记为禁用的步骤。典型可裁剪步骤：
tdd — 是否强制 TDD（prototype 模板可能禁用）quality_gates — 是否运行覆盖率/变异测试门禁feature_st — 是否运行功能验收测试spec_review — 是否运行规格合规审查即使步骤被裁剪，功能仍需测试和验证才能标记为 passing。裁剪仅影响形式化门禁流程。
.env（如存在）python scripts/get-vibeflow-paths.py --json.vibeflow/logs/session-log.md 的 ## Current State — 进度、上一个完成的功能、下一个功能feature-list.json — 注意 constraints[]、assumptions[]、required_configs[]、功能状态feature-list.json 中当前功能的归一化合同，并补读 design.md、tasks.md、rules/tasks.md 中当前功能对应的执行级任务块；将其视为已审批、已门禁的 handoff plan，而不是可随意改写的草稿build_contract_ref 与 design_section.vibeflow/guides/build.md — 项目专属工作流指导.vibeflow/guides/services.md（如存在）— 服务名、端口、健康检查 URLdocs/changes/<change-id>/design.md）— 项目概览和架构快照git log --oneline -10 — 近期提交上下文"status": "failing" 的功能，按优先级然后按数组位置（第一个合格的胜出）— 跳过 "deprecated": true 的功能dependencies[] 中所有功能 ID 在 feature-list.json 中状态为 "passing"。如有依赖未满足：
AskUserQuestion 警告用户"ui": true 且 UCD 文档存在，读取 UCD 风格指南文档查找协议：
当需要功能的设计章节或 SRS 需求时，不要 grep 功能标题。而是：
design_contract.design_section### 4.N 子节### 4.N 子节### 4.N 到 ### 4.(N+1) 前）design_contract.build_contract_ref，再补读 ## Build Contract 代码块{build_contract}、{design_section} 和 {srs_section} 供后续步骤使用功能合同规则：
feature-list.json 中的 feature 条目加上文档引用检查目标功能的 required_configs 是否齐备。缺失时通过 AskUserQuestion 向用户收集，追加到 .env。配置齐备前阻塞。
读取并消费 docs/changes/<change-id>/tasks.md 中已批准的执行级任务计划，为当前功能建立本轮执行顺序。
{design_section} 和 {srs_section}{build_contract}，计划必须同时遵守其中的全局约束和 required configstask_id、goal、exact_file_paths、steps、verification_steps、rollback_note、expected_duration_mintasks 阶段，而不是在 build-work 阶段自行补写一套新计划execution_notes / status，不得覆写已批准任务的目标、文件范围、验证步骤或回滚说明如 workflow.yaml 启用了 tdd：
读取并遵循 skills/vibeflow-tdd/SKILL.md。
传递上下文：当前功能对象、quality_gates、tech_stack、计划文件路径、完整 {srs_section}、完整 {design_section}。
如 workflow.yaml 启用了 quality_gates：
读取并遵循 skills/vibeflow-quality/SKILL.md。
Quality Gates 通过后，Feature-ST 和 Spec-Review 互不依赖，使用 Agent 工具并行执行：
Quality Gates 通过
│
├──▶ Agent: vibeflow-feature-st（黑盒验收测试）
│ 产出：docs/test-cases/feature-{id}-{slug}.md
│
└──▶ Agent: vibeflow-spec-review（规范合规审查）
产出：审查裁定（PASS/FAIL）
│
├── 两个 Agent 都返回 ──▶ 合并结果
└── 任一失败 ──▶ 修复后重新运行失败的部分
执行方式：
在同一条消息中发起两个 Agent 调用：
Agent 1 — Feature-ST（如 workflow.yaml 启用了 feature_st）：
.vibeflow/guides/services.md 路径skills/vibeflow-feature-st/SKILL.md，完成后返回执行结果摘要Agent 2 — Spec-Review（如 workflow.yaml 启用了 spec_review）：
skills/vibeflow-spec-review/SKILL.md，完成后返回审查裁定结果合并：
回退规则： 如 Agent 工具不可用或执行异常，回退为顺序执行（先 ST，后 Review）。
在 examples/ 中创建可运行的示例展示已完成的功能。纯基础设施功能可跳过。
RELEASE_NOTES.md（Keep a Changelog 格式）.vibeflow/logs/session-log.md：
## Current State：进度计数（X/Y 通过）、上一个完成的功能、下一个功能"status": "passing" 在 feature-list.json 中vibeflow-review.vibeflow/logs/session-log.md 已更新）tasks.md 是 handoff plan，不是 build-work 临时重写的草稿| 合理化借口 | 正确行动 |
|---|---|
| "配置之后再补" | 运行配置门禁。需要真实配置。 |
| "这功能太简单，跳过测试用例" | 运行 vibeflow-feature-st。每个功能。 |
| "这功能太简单，跳过 TDD" | 运行 vibeflow-tdd。每个功能。 |
| "测试通过了，标记完成" | 先运行 vibeflow-quality。 |
| "覆盖率差不多够了" | 阈值是硬门禁。运行工具。 |
| "我自己快速审查一下" | 运行 vibeflow-spec-review。始终。 |
| "让我快速试试这个修复" | 先系统化调试。 |
| "任务太粗，我边做边重新规划" | 停止实现，回退到 execution planning gate。 |
| "端口占用，手动杀掉" | 使用 .vibeflow/guides/services.md 的停止命令 |
| "后端没准备好先 mock" | 依赖检查存在是有原因的。先开发后端功能。 |
遵循系统化调试流程 — 不猜测修复：
当选择并行模式时，使用 Agent 工具同时执行多个 feature。
1. 读取 feature-list.json
→ 找出所有 status=failing 的 feature
→ 按优先级排序
2. 读取每个 feature 的设计章节
→ 确认 feature 之间无文件重叠
3. 同时 Spawn N 个 Agent（每个 failing feature 一个）
4. 等待所有 Agent 完成
5. 汇总结果
→ 更新 feature-list.json
→ 更新 `.vibeflow/logs/session-log.md`
→ 报告汇总
每个 subagent 收到：
# Feature Implementation Agent
你是 VibeFlow 的 feature 实现 Agent。你的上下文是**全新的 200k token**，没有任何历史包袱。
## 你的任务
实现 feature：
- **ID**: {feature_id}
- **名称**: {feature_name}
- **优先级**: {priority}
## 上下文文件（请先读取）
1. `docs/changes/<change-id>/design.md` — 技术设计（找到第 4.N 节）
2. `feature-list.json` — 功能详情（找到 id={feature_id} 的条目）
3. `.vibeflow/workflow.yaml` — 启用了哪些步骤
4. `.vibeflow/guides/build.md`（如存在）— 项目专属指导
## 执行步骤
按顺序执行：
### Step 1: Orient
理解功能需求，确认设计章节。
### Step 2: TDD
读取 `skills/vibeflow-tdd/SKILL.md`，执行红→绿→重构循环。
### Step 3: Quality Gates
读取 `skills/vibeflow-quality/SKILL.md`，运行覆盖率 + 变异测试。
### Step 4: Feature-ST
读取 `skills/vibeflow-feature-st/SKILL.md`，执行验收测试。
### Step 5: Spec-Review
读取 `skills/vibeflow-spec-review/SKILL.md`，检查实现是否符合 SRS。
### Step 6: Persist
1. **不要直接 commit** — 并行模式下由 orchestrator 统一处理 git 操作
2. 将实现结果回写到 `feature-list.json` 对应 feature 的 `execution_result` 字段，并生成 `.vibeflow/build-reports/feature-{id}.md`
3. 如实现完成但测试失败，status 仍为 "failing"
**重要**：不要同时写入 `feature-list.json`、`.vibeflow/logs/session-log.md`、`RELEASE_NOTES.md` 等共享文件，这些由 orchestrator 统一更新。
## 产出
完成后返回结构化结果：
RESULT: {feature_id}: PASS COMMIT: {git_hash} SUMMARY: {一句话总结}
如失败：
RESULT: {feature_id}: FAIL ERROR: {具体错误描述} RETRY: {是否可自动重试}
## 重要约束
- **每个 feature 独立执行**，不知道其他 feature 的存在
- **不要与其他 subagent 通信**，结果通过文件共享
- **遇到错误不要放弃**，尽力完成，能走多远走多远
所有 Agent 完成后：
1. 读取 `feature-list.json` 中各 feature 的 `execution_result`
2. 对于每个 PASS 的 feature：
a. git add {implemented_files}
b. git commit -m "feat({feature_id}): {summary}"
c. 获取 commit hash
3. 更新 feature-list.json（统一操作，非并行）：
- status = "passing"（如 PASS）
- status = "failing" + last_error（如 FAIL）
- completed_at = timestamp
- commit = hash（如 PASS）
4. 更新 `.vibeflow/logs/session-log.md`（统一操作）
5. 更新 RELEASE_NOTES.md（统一操作）
6. 生成汇总报告：
═══════════════════════════════════ Parallel Execution Results ═══════════════════════════════════ Total: N | PASS: M | FAIL: K
✅ Feature A — PASS (commit: abc123) ✅ Feature B — PASS (commit: def456) ❌ Feature C — FAIL (覆盖率不足)
Next: [处理失败 feature 的建议] ═══════════════════════════════════
7. 如有失败：
- 询问用户是否继续 Sequential 模式逐个修复
- 或在下一个会话处理
| 场景 | 推荐模式 |
|---|---|
| 项目启动，第一次执行所有 feature | Parallel |
| 调试某个具体 feature | Sequential |
| 有 feature 失败后的重试 | Sequential（修复单个） |
| 多个独立 feature 需要快速完成 | Parallel |
并行模式要求：
如不满足条件，自动降级为 Sequential 模式。
调用者： vibeflow-router 的 Build 自动继续链路（默认）或 vibeflow-build-init 的手动 fallback 调用顺序：
vibeflow-tdd（步骤 5-7）— 顺序vibeflow-quality（步骤 8）— 顺序（依赖 TDD 产出）vibeflow-feature-st + vibeflow-spec-review（步骤 9-10）— 并行（通过 Agent 工具）
读/写： feature-list.json、.vibeflow/logs/session-log.md、RELEASE_NOTES.md