Help us improve
Share bugs, ideas, or general feedback.
From vibeflow
Drives a single feature through the full TDD pipeline: orient, gate, plan, TDD, quality gates, acceptance, review, persist. Use when feature-list.json exists and some features still fail.
npx claudepluginhub ttttstc/vibeflow --plugin vibeflowHow this skill is triggered — by the user, by Claude, or both
Slash command
/vibeflow:vibeflow-build-workThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
通过每次循环实现一个功能来执行多会话软件项目。每个循环遵循严格管线:Orient -> Gate -> Plan -> TDD -> Quality -> ST 验收 -> Review -> Persist。
Orchestrates multi-session projects by implementing one feature per cycle from feature-list.json through TDD pipeline with quality gates and code review.
Orchestrates unified workflows for feature implementation, bug fixes, autonomous batch processing, planning, ATDD agent teams, and end-to-end coding.
Routes the VibeFlow lifecycle at session start: detects phase, injects context, dispatches to phase handler. Supports Full and Quick modes.
Share bugs, ideas, or general feedback.
通过每次循环实现一个功能来执行多会话软件项目。每个循环遵循严格管线: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