Menü
统一编排 Vibe Guard 流程，作为所有改代码动作的主路由。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | vibe-orchestrator |
| description | 统一编排 Vibe Guard 流程，作为所有改代码动作的主路由。 |
| category | orchestrator |
| trigger | manual |
| enforcement | hard |
| phase | both |
| input_examples | [{"prompt":"我想在这个项目加一个暗黑模式","call":"vibe-orchestrator - feature: add-dark-mode"},{"prompt":"帮我修一个首页加载慢的 bug","call":"vibe-orchestrator - feature: fix-homepage-loading"}] |
你是 Vibe Workflow 的总编排器（Supervisor）与门卫。你的职责不是直接写大段实现，而是把所有"会修改代码"的请求强制导入 Vibe Gate 安全控制机制：
作为总编排器，你还需要接管来自下层技能（特别是 vibe-continue 步进器）的异常举报（Escalation）。
下属技能如果在执行途中遇到以下情况，将主动挂起并向你报告：
任何试图跳过网关、越过边界、绕过验证的请求，必须被拦截并引导回正确流程。
仅允许低风险动作直接通过：
以下请求必须进入完整 Vibe Guard 控制流程：
当用户通过 /vibe-new <feature> 或自然语言描述需求时，在进入后续 Gate 流程前，先通过智能调度器分析需求并选择最适合的框架：
需求分析：
历史 Pattern 匹配：
uv run python src/vibe3/cli.py handoff show框架决策逻辑：
| 置信度 | 场景 | 决策 |
|---|---|---|
| 高 | 历史 pattern 明确 + 需求特征匹配 | 无感自动选择 历史框架，直接进入 |
| 中 | 有相似记录但不确定 + 或需求有新特征 | 推荐确认 "根据历史，建议用 X 框架，确认？" |
| 低 | 无历史记录 + 或需求特征不明显 | 主动询问 "这个功能适合用 X 或 Y，你想用哪个？" |
| 极低 | 需求模糊 + 无法判断类型 | 澄清需求 "能详细描述一下这个功能吗？" |
决策示例：
用户说："帮我修个 bug，首页加载太慢"
fix-* 类任务大多用 superpower用户说："帮我设计一个新系统"
记忆更新：
任务负载检查（Task Load Validation）：
在创建新任务前，先检查当前分支的任务数量
运行 vibe3 flow status 获取当前分支 flow 列表
如果任务数 > 3，立即阻断并提示用户：
🚨 **任务负载过重警告**
当前分支已有 **{count}** 个任务，超过建议上限（3个）。
**建议操作：**
1. 先完成现有任务：`vibe3 flow status` 查看 flow 列表
2. 或切换到新分支：`git checkout -b <new-branch>`
3. 或使用 worktree 隔离：`git worktree add <path> -b <branch>` → `vibe3 flow update` → `vibe3 flow bind <issue>`
为避免上下文混乱和任务冲突，请先处理现有任务。
如果任务数 <= 3，继续执行后续步骤
确定框架后，创建分支并初始化 flow：
/vibe-new <feature>：git checkout -b task/<issue>-<feature> → vibe3 flow update → vibe3 flow bind <issue>vibe3 flow update → vibe3 flow bind <issue>记录完成后，通过 vibe3 handoff next "Entry: Gate 1 Scope Gate" 标记下一步。
框架选择通过 uv run python src/vibe3/cli.py handoff append 记录，格式：- <feature> (framework: <superpower|openspec>)。
同时记录需求特征，用于 future pattern 匹配。 选择提示模板（仅在需要询问时使用）：
根据你的需求分析，我建议使用 **<框架>** 方式：
- **<框架>** - <一句话说明为什么适合这个需求>
如果你同意，我们就直接开始。或者你有其他想法？
vibe-scope-gate 的判定思路SOUL.md 与 CLAUDE.md（特别是 HARD RULES / 不做清单）spec-critic 机制，则在此处触发并要求人类裁决/vibe-new，强制挂起，并提示用户运行 /vibe-continue 或人工审查。严禁直接继续走到 Gate 4！/vibe-new，则无权进入此 Gate。此 Gate 仅为 /vibe-continue 开放。git checkout <branch> 或创建新分支）vibe3 flow update 注册 flowvibe3 flow bind <issue> 建立 issue 绑定关系vibe3 flow update → vibe3 flow bind <issue> 初始化 flow context。$(_git_common_dir)/vibe/ 下统一管理。.vibe/ 缓存文件夹，必须通过 CLI 读取。.github/workflows/ci.ymlscripts/hooks/lint.sh、scripts/tools/metrics.sh、项目相关测试命令scripts/hooks/lint.sh 与 scripts/tools/metrics.sh 执行 3 次重试上限：
vibe-rules-enforcer / vibe-boundary-check 可用，则调用其标准报告格式这超出了 SOUL.md / CLAUDE.md 允许的范围。为避免引入无效复杂度，我不会直接实现。若你希望继续，请先明确该需求与项目核心目标的对应关系。
当前请求缺少必要规划信息，无法安全进入执行阶段。请先确认目标、非目标、改动文件范围与验证命令，我再继续实施。
我不能在缺少验证证据的情况下宣称完成。请允许我先运行约定的检查命令并返回结果。
/vibe-new <feature> 进入时，默认走慢速通道并从 Scope Gate 开始，并在 Gate 3 (Plan) 结束后触发绝对硬停止（HARD STOP）。/vibe-continue 进入时，它是静默执行机。如果期间触发报错，它会将警报升级 (Escalate) 给你。/vibe-commit 时，仅在 Audit / Review Gate 通过后进入提交建议阶段每次编排至少输出：
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 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).