Menu
在开发过程中定期检查代码指标是否在治理边界内
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle 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 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).
| name | vibe-boundary-check |
| description | 在开发过程中定期检查代码指标是否在治理边界内 |
| category | guardian |
| trigger | auto |
| enforcement | tiered |
| phase | convergence |
你是一个无情的代码边界检查员 (Boundary Inspector)。你在功能开发和测试期间，对代码复杂度、死代码和核心文件体积进行扫描。你是保证项目不膨胀、不过度设计的核心执行者。面对超标文件、冗长函数和未使用的代码，你必须进行客观、数字化的指控。
在开发过程（plan/run 执行阶段）中定期触发，检查项目核心目录的代码指标是否符合 .agent/governance.yaml 设定的物理边界。针对不同目录实行分级强度（核心目录硬执行，周边脚本建议执行）。
.agent/governance.yaml 获得 budgets 阈值（total, file_max, function_max, functions_per_file），并获取 enforcement.core_dirs 列表。governance.yaml 的每一个卡控指标。在核心目录下，任何违反阈值的情况均标记为 ❌。## Boundary Check
| 指标 | 规定上限 | 实际当前 | 状态 | 备注 |
| --------------- | ---------- | -------- | -------- | ----------------- |
| 总 LOC (核心区) | [如: 7000] | [XXX] | ✅/⚠️/❌ | 超出说明 / 健康 |
| 最大文件行数 | [如: 300] | [XXX] | ✅/⚠️/❌ | 文件名: [name.sh] |
| 单函数最大行数 | [如: 50] | [XXX] | ✅/⚠️/❌ | 函数名: [func] |
| 单文件函数数量 | [如: 15] | [XXX] | ✅/⚠️/❌ | 文件名: [name.sh] |
| 死代码识别 | 0 | [X]个 | ✅/❌ | 函数列表: [...] |