메뉴
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.
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 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 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.
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-continue |
| description | 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. |
恢复已有 flow 并逐步执行。每步完成后审查结果，发现问题直接修正，修正后再进入下一步。
执行 → 审查 → 修正 → 报告 → 下一步
不是"报告问题然后继续跑"。审查是修正门禁，不是信息展示。
修正优先级：
任务类型判断（进入流程前的第一步）：
flow 有 plan/run/review_ref?
├─ 有 → 恢复已有状态（标准实现流程）
└─ 无 → 检查 issue 标签
├─ roadmap/rfc → 进入 RFC 探索模式（见下方）
├─ roadmap/design → 进入 RFC 探索模式
├─ roadmap/epic → 不在此处处理，请使用 /vibe-new 选择 sub-issue
└─ 其他 → 标准实现流程
roadmap/rfc 和 roadmap/design 标签的 issue 自动走 RFC 探索模式vibe3 plan/vibe3 run/vibe3 review适用于：roadmap/rfc、roadmap/design 标签的 issue，或用户明确要求探索/研究/分析的任务。
目标：探索问题空间、质询假设、比较方案、形成结论。不产生代码实现。
Explore (了解领域) → Analyze (逐项质询) → Converge (收敛结论) → Record (记录输出)
探索模式的灵魂是苏格拉底式质询 — "烤"问每个假设和方案：
质询维度：
├─ 假设质询 "这个假设成立吗？证据是什么？不成立会怎样？"
├─ 边界扫描 "我们忽略了什么边界情况？极端条件下会怎样？"
├─ 代价分析 "这个方案的代价是什么？（复杂度/维护/性能/学习成本）"
├─ 逆向思考 "如果这个方案是错的，会怎样？反例是什么？"
├─ 简化挑战 "有更简单的方案吗？我们是不是在做过度工程？"
└─ 替代追问 "还有其他方案吗？为什么选这个不选那个？"
并行执行：
vibe3 flow show [--branch <b>]
vibe3 handoff show @current [--branch <b>]
gh issue view <number> --json body,labels,comments
git status
然后：
对每个子问题使用以下结构化分析：
单点分析框架
==============================
1. 现状描述
"当前是什么情况？"
2. 假设清单
"隐含了哪些假设？"
-> 逐条列出并标注可信度
3. 质询 (Grill Me)
a) "这个假设被违反会怎样？"
b) "边界条件是什么？"
c) "代价和收益是否匹配？"
d) "有反例吗？"
e) "更简单的做法是什么？"
4. 方案发散
"有哪些可能的方案？"
-> 列出 2-3 种方案及其 trade-off
5. 收敛
"推荐哪个？理由是什么？"
-> 明确推荐 + 开放问题
使用指导：
将各轮分析的结论汇总：
分析结论：
+ 已确认问题：N 个（每个附证据）
- 已排除问题：M 个（附排除理由）
? 开放问题：K 个（需进一步研究）
* 推荐方案：（如果有）
! 风险提示：（已知盲区）
Grill-Me 终审：
# 记录分析结论到 handoff
vibe3 handoff append "[vibe-continue] <分析结论摘要>" --actor vibe-continue --kind analysis
可能的输出形式：
探索完成后，可转向以下方向：
探索完成？
+ 结论明确，可进入实现 -> 告知用户创建实现 issue 或继续 /vibe-new
+ 发现新问题 -> 告知用户创建新 issue
+ 需要决策 -> 告知用户结论，等待决策
+ 继续探索 -> 回到 Step E1 继续
每步向用户报告探索进度：
RFC 探索进度 (Issue #XXXX):
- [x] E1 Explore: 已了解领域 (关键文件: N 个)
- [ ] E2 Analyze: 待分析 (剩余 M 个子问题)
- [ ] E3 Converge: 待收敛
- [ ] E4 Record: 待记录
当前发现：
- 问题 A: 确认存在（证据: ...）
- 问题 B: 需进一步研究
下一步：继续 Analyze 子问题 X
并行执行：
vibe3 flow show [--branch <b>]
vibe3 handoff show @current [--branch <b>]
git status
检查并清理残留 Monitor：
TaskList # 查看活跃 Monitor
# 任何残留 Monitor → TaskStop 清理
提取当前状态，决定下一步。
恢复上下文后，调用现有 skill 查 spec-kit 进度，分流到正确轨（参考 spec-kit-workflow-standard.md 双轨模型）。
/speckit-superspec-status（勿手写 bash 重造）：
.specify/specs/，读 progress.yml（无则按 spec.md/plan.md/tasks.md 推断 phase）Suggested next step（如 /speckit.superspec.execute 001）vibe3 flow show [--branch <b>] 确认 spec_ref/plan_ref/report_ref/audit_ref，关联 issue 到具体 spec 编号轨选择：
| 情况 | 推荐轨 | 下一步 |
|---|---|---|
| suggested next step 存在，非平凡变更 | spec-kit | 按 suggestion（/speckit-*） |
无 .specify/ 或无匹配 spec，issue 已明确 | vibe3 flow | Step 2 标准流程 |
flow 有 spec_ref/plan_ref 但无 spec 目录 | vibe3 flow | 按 plan_ref/run_ref 推进 |
向用户报告 status 输出 + 推荐，由用户确认进入哪条轨。不自动推进。
先判断任务类型：
当前是 RFC 探索模式？
├─ Yes → 执行 RFC 探索流程（Step E1-E5，参见上方 RFC 探索模式章节）
└─ No → 双轨分流（依 Step 1.5 扫描结果）：
├─ spec-kit 轨（存在匹配 spec，或非平凡变更需 spec 设计）
│ → 按 spec 产物推进：/speckit-plan | /speckit-tasks | /speckit-superspec-execute | /speckit-superspec-review
└─ vibe3 flow 轨（issue body 已明确，无 spec）
→ 标准实现流程：plan → run → review → publish（如下）
注意：
vibe3 plan/run/review是 issue-driven 自动化后端，通常不作为人机协作首选；spec/explore 阶段保持人机协作走 spec-kit 轨。openspec 不是本项目推荐工作流，统一用 spec-kit。
根据 flow 状态决定：
plan_ref 为空 → vibe3 plan
run_ref 为空 → vibe3 run
review_ref 为空 → vibe3 review
PR 未创建 → vibe3 run --publish
命令启动后，用 Monitor 监控完成信号（不要轮询等待）。
如果 vibe3 run 的 agent 遇到持续问题（rate limit、卡死、反复重试），不要无限等待，直接接管：
接管触发条件：
api_retry 且 error_status=429 超过 3 次接管流程：
tmux kill-session -t vibe3-executor-issue-<id>git diff）vibe3 handoff appendFallback：如果接管后实现遇到困难（上下文不足、能力限制），建议重新执行 vibe3 run（可能需要手动保存当前状态），而不是继续在当前 session 硬撑。
原则：vibe3 run 是便利工具，不是必须依赖。主 agent 有能力直接实现。
每个 Monitor 只服务一个命令。完成后立即清理：
启动命令 → 创建 Monitor → 等待事件
↓
Monitor 触发（命令完成/失败/超时）
↓
立即 TaskStop 清理该 Monitor
↓
进入审查流程
每次进入 Step 2 前，先检查并清理上一步的 Monitor：
ScheduleWakeup 同理：每次循环只保留一个 ScheduleWakeup。新循环开始时，上一个 ScheduleWakeup 应已被唤醒（或超时），不需要手动清理。
ScheduleWakeup 与 Monitor 的关系：
启动序列：启动命令 → 创建 Monitor → 设置 ScheduleWakeup 作为 fallback
禁止：
示例：
# Step 2: plan 完成后
Monitor triggered → TaskStop(monitor_id) # 清理 plan monitor
# 进入 Step 3 审查
# Step 2: 启动 run
New Monitor created for run
ScheduleWakeup set as fallback
每步完成后，必须审查并修正发现的问题。
读取 artifact
↓
逐项审查（范围、质量、测试、一致性）
↓
发现问题？
├─ 明确问题 → 直接修正 → 重新验证 → 报告修正内容
├─ 模糊问题 → 向用户报告 → 等待决策
└─ 无问题 → 报告结果
↓
进入下一步
读取 vibe3 handoff show @plan，审查：
修正 plan 后报告：
Plan 审查：
- 范围：完整 / 已补充 XX
- 修正：修正了 XX 问题（具体说明）
- 风险：低 / 中 / 高
- 状态：通过 → 继续 run
读取 vibe3 handoff show @report + 检查代码，审查：
重复修复限制：同一问题修正 2 次仍未解决 → 暂停，向用户报告（见 Step 4 和限制章节）
修正代码后报告：
Run 审查：
- 变更：N 个文件，+X/-Y 行
- 修正：修复了 XX（测试失败/逻辑错误/...）
- 测试：全部通过
- Plan 一致性：一致 / 有偏离（原因）
- 状态：通过 → 继续 review
读取 vibe3 handoff show @audit，审查：
vibe3 review 确认通过重复修复限制：同一问题修正 2 次仍未解决 → 暂停，向用户报告（见 Step 4 和限制章节）
修正后报告：
Review 审查：
- Verdict: PASS / 修正后 PASS / CONDITIONAL
- 修正：修复了 N 个阻塞项（列出）
- 遗留：M 个建议项（不阻塞）
- 状态：通过 → 继续 publish
报告：
PR 已创建：https://github.com/.../pull/XXXX
- CI：通过 / 修复中 / 失败（原因）
每步修正完成后，向用户报告修正了什么和当前状态：
标准实现流程报告：
Issue #XXXX 进度：
- [x] plan：通过（修正了 1 处范围遗漏）
- [x] run：通过（修复了 2 个测试失败）
- [ ] review：等待执行
- [ ] publish：等待
下一步：执行 vibe3 review
RFC 探索模式报告（见 RFC 探索模式章节的报告格式）。
只在以下情况询问用户：
不询问用户的情况（直接修正继续）：
回到 Step 2 执行下一步，直到 PR 创建完成。
vibe3 plan --branch <b> # 生成计划
vibe3 handoff show @plan --branch <b> # 读取计划
vibe3 run --branch <b> # 执行实现
vibe3 handoff show @report --branch <b> # 读取报告
vibe3 review --branch <b> # 代码审查
vibe3 handoff show @audit --branch <b> # 读取审查
vibe3 run --publish --branch <b> # 创建 PR
--branch 接受分支名或 issue 编号本项目双轨模型（spec-kit-workflow-standard.md）：spec-kit 轨为人机协作首选，vibe3 flow 轨为 issue-driven 自动化后端。
| 阶段 | spec-kit 轨（首选） | vibe3 flow 轨 |
|---|---|---|
| brainstorm / explore | /speckit-superspec-brainstorm | — |
| specify | /speckit-specify | — |
| plan | /speckit-plan | vibe3 plan |
| tasks | /speckit-tasks | — |
| implement | /speckit-superspec-execute | vibe3 run |
| review | /speckit-superspec-review | vibe3 review |
| publish | （经 vibe-spec-bridge after_* hooks 桥接 handoff） | vibe3 run --publish |
| RFC 探索模式 | 等效能力 |
|---|---|
| E1 Explore | spec-kit before_specify hook（graphify/mem-search/exa/ADR） |
| E2 Analyze (Grill Me) | 苏格拉底式质询 / 魔鬼代言人 |
| E3 Converge | 方案对比与收敛 |
| E4 Record | Issue comment / ADR 记录 |
openspec 不是本项目推荐工作流，spec/explore/plan/tasks/implement/review 统一走 spec-kit（
/speckit-*skills）。superpowers:*作为 cross-cutting 技能仍可使用，但项目工作流入口是 spec-kit + vibe3 双轨。