菜单
Use when starting or switching to a new human-collaboration task. Confirm the target issue, bootstrap the corresponding dev/issue flow scene, and hand off to the chosen implementation workflow. Do not use for resuming an existing branch; use vibe-continue instead.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the user wants to classify dirty changes, create serial commits, split work into one or more PRs, or publish the current flow without merging it.
Use when the user wants to resume work on an existing branch or flow. Reads context, executes the next step, reviews the result, and reports to the user before proceeding. Equivalent to superpowers:executing-plans, using vibe3 as the execution backend.
Use when you need an overview of the Vibe Center project, its implementations (vibe2 shell and vibe3 python), the available commands, and the standard development workflow. This is the meta-skill that orients any agent to the project.
Use after `scripts/install.sh` to guide users through machine-level setup, dependency checks, Claude/Codex toolchain readiness, and core feature introduction. Interactive onboarding for new users. Delegates diagnostics to `vibe doctor` and `vibe keys check`. Do not use for project-level configuration (use vibe-project-check instead).
Use after `vibe init` to verify target-project configuration completeness, tool availability, and environment readiness. Interactively prompts user to fill missing items. Orchestrates existing commands without adding Python code. Supports cross-project vibe3 readiness verification (Phase 5-8). Do not use for system-level installation issues (use vibe-onboard instead).
Use when the user wants to save session context. This is a human-facing session handoff entrypoint that preserves work state via vibe3 handoff, not an automated persistence workflow.
| name | vibe-new |
| description | Use when starting or switching to a new human-collaboration task. Confirm the target issue, bootstrap the corresponding dev/issue flow scene, and hand off to the chosen implementation workflow. Do not use for resuming an existing branch; use vibe-continue instead. |
从 issue 进入一个新的协作 flow。
从用户输入提取意图：
/vibe-new 2540 → issue=2540, branch=dev/issue-2540/vibe-new 2540 create worktree → issue=2540, worktree=true/vibe-new 2540 superpowers → issue=2540, workflow=superpowers/vibe-new 2540 worktree superpowers → issue=2540, worktree=true, workflow=superpowers/vibe-new（无参数）→ 询问 issue 号推断规则：
dev/issue-<id>（自动推断，不问）并行执行以下 4 条命令（不要串行）：
vibe3 flow show
git status
git fetch origin main
gh issue view <issue-number> --json labels,body,state
然后一次性判断：
/vibe-continue/vibe-issue 完成 intake → 继续禁止跳过 vibe3 flow show 直接进入 bootstrap。
在 bootstrap 前，必须检查 origin/main 是否有更新：
检查本地 main 是否落后（fetch 已在 Step 1 完成）：
git log main..origin/main --oneline | wc -l
决策逻辑：
本地 main 分支落后 origin/main {N} commits，新分支将基于最新的 origin/main 创建vibe3 internal bootstrap 会自动从 origin/main 创建分支）用户选择：
vibe3 internal bootstrap 自动处理 fetch + 分支创建vibe3 handoff append "跳过 main 同步检查，用户主动选择"原因：vibe3 internal bootstrap 内部已执行 git fetch + git create_branch_ref(branch, start_ref=origin/main)，不依赖本地 main 分支状态。新分支始终基于最新的 origin/main 创建，避免从落后代码开始的问题。
在确认目标 issue 后，检查是否为 Epic 主 issue：
使用 Step 1 获取的 issue 数据。
检查逻辑：
roadmap/epic 标签 且 body 包含 ## Sub-issues 或 ## 子任务 section：
## Sub-issues section 解析）roadmap/epic 标签但无 ## Sub-issues section：
注意：必须同时满足标签和 section 两个条件才是有效的 Epic 主 issue。
从输入解析中已确认的信息不再询问：
workflow 推荐顺序（参考 spec-kit-workflow-standard.md 双轨模型）：
brainstorm → specify → plan → tasks → implement → review，对应 /speckit-* skillsvibe3 plan/run/review注意：
vibe3 plan/run/review是自动化执行后端，通常不作为人机协作首选入口；spec/explore 阶段保持人机协作走 spec-kit 轨。openspec 不是本项目推荐工作流，统一用 spec-kit。
在 bootstrap 前，确认依赖关系：
使用 Step 1 获取的 issue body，检查是否有 ## Dependencies 或 ## 依赖 section
如果存在依赖：
Depends on #<id>、依赖 #<id>、blocked by #<id>）gh issue view <dep-id> --json state
open：
--dependency <id> 参数closed：
--dependency 参数如果无依赖：继续
强制要求：必须使用 vibe3 internal bootstrap 作为唯一 bootstrap 路径，禁止手工拼接。
✅ 正确做法：
vibe3 internal bootstrap <issue-number> \
--branch dev/issue-<id> \
[--related <issue-number>]... \
[--dependency <issue-number>]... \
[--reactivate-existing]
❌ 禁止做法：
git checkout -b / git switch -c 手工建分支vibe3 flow update / vibe3 flow bind 手工组装 flowgit pull origin main && git checkout -b ... 手工拉取建分支原因：bootstrap 命令保证幂等性、统一的 actor 签名和 flow 关系绑定。手工拼接会绕过这些契约，导致 flow 状态不一致。
如遇 bootstrap 失败：先诊断问题（网络、权限、分支冲突），不要回退到手工拼接。
这个命令会走共享底层路径，完成：
bootstrap 成功后，根据当前环境留痕：
判断环境：
# 检测是否有 flow 环境
vibe3 flow show
留痕规则：
有 flow 环境（正常情况）：使用 handoff 记录创建决策
vibe3 handoff append "[vibe-new] flow ready" --actor vibe-new --kind milestone
无 flow 但有 issue（异常情况）：在 issue 中记录创建失败
gh issue comment <issue-number> --body "## vibe-new 创建失败
**原因**：<失败原因>
**下一步**：<建议操作>
"
都没有：无需留痕
留痕内容应包含：
bootstrap 后、指向下一阶段前，调用现有 skill 查 spec-kit 进度：
/speckit-superspec-status（勿手写 bash 重造）：
.specify/specs/，读每个 spec 的 progress.yml（无则按 spec.md/plan.md/tasks.md 存在性推断 phase）Suggested next step（如 /speckit.superspec.execute 001）vibe3 flow show 确认当前 flow 的 spec_ref / plan_ref / report_ref / audit_ref，用来把 issue 关联到具体 spec 编号轨选择（依 suggested next step + 任务性质）：
| 情况 | 推荐 |
|---|---|
/speckit-superspec-status 给出 suggested next step，且为非平凡变更 | 按 suggestion 进入 spec-kit 轨 |
无 .specify/ 或无匹配 spec，且变更为非平凡 | /speckit-superspec-brainstorm 或 /speckit-specify 起步 |
| issue body 已明确、琐碎修复、文档改动 | 跳过 spec-kit，走 vibe3 flow 轨 /vibe-continue |
向用户展示 status 输出 + 推荐，由用户确认进入哪条轨。不自动推进。
bootstrap 完成 + Step 7.5 spec 状态扫描后，根据推荐分流：
/speckit-<phase> 或 specify workflow run speckit/vibe-continue（vibe3 plan → run → review → publish）不再默认把 vibe3 plan/run/review 作为"标准"工作流。两条轨皆为 first-class，视任务性质选择。详见 spec-kit-workflow-standard.md。
完成后应能明确说出：
dev/issue-<id> flow 已 readyvibe3 flow show