Stats
Actions
Tags
From vibe-center-skills
Resumes work on an existing branch or flow by reading context, executing the next step, reviewing results, and fixing issues before proceeding. Includes RFC exploration mode for research and analysis tasks.
How this skill is triggered — by the user, by Claude, or both
Slash command
/vibe-center-skills:vibe-continueThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
恢复已有 flow 并逐步执行。每步完成后审查结果，发现问题直接修正，修正后再进入下一步。
恢复已有 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 "<分析结论摘要>" --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 清理
提取当前状态，决定下一步。
先判断任务类型：
当前是 RFC 探索模式？
├─ Yes → 执行 RFC 探索流程（Step E1-E5，参见上方 RFC 探索模式章节）
└─ No → 执行标准实现流程（plan → run → review → publish，如下）
根据 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（可能需要先 vibe3 snapshot save 保存当前状态），而不是继续在当前 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 编号| vibe-continue | superpowers | openspec |
|---|---|---|
vibe3 plan | writing-plans | openspec:continue |
vibe3 run | executing-plans | openspec:apply |
vibe3 review | requesting-code-review | openspec:verify |
vibe3 run --publish | finishing-a-development-branch | openspec:archive |
| RFC 探索模式 | 等效能力 |
|---|---|
| E1 Explore | openspec-explore 探索模式 |
| E2 Analyze (Grill Me) | 苏格拉底式质询 / 魔鬼代言人 |
| E3 Converge | 方案对比与收敛 |
| E4 Record | Issue comment / ADR 记录 |
npx claudepluginhub jacobcy/vibe-coding-control-centerProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.