vibe-coding-control-center

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).

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.

Use when installed skills are messy across IDEs, the user is unsure which skills exist globally vs project-level, needs to sync, clean, or recommend installed skills, is setting up a new worktree, or mentions "/vibe-skills-manager". Do not use for authoring or reviewing `skills/vibe-*` content.

Use when creating or reviewing a non-trivial spec-kit implementation plan to recall applicable accepted ADRs from docs/decisions/ and record a structured ADR Consideration artifact in the plan. Agent-only and low-code - scans ADR frontmatter (decides/scope) and reads candidate bodies only; no runtime command, database, scoring, embeddings, or RAG. Triggers at plan time (planned paths + issue/spec semantics) and at review time (actual merge-base diff reconciliation).

Use when the user wants a structured code review for local or PR-bound source changes, asks for a pre-PR implementation audit, or wants fixes validated against code review feedback. Do not use for docs-only review, concept governance, PR publishing, merging, or CI debugging.

Use only when the human explicitly invokes vibe-team-review or /vibe-team-review.

Use when the user wants to create, update, review, or audit a repo-local Vibe skill under `skills/`, mentions "/vibe-skill-audit", "vibe-skill", "vibe skill", "创建 skill", "审查 skill", "skill 文案", or "自动匹配语义", or needs a Vibe-specific wrapper around `skill-creator` rather than a generic cross-project skill workflow.

统一编排 Vibe Guard 流程，作为所有改代码动作的主路由。

代码修改后自动执行三层验证（Lint + 测试 + Review Gate），失败时循环修复（最多 3 轮）

Use when the user wants project-level roadmap planning, version goals, backlog triage, governance suggest review, or issue placement decisions. Triggered by "vibe roadmap", "/vibe-roadmap", "版本规划", "roadmap 审查", "消化 governance suggest", "下一个版本做什么", or "这个 issue 放哪一版". Do not use for assignee pool governance (use vibe-orchestra) or single-flow execution.

Use when the user wants to find suspicious redundant business logic, repeated implementation patterns, stale compatibility paths, or low-quality code that should be reviewed for consolidation, reuse, or retirement. Do not use for automatic cleanup or direct code deletion.

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).

Use when manager has signaled flow terminal state cleanup via handoff indicate. Reads cleanup instructions and executes FlowCleanupService. Do not use for code changes or PR creation.

Use when the current human-collaboration flow has reached terminal PR state and the user wants to do final closeout. Confirm PR outcome, close owned issues, check for follow-up needs, delete resources, and switch back to main. Do not use for code changes or abandoned work.

Use for handling blocked and RFC issues, making decisions that may form ADRs (Architecture Decision Records). Processes problem issues requiring human judgment, dependency resolution, and architectural decisions. Do not use for routine issue monitoring (use vibe-orchestra) or roadmap planning (use vibe-roadmap).

Use when rules files change, when checking for duplicate or conflicting rules across ~/.claude/rules/common/, .claude/rules/, and CLAUDE.md, or when an agent has created new rules that may overlap with existing ones. Do not use for skill authoring or flow governance.

Use when the user wants heartbeat-style governance over the issue pool. inspect running issues, judge which issue is worth starting next, backfill assignee-triggered candidates, and propose non-state label or routing actions. Do not use for single-flow execution governance, coding, or implementation work.

Use when the user wants to create or refine a GitHub issue. This is a human-facing intake entrypoint, not an automated workflow.

Use when checking orchestra service health, viewing serve running status, debugging vibe3 serve (orchestra server), checking whether a new serve debugging round is ready, inspecting agent execution logs in temp/logs/, diagnosing governance or manager chain failures, or identifying bugs in the heartbeat/dispatch pipeline. Triggered by "serve status", "orchestra service running", "FailedGate", "heartbeat", "serve health". Do not use for flow/task metadata repair (use vibe-check) or issue pool governance (use vibe-orchestra).

Use when the user wants to assess, unblock, and merge PRs. This is a human-facing convergence entrypoint that explains integration status and guides decisions, not an automated merge workflow.

在开发过程中定期检查代码指标是否在治理边界内

在 review 阶段执行全量合规检查，生成 PR 合规报告。

在新 flow 启动时检查新功能是否在项目范围内

Use when the user wants to review documentation changes, audit entry files or standards docs, check changelog quality, inspect concept drift in docs, or says "review docs" / "review documentation". Do not use for source-code implementation review.

Use when evaluating whether a project should continue, be refactored, rebuilt, forked, or abandoned — for both own projects and external/third-party codebases

定期检测项目是否偏离初衷。