| name | vibe-check |
| description | Use for deep inspection of single flow when automated processes fail. Human intervention for complex flow/task binding issues, runtime state inconsistencies, and manual diagnosis. Do not use for routine monitoring (use vibe3 task status) or system-level debugging (use vibe-debug-serve). |
/vibe-check - Flow Deep Inspection & Manual Intervention
单 flow 深入检查与人工接手，用于自动化流程无法处理的复杂问题诊断与修复。
When to Use
使用 vibe-check 的场景：
-
自动化流程失败：
- Orchestra heartbeat 无法自动恢复的 blocked issues
vibe3 task resume 无法解决的复杂绑定问题- Flow/task state 严重不一致，需要人工判断
-
深度诊断需求：
- 单个 flow 的 runtime 绑定问题
- Worktree/branch/flow 三者关系混乱
- 需要理解具体错误原因，而非简单恢复
-
复杂修复场景：
- 需要跨多个 worktree 做一致性判断
- 需要结合 PR/issue 历史做语义判断
- 自动修复会丢失重要上下文时
Do NOT use for:
- 常规运行时监控 → 使用
vibe3 task status
- 系统/服务层调试 → 使用
/vibe-debug-serve
- 问题 issue 处理 → 使用
/vibe-task
核心职责
现场观察与修复分三类命令：
vibe3 task status：看 orchestra 与 task 现场（首选入口）uv run python src/vibe3/cli.py flow status / flow show：看当前或特定 flow 详细信息（补充）uv run python src/vibe3/cli.py check：只检查 flow 与 task 是否同步uv run python src/vibe3/cli.py task resume ...：清除 blocked 状态，恢复 issue 到 ready（非破坏性，保留 worktree）
vibe-check skill 负责：
- 读取审计输出
- 做业务判断
- 只修复
task <-> flow / runtime 绑定与 auto-task scene recovery 问题
- 只通过 Shell API 执行安全修复
vibe-check 是 runtime / recovery audit，不承担 task-centered audit。
对象约束：
- 任何修复都必须先读 shell 审计输出，再决定动作
故障归类边界
vibe-check 必须先判断现场是否是 flow/block 问题，还是 serve/system 问题。
属于 flow/block 问题：
- business blocked reason、dependency block、human block
- task / flow / branch / worktree 绑定缺失或残留
- terminal flow 仍残留 runtime binding
- orphan auto task scene 需要
flow rebuild 或 cleanup 回到可恢复起点
属于 serve/system 问题：
- dispatcher / heartbeat / frozen queue 行为异常
- role handler 或 ExecutionCoordinator 派发失败
- worktree 创建异常发生在 serve dispatch 链路中
- FailedGate、error_log、
serve status 中的系统错误
如果证据指向 serve/system，vibe-check 只报告边界并转交 /vibe-debug-serve；
不要把系统错误写成 business blocked reason，也不要在 flow repair 中扩展新机制。
Announce at start: "我正在使用 vibe-check 技能读取 runtime 现场与审计结果，并在可确定时通过 Shell API 修复共享状态问题。"
项目命令参考见 skills/vibe-instruction/SKILL.md
真源边界
共享真源与本地事实边界以 docs/standards/v3/command-standard.md 为准；skill 只读取 shell 暴露的 flow / task / handoff 审计结果，不直接读取底层 JSON / SQLite。
禁止：
- skill 直接编辑
.git/vibe/*.json
- 把
.agent/context/task.md 当作共享真源
- 把
uv run python src/vibe3/cli.py check 扩展成默认自动修复器
执行流程
Step 1: 先读现场
优先运行：
vibe3 task status
如果需要看当前分支或特定 flow 详细信息，再补：
uv run python src/vibe3/cli.py flow status
uv run python src/vibe3/cli.py flow show
这一层回答的是：
- 当前有哪些 active / ready / blocked issues
- 当前分支是不是已注册 flow
- auto task scene 和 manual scene 是否异常
Step 2: 再做同步审计
当且仅当需要确认 flow 与 task 是否同步时，再运行：
uv run python src/vibe3/cli.py check
check 的职责是审计同步性，不是默认的“看现场”入口，也不是默认自动修复器。
职责边界
vibe-check 只处理：
- task runtime 指向不存在的 worktree
- 已完成 / 已归档 task 仍残留 runtime 绑定
- 当前现场绑定与 task runtime 的确定性修复
- 需要把其他 auto-created task/issue-* 现场回退到 ready / blocked recovery 起点
- 基于 shell 输出可直接确认的 flow/task 状态缺失提示
vibe-check 不处理：
task <-> issue 对应关系修复- task 未链接 issue 的规划问题
- task 应该归属于哪个 issue 的语义判断
- GitHub Issue intake、模板补全、查重与创建
flow/task 绑定的 task issue 只能作为审计证据或转交依据，不得在 skill 内重写成 GitHub 官方身份。
前三项属于 vibe-task 的审计/修复范围。
其中：
- Issue intake 与 GitHub 创建属于
vibe-issue
- 此 skill 中的
worktree 只表示物理目录容器，不表示 runtime 主体；runtime 主语仍是 task <-> flow / branch 绑定
Step 3: 分类问题
把问题分成三类：
A. 可确定自动修复
满足以下条件才可自动修复：
- shell 已提供原子命令
- 修复目标唯一
- 不需要语义猜测
当前允许的确定性修复：
completed/archived task still has runtime binding: <task-id>
- 修复命令：仅限当前
vibe3 check 默认模式已经明确支持的最小修复
- 当前目录承载的 flow 就是目标 task 的确定性现场
- 修复命令：仅限当前
vibe3 check 默认模式已经明确支持的最小修复
- 其他 auto task flow 需要恢复 blocked 状态
- 修复命令：
uv run python src/vibe3/cli.py task resume <issue-number> --label auto ...
B. 需要用户确认
以下情况不允许直接修：
runtime points to missing worktree: <task-id>:<worktree-name>
- shell 能发现缺口，但无法仅凭审计结果判断应解绑还是重绑
- 要不要重建其他 issue 的 auto task scene
- shell 有
flow rebuild 能力，但需要用户确认具体 issue
- 需要从 PR / 评论 / 文档语义推断 task 完成度
- 需要在多个 worktree / task 之间做语义匹配
此时必须向用户展示：
C. shell 能发现但不能修
如果发现问题但缺少原子能力，例如：
- 现场记录需要删除或改成
missing/stale，但 shell 没有单独的 flow 修复 API
- 需要跨多个 worktree 做事务修复，但 shell 只有单 task 写入口
则必须停止并明确报告 shell 能力缺口。
Step 4: 执行修复
对 A 类问题，只调用当前真实存在的 shell 命令，不做 JSON / SQLite 直写：
uv run python src/vibe3/cli.py check
uv run python src/vibe3/cli.py task resume <issue-number> --label auto --yes
如果命令失败：
- 立即停止该条修复
- 记录失败命令和错误
- 不继续假设状态已同步
Step 5: 重新验证
修复后必须重新运行：
vibe3 task status
vibe3 flow status
vibe3 check
Step 6: 报告
最终报告固定包含：
- 审计结论
- 已执行的 shell 命令
- 修复成功项
- 需用户确认项
- shell 能力缺口
输出示例：
📋 Vibe Check Report
已自动修复：
- completed/archived task still has runtime binding: 2026-03-08-foo
command: uv run python src/vibe3/cli.py check
需要确认：
- runtime points to missing worktree: 2026-03-08-bar:wt-old
reason: shell 无法仅凭审计结果判断应解绑还是重绑
验证结果：
- uv run python src/vibe3/cli.py check -> clean
Step 7: 留痕（Trace）
完成诊断和修复后，根据当前环境留痕：
判断环境：
vibe3 flow show
留痕规则：
-
有 flow 环境：使用 handoff 记录诊断结果和修复动作
vibe3 handoff append "[vibe-check] <诊断结论摘要>" --actor vibe-check --kind audit
-
无 flow 但有 issue：在 issue 中记录诊断结果
gh issue comment <issue-number> --body "## vibe-check 诊断结果
<诊断结论摘要>
**已执行修复**：<修复命令列表>
**需确认项**：<需要用户确认的问题>
"
-
都没有：无需留痕
留痕内容应包含：
- 诊断结论
- 已执行的修复命令
- 需要用户确认的问题
- shell 能力缺口（如有）
与其他命令的关系
vibe3 task status：主现场看板，优先用于看 orchestra / task runtimeuv run python src/vibe3/cli.py flow status / flow show：flow 现场读取uv run python src/vibe3/cli.py check：只负责检查 flow 和 task 是否同步uv run python src/vibe3/cli.py task resume：只清除 blocked 状态并恢复 label，不删除现场/vibe-check：基于上述命令解释 runtime 审计结果并编排最小修复/vibe-task：处理 task 与元数据审计修复
