Help us improve
Share bugs, ideas, or general feedback.
From vibeflow
Initializes a VibeFlow project after task approval: validates execution plans, scaffolds project structure, and generates feature-list.json from design contracts to prepare for iterative build.
npx claudepluginhub ttttstc/vibeflow --plugin vibeflowHow this skill is triggered — by the user, by Claude, or both
Slash command
/vibeflow:vibeflow-build-initThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
在 `tasks` 审批通过后运行一次。搭建所有持久化工件,将需求分解为可验证的功能,准备项目进入迭代构建。
Entry point for VibeFlow framework. Initiates structured six-phase development workflow (Spark→Test) with quality gates. Supports Quick Mode for small changes and Full Mode for complex features.
Use when ATS doc exists (or auto-skipped) but feature-list.json not yet created - scaffold project artifacts and populate features from Design §10.2
Orchestrates end-to-end feature workflow from requirements to design, tasks, build, verify, and archive using sub-agents in one command.
Share bugs, ideas, or general feedback.
在 tasks 审批通过后运行一次。搭建所有持久化工件,将需求分解为可验证的功能,准备项目进入迭代构建。
在 Claude Code 插件的默认路径中,本 skill 是 Build 自动继续链路的第一个内部子步骤。只有 tasks 已经展示全量交付计划并经过人工确认后,才能进入这里。
启动宣告: "正在使用 vibeflow-build-init 初始化项目。"
| 文档 | 位置 | 提供 |
|---|---|---|
| 概要 | docs/changes/<change-id>/brief.md | 目标、范围、非目标、验收标准、约束、假设、开放问题 |
| 设计 | docs/changes/<change-id>/design.md | 技术栈、架构、数据模型、API 设计、测试策略 |
| 执行计划 | docs/changes/<change-id>/tasks.md | execution-grade tasks,包含精确文件路径、验证步骤、回滚说明、依赖关系 |
| 工作流 | .vibeflow/workflow.yaml | 模板配置、质量门禁阈值 |
按顺序完成以下步骤:
python scripts/get-vibeflow-paths.py --jsondocs/changes/<change-id>/brief.md — 目标、范围、验收标准、约束、假设docs/changes/<change-id>/design.md — 技术栈、架构决策docs/changes/<change-id>/tasks.md — execution-grade task blocks.vibeflow/workflow.yaml — 质量阈值和启用的步骤在进入项目骨架生成和 feature 分解前,先验证 tasks.md 是否达到执行级质量。
适用规则:
tasks.md 是必需输入必须检查:
tasks.md 存在且可解析为按任务块组织的计划task_id、goal、exact_file_paths、steps、verification_steps、rollback_note、expected_duration_minexact_file_paths 为仓库内精确路径,不得出现“相关文件”“必要时”“视情况”“等”这类模糊词verification_steps 至少包含一个可执行检查rollback_note 说明最小撤销路径expected_duration_min 默认在 2-5 分钟范围;超过 10 分钟的任务必须阻塞并要求拆分feature_id、build_contract_ref、design_section 中至少一个正式索引阻塞规则:
feature-list.json基于设计文档的架构创建目录结构、配置文件、依赖清单。
创建 feature-list.json,根结构:
权威来源规则:
design.md 中的 Build Contract + Implementation Contract TOML 代码块是生成 feature-list.json 的唯一权威来源tasks.md 或默认值回退推断 feature 合同Build Contract、或 feature 契约不完整,必须阻塞 build-init{
"project": "项目名",
"created": "YYYY-MM-DD",
"tech_stack": {
"language": "python|java|typescript|c|cpp",
"test_framework": "pytest|junit|vitest|gtest|...",
"coverage_tool": "pytest-cov|jacoco|c8|gcov|...",
"mutation_tool": "mutmut|pitest|stryker|mull|..."
},
"quality_gates": {
"line_coverage_min": 90,
"branch_coverage_min": 80,
"mutation_score_min": 80
},
"constraints": ["硬限制 — 每项一个字符串"],
"assumptions": ["隐含信念 — 每项一个字符串"],
"required_configs": [],
"features": []
}
quality_gates 阈值应从 .vibeflow/workflow.yaml 中读取,而非硬编码默认值。
从 brief.md 中:
constraints[] — 复制 CON-xxx 项assumptions[] — 复制 ASM-xxx 项category: "non-functional" 的功能条目,带可度量的 verification_steps如设计契约已经声明 constraints[]、assumptions[]、required_configs[],优先采用设计文档中的执行版本;brief.md 作为追溯和补全来源。
优先从设计文档中每个 feature 的 Implementation Contract 填充 features[];必要时再从 brief.md 与设计文档的开发计划(任务分解章节)补全。
id、category、title、description、priority、status(始终为 "failing")、verification_steps、dependenciesverification_steps 应追溯到 brief 中的验收标准(Given/When/Then)"ui": true,可选 "ui_entry": "/路径"file_scope、requirements_refs、integration_points、required_configs、autopilot_commands 必须原样保留到 feature 条目中每个功能条目:
{
"id": 1,
"category": "core",
"title": "功能标题",
"description": "做什么",
"priority": "high|medium|low",
"status": "failing",
"verification_steps": ["步骤 1", "步骤 2"],
"dependencies": [],
"ui": false,
"ui_entry": "/可选路径"
}
验证步骤质量规则:
"登录页正常显示" -> 无动作,无断言"导航到 /login -> 预期:邮箱输入框、密码输入框、'登录'按钮;填入有效凭证 -> 点击登录 -> 预期:跳转到 /dashboard,头部显示用户名"[devtools] 步骤必须描述多步交互链前后端配对排序规则:前端功能("ui": true)必须在 dependencies[] 中列出其后端 API 依赖。且 features[] 数组中在每个后端功能之后紧跟其对应的前端功能。
优先级排序:遵循设计文档的任务分解表 — P0/P1/P2/P3 映射为 high/high/medium/low
目标:10-200+ 个功能;每个独立可验证,可在一个会话中完成。
在 feature-list.json 准备完成后,为每个 feature 补齐归一化合同字段,至少包括:
如果 feature 来自设计契约,条目必须包含:
design_sectionbuild_contract_refrequirements_refsintegration_pointsBuild 阶段后续独立实施单元的正式输入应以 feature-list.json + design.md + tasks.md + rules/ 为准,不应依赖长会话上下文记忆。
从 brief(IFR-xxx 接口需求)和设计文档:
envfilerequired_by 链接到功能;提供 check_hint 含设置说明从 required_configs 生成:
# <名称> — <描述>
# 提示:<check_hint>
# 功能依赖:<required_by ids>
<KEY>=
将 .env 加入 .gitignore。
创建项目专属的构建会话指南,放在 .vibeflow/guides/build.md:
必须包含的章节:
.vibeflow/guides/services.md在 .vibeflow/guides/services.md 创建服务生命周期指南:
创建 init.sh(Unix/macOS)和 init.ps1(Windows):
.vibeflow/logs/session-log.md — 含 ## Current State 头部(在首次执行写入时生成)RELEASE_NOTES.md — Keep a Changelog 格式运行初始化脚本,验证环境搭建无错误。验证测试命令可执行(此时全部失败是预期的)。
初始提交,包含所有搭建的工件。
不要在这里停下来等待下一条用户指令。完成初始化后立即重新检测 phase,继续 Build 自动执行链路;仅在调试或恢复时,才手动转入 vibeflow-build-work。
| 文件 | 用途 |
|---|---|
feature-list.json | 带状态的结构化任务清单 |
.vibeflow/build-reports/feature-*.md | 每个 feature 的执行证据报告 |
.vibeflow/logs/session-log.md | 逐会话进度日志 |
RELEASE_NOTES.md | 活跃的发布说明 |
.vibeflow/guides/build.md | 项目专属构建指南 |
.vibeflow/guides/services.md | 服务生命周期命令(如适用) |
init.sh / init.ps1 | 环境引导脚本 |
.env.example | 必需环境配置模板 |
调用者: vibeflow-router 的 Build 自动继续链路,或调试/恢复场景下的手动调用
读取: docs/changes/<change-id>/brief.md + docs/changes/<change-id>/design.md + docs/changes/<change-id>/tasks.md + .vibeflow/workflow.yaml
链接到: Build 自动继续链路(默认) / vibeflow-build-work(手动 fallback)
产出: feature-list.json + 上述所有工件