vibe

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Vibe Skill

Purpose: Is this code ready to ship?

Two steps:

Complexity analysis — Find hotspots (radon, gocyclo)
Council validation — Multi-model judgment

用途： 这段代码是否可以发布？

两个步骤：

复杂度分析 — 找出代码热点（使用radon、gocyclo工具）
评审委员会验证 — 多模型判断

Quick Start

快速开始

bash

/vibe                                    # validates recent changes
/vibe recent                             # same as above
/vibe src/auth/                          # validates specific path
/vibe --quick recent                     # fast inline check, no agent spawning
/vibe --deep recent                      # 3 judges instead of 2
/vibe --mixed recent                     # cross-vendor (Claude + Codex)
/vibe --preset=security-audit src/auth/  # security-focused review
/vibe --explorers=2 recent               # judges with explorer sub-agents
/vibe --debate recent                    # two-round adversarial review

bash

/vibe                                    # 验证最近的变更
/vibe recent                             # 与上述命令功能相同
/vibe src/auth/                          # 验证指定路径下的代码
/vibe --quick recent                     # 快速在线检查，不启动Agent
/vibe --deep recent                      # 启用3位评审员（默认是2位）
/vibe --mixed recent                     # 跨供应商评审（Claude + Codex）
/vibe --preset=security-audit src/auth/  # 以安全为重点的评审
/vibe --explorers=2 recent               # 搭配探索子Agent进行评审
/vibe --debate recent                    # 两轮对抗式评审

Execution Steps

执行步骤

Step 1: Determine Target

步骤1：确定目标范围

If target provided: Use it directly.

If no target or "recent": Auto-detect from git:

bash

undefined

如果指定了目标路径： 直接使用该路径。

如果未指定目标或使用"recent"： 通过Git自动检测：

bash

undefined

Check recent commits

检查最近的提交

git diff --name-only HEAD~3 2>/dev/null | head -20


If nothing found, ask user.

**Pre-flight: If no files found:**
Return immediately with: "PASS (no changes to review) — no modified files detected."
Do NOT spawn agents for empty file lists.

git diff --name-only HEAD~3 2>/dev/null | head -20


如果未找到任何内容，询问用户。

**预检查：如果未找到文件：**
直接返回结果："通过（无需要评审的变更）——未检测到修改的文件。"
不要为空文件列表启动Agent。

Step 2: Run Complexity Analysis

步骤2：运行复杂度分析

Detect language and run appropriate tool:

For Python:

bash

undefined

检测代码语言并运行对应工具：

针对Python：

bash

undefined

Check if radon is available

检查radon是否可用

mkdir -p .agents/council echo "$(date -Iseconds) preflight: checking radon" >> .agents/council/preflight.log if ! which radon >> .agents/council/preflight.log 2>&1; then echo "⚠️ COMPLEXITY SKIPPED: radon not installed (pip install radon)"

Record in report that complexity was skipped

else

Run cyclomatic complexity

radon cc <path> -a -s 2>/dev/null | head -30

Run maintainability index

radon mi <path> -s 2>/dev/null | head -30 fi


**For Go:**
```bash

mkdir -p .agents/council echo "$(date -Iseconds) preflight: checking radon" >> .agents/council/preflight.log if ! which radon >> .agents/council/preflight.log 2>&1; then echo "⚠️ 复杂度分析已跳过：未安装radon（执行pip install radon安装）"

在报告中记录复杂度分析已跳过

else

运行圈复杂度分析

radon cc <path> -a -s 2>/dev/null | head -30

运行可维护性指数分析

radon mi <path> -s 2>/dev/null | head -30 fi


**针对Go：**
```bash

Check if gocyclo is available

检查gocyclo是否可用

echo "$(date -Iseconds) preflight: checking gocyclo" >> .agents/council/preflight.log if ! which gocyclo >> .agents/council/preflight.log 2>&1; then echo "⚠️ COMPLEXITY SKIPPED: gocyclo not installed (go install github.com/fzipp/gocyclo/cmd/gocyclo@latest)"

Record in report that complexity was skipped

else

Run complexity analysis

gocyclo -over 10 <path> 2>/dev/null | head -30 fi


**For other languages:** Skip complexity with explicit note: "⚠️ COMPLEXITY SKIPPED: No analyzer for <language>"

**Interpret results:**

| Score | Rating | Action |
|-------|--------|--------|
| A (1-5) | Simple | Good |
| B (6-10) | Moderate | OK |
| C (11-20) | Complex | Flag for council |
| D (21-30) | Very complex | Recommend refactor |
| F (31+) | Untestable | Must refactor |

**Include complexity findings in council context.**

echo "$(date -Iseconds) preflight: checking gocyclo" >> .agents/council/preflight.log if ! which gocyclo >> .agents/council/preflight.log 2>&1; then echo "⚠️ 复杂度分析已跳过：未安装gocyclo（执行go install github.com/fzipp/gocyclo/cmd/gocyclo@latest安装）"

在报告中记录复杂度分析已跳过

else

运行复杂度分析

gocyclo -over 10 <path> 2>/dev/null | head -30 fi


**针对其他语言：** 跳过复杂度分析并明确说明："⚠️ 复杂度分析已跳过：无对应语言的分析工具"

**结果解读：**

| 评分 | 评级 | 操作建议 |
|-------|--------|--------|
| A (1-5) | 简单 | 良好 |
| B (6-10) | 中等 | 可接受 |
| C (11-20) | 复杂 | 标记后提交评审委员会 |
| D (21-30) | 非常复杂 | 建议重构 |
| F (31+) | 不可测试 | 必须重构 |

**将复杂度分析结果纳入评审委员会的参考上下文。**

Step 2a: Run Constraint Tests

步骤2a：运行约束测试

If the project has constraint tests, run them before council:

bash

undefined

如果项目包含约束测试，在提交评审委员会前先运行：

bash

undefined

Check if constraint tests exist (Olympus pattern)

检查是否存在约束测试（Olympus模式）

if [ -d "internal/constraints" ] && ls internal/constraints/*_test.go &>/dev/null; then echo "Running constraint tests..." go test ./internal/constraints/ -run TestConstraint -v 2>&1

If FAIL → include failures in council context as CRITICAL findings

If PASS → note "N constraint tests passed" in report


**Why:** Constraint tests catch mechanical violations (ghost references, TOCTOU races, dead code at entry points) that council judges miss. Proven by Argus ghost ref in ol-571 — council gave PASS while constraint test caught it.

Include constraint test results in the council packet context. Failed constraint tests are CRITICAL findings that override council PASS verdict.

if [ -d "internal/constraints" ] && ls internal/constraints/*_test.go &>/dev/null; then echo "正在运行约束测试..." go test ./internal/constraints/ -run TestConstraint -v 2>&1

如果测试失败 → 将失败结果作为关键发现纳入评审委员会上下文

如果测试通过 → 在报告中记录"已通过N项约束测试"


**原因：** 约束测试可以捕捉到评审委员会容易遗漏的机械性违规问题（如幽灵引用、TOCTOU竞争、入口点处的死代码）。在ol-571的Argus幽灵重构案例中，评审委员会给出了通过结论，但约束测试却发现了问题。

将约束测试结果纳入评审委员会的数据包上下文中。失败的约束测试属于关键发现，将覆盖评审委员会给出的通过结论。

Step 2b: Metadata Verification Checklist (MANDATORY)

步骤2b：元数据验证清单（必填）

Run mechanical checks BEFORE council — catches errors LLMs estimate instead of measure:

File existence — every path in
```
git diff --name-only HEAD~3
```
must exist on disk
Line counts — if a file claims "N lines", verify with
```
wc -l
```
Cross-references — internal markdown links resolve to existing files
Diagram sanity — files with >3 ASCII boxes should have matching labels

Include failures in council packet as

context.metadata_failures

(MECHANICAL findings). If all pass, note in report.

在提交评审委员会前运行机械检查——捕捉大语言模型容易估算错误而非精确测量的问题：

文件存在性 —
```
git diff --name-only HEAD~3
```
中的每个路径必须在磁盘上存在
行数验证 — 如果文件声称有"N行"，通过
```
wc -l
```
命令验证
交叉引用检查 — 内部Markdown链接需指向存在的文件
图表示合理性 — 包含超过3个ASCII框图的文件需有匹配的标签

将检查失败的内容作为

context.metadata_failures

（机械性发现）纳入评审委员会数据包。如果全部通过，在报告中记录。

Step 2c: Deterministic Validation (Olympus)

步骤2c：确定性验证（Olympus）

Guard: Only run when

.ol/config.yaml

exists AND

which ol

succeeds. Skip silently otherwise.

If OL project detected: run

ol validate stage1 --quest <quest-id> --bead <bead-id> --worktree .

passed: false
→ Auto-FAIL the vibe. Do NOT proceed to council.
passed: true
→ Include Stage1Result in council context. Proceed normally.
Error/non-zero exit → Note "SKIPPED (ol error)" in report. Proceed to council.

触发条件： 仅当

.ol/config.yaml

存在且

which ol

命令执行成功时运行。否则静默跳过。

如果检测到是OL项目：运行

ol validate stage1 --quest <quest-id> --bead <bead-id> --worktree .

passed: false
→ 自动判定Vibe失败。不提交至评审委员会。
passed: true
→ 将Stage1Result纳入评审委员会上下文。正常继续流程。
报错/非零退出码 → 在报告中记录"已跳过（ol工具报错）"。继续提交至评审委员会。

Step 2.5: Codex Review (if available)

步骤2.5：Codex评审（如果可用）

Run a fast, diff-focused code review via Codex CLI before council:

bash

echo "$(date -Iseconds) preflight: checking codex" >> .agents/council/preflight.log
if which codex >> .agents/council/preflight.log 2>&1; then
  codex review --uncommitted > .agents/council/codex-review-pre.md 2>&1 && \
    echo "Codex review complete — output at .agents/council/codex-review-pre.md" || \
    echo "Codex review skipped (failed)"
else
  echo "Codex review skipped (CLI not found)"
fi

If output exists, include in council packet as additional context:

json

"codex_review": {
  "source": "codex review --uncommitted",
  "content": "<contents of .agents/council/codex-review-pre.md>"
}

This gives council judges a Codex-generated review as pre-existing context — cheap, fast, diff-focused. It does NOT replace council judgment; it augments it.

Skip conditions:

Codex CLI not on PATH → skip silently
```
codex review
```
fails → skip silently, proceed with council only
No uncommitted changes → skip (nothing to review)

在提交评审委员会前，通过Codex CLI运行快速、针对代码差异的评审：

bash

echo "$(date -Iseconds) preflight: checking codex" >> .agents/council/preflight.log
if which codex >> .agents/council/preflight.log 2>&1; then
  codex review --uncommitted > .agents/council/codex-review-pre.md 2>&1 && \
    echo "Codex评审完成 — 输出文件路径：.agents/council/codex-review-pre.md" || \
    echo "Codex评审已跳过（执行失败）"
else
  echo "Codex评审已跳过（未找到CLI工具）"
fi

如果生成了输出文件，将其作为额外上下文纳入评审委员会数据包：

json

"codex_review": {
  "source": "codex review --uncommitted",
  "content": "<contents of .agents/council/codex-review-pre.md>"
}

这将为评审委员会提供Codex生成的评审结果作为前置参考——成本低、速度快、聚焦代码差异。它不会替代评审委员会的判断，仅作为补充。

跳过条件：

Codex CLI不在PATH中 → 静默跳过
```
codex review
```
执行失败 → 静默跳过，仅提交至评审委员会
无未提交的变更 → 跳过（无内容可评审）

Step 2d: Search Knowledge Flywheel

步骤2d：搜索知识飞轮

bash

if command -v ao &>/dev/null; then
    ao search "code review findings <target>" 2>/dev/null | head -10
fi

If ao returns prior code review patterns for this area, include them in the council packet context. Skip silently if ao is unavailable or returns no results.

bash

if command -v ao &>/dev/null; then
    ao search "code review findings <target>" 2>/dev/null | head -10
fi

如果ao工具返回了该领域之前的代码评审模式，将其纳入评审委员会数据包上下文。如果ao工具不可用或未返回结果，静默跳过。

Step 3: Load the Spec (New)

步骤3：加载规格文档（新增）

Before invoking council, try to find the relevant spec/bead:

If target looks like a bead ID (e.g.,
```
na-0042
```
):
```
bd show <id>
```
to get the spec

Search for plan doc:

ls .agents/plans/ | grep <target-keyword>

Check git log:
```
git log --oneline | head -10
```
to find the relevant bead reference

If a spec is found, include it in the council packet's

context.spec

field:

json

{
  "spec": {
    "source": "bead na-0042",
    "content": "<the spec/bead description text>"
  }
}

在调用评审委员会前，尝试查找相关的规格/bead文档：

如果目标看起来是bead ID（例如：
```
na-0042
```
）：执行
```
bd show <id>
```
获取规格文档

搜索计划文档：

ls .agents/plans/ | grep <target-keyword>

检查Git日志：
```
git log --oneline | head -10
```
查找相关的bead引用

如果找到规格文档，将其纳入评审委员会数据包的

context.spec

字段：

json

{
  "spec": {
    "source": "bead na-0042",
    "content": "<the spec/bead description text>"
  }
}

Step 4: Run Council Validation

步骤4：运行评审委员会验证

With spec found — use code-review preset (3 judges):

/council --deep --preset=code-review validate <target>

```
error-paths
```
: Trace every error handling path. What's uncaught? What fails silently?
```
api-surface
```
: Review every public interface. Is the contract clear? Breaking changes?
```
spec-compliance
```
: Compare implementation against the spec. What's missing? What diverges?

The spec content is injected into the council packet context so the

spec-compliance

judge can compare implementation against it.

Without spec — 3 independent judges (no perspectives):

/council --deep validate <target>

3 independent judges (no perspective labels). Vibe uses

--deep

by default (3 judges) for consistency with /pre-mortem and /post-mortem, but users can override with

--quick

(inline single-agent check) or

--mixed

(cross-vendor with Codex).

Council receives:

Files to review
Complexity hotspots (from Step 2)
Git diff context
Spec content (when found, in
```
context.spec
```
)

All council flags pass through:

--quick

(inline),

--mixed

(cross-vendor),

--preset=<name>

(override perspectives),

--explorers=N

--debate

(adversarial 2-round). See Quick Start examples and

/council

docs.

找到规格文档时 — 使用代码评审预设（3位评审员）：

/council --deep --preset=code-review validate <target>

```
error-paths
```
：追踪每个错误处理路径。哪些错误未被捕获？哪些会静默失败？
```
api-surface
```
：评审每个公共接口。契约是否清晰？是否有破坏性变更？
```
spec-compliance
```
：将实现与规格文档对比。哪些内容缺失？哪些内容偏离？

规格文档内容会被注入到评审委员会数据包上下文中，以便

spec-compliance

评审员可以将实现与规格进行对比。

未找到规格文档时 — 3位独立评审员（无指定视角）：

/council --deep validate <target>

3位独立评审员（无视角标签）。为了与/pre-mortem和/post-mortem保持一致，Vibe默认使用

--deep

参数（3位评审员），但用户可以通过

--quick

（在线单Agent检查）或

--mixed

（跨供应商搭配Codex）覆盖默认设置。

评审委员会收到的内容：

需要评审的文件
复杂度热点（来自步骤2）
Git差异上下文
规格文档内容（如果找到，在
```
context.spec
```
中）

所有评审委员会的参数都可传递：

--quick

（在线）、

--mixed

（跨供应商）、

--preset=<name>

（覆盖视角）、

--explorers=N

、

--debate

（两轮对抗式）。请查看快速开始示例和

/council

文档。

Step 5: Council Checks

步骤5：评审委员会检查要点

Each judge reviews for:

Aspect	What to Look For
Correctness	Does code do what it claims?
Security	Injection, auth issues, secrets
Edge Cases	Null handling, boundaries, errors
Quality	Dead code, duplication, clarity
Complexity	High cyclomatic scores, deep nesting
Architecture	Coupling, abstractions, patterns

每位评审员需检查以下方面：

检查维度	检查要点
正确性	代码是否实现了声称的功能？
安全性	注入攻击、认证问题、敏感信息泄露
边界情况	空值处理、边界值、错误处理
代码质量	死代码、重复代码、代码清晰度
复杂度	高圈复杂度分数、深层嵌套
架构	耦合度、抽象设计、设计模式

Step 6: Interpret Verdict

步骤6：解读评审结论

Council Verdict	Vibe Result	Action
PASS	Ready to ship	Merge/deploy
WARN	Review concerns	Address or accept risk
FAIL	Not ready	Fix issues

评审委员会结论	Vibe最终结果	操作建议
通过	可以发布	合并/部署
警告	存在需要关注的问题	解决问题或接受风险
失败	不可发布	修复问题

Step 7: Write Vibe Report

步骤7：生成Vibe报告

Write to:

.agents/council/YYYY-MM-DD-vibe-<target>.md

markdown

undefined

报告路径：

.agents/council/YYYY-MM-DD-vibe-<target>.md

markdown

undefined

Vibe Report: <Target>

Vibe报告：<目标范围>

Date: YYYY-MM-DD Files Reviewed: <count>

日期： YYYY-MM-DD 评审文件数量： <数量>

Complexity Analysis

复杂度分析

Status: ✅ Completed | ⚠️ Skipped (<reason>)

File	Score	Rating	Notes
src/auth.py	15	C	Consider breaking up
src/utils.py	4	A	Good

Hotspots: <list files with C or worse> Skipped reason: <if skipped, explain why - e.g., "radon not installed">

状态： ✅ 已完成 | ⚠️ 已跳过（<原因>）

文件	评分	评级	备注
src/auth.py	15	C	考虑拆分
src/utils.py	4	A	良好

热点文件： <列出评级为C及以下的文件> 跳过原因： <如果跳过，说明原因 - 例如："未安装radon">

Council Verdict: PASS / WARN / FAIL

评审委员会结论：通过 / 警告 / 失败

Judge	Verdict	Key Finding
Error-Paths	...	... (with spec — code-review preset)
API-Surface	...	... (with spec — code-review preset)
Spec-Compliance	...	... (with spec — code-review preset)
Judge 1	...	... (no spec — 3 independent judges)
Judge 2	...	... (no spec — 3 independent judges)
Judge 3	...	... (no spec — 3 independent judges)

评审员	结论	关键发现
错误路径评审员	...	...（有规格文档时 — 使用代码评审预设）
API接口评审员	...	...（有规格文档时 — 使用代码评审预设）
规格合规性评审员	...	...（有规格文档时 — 使用代码评审预设）
评审员1	...	...（无规格文档时 — 3位独立评审员）
评审员2	...	...（无规格文档时 — 3位独立评审员）
评审员3	...	...（无规格文档时 — 3位独立评审员）

Shared Findings

共同发现

Concerns Raised

提出的问题

Recommendation

建议

<评审委员会的建议>

Decision

决策

[ ] SHIP - Complexity acceptable, council passed [ ] FIX - Address concerns before shipping [ ] REFACTOR - High complexity, needs rework

undefined

[ ] 发布 - 复杂度可接受，评审委员会已通过 [ ] 修复 - 发布前解决问题 [ ] 重构 - 复杂度过高，需要重构

undefined

Step 8: Report to User

步骤8：向用户反馈结果

Tell the user:

Complexity hotspots (if any)
Council verdict (PASS/WARN/FAIL)
Key concerns
Location of vibe report

告知用户以下内容：

复杂度热点文件（如果有）
评审委员会的结论（通过/警告/失败）
关键问题
Vibe报告的路径

Step 9: Record Ratchet Progress

步骤9：记录棘轮进度

After council verdict:

If verdict is PASS or WARN:
- Run:
```
ao ratchet record vibe --output "<report-path>" 2>/dev/null || true
```
- Suggest: "Run /post-mortem to capture learnings and complete the cycle."
If verdict is FAIL:
- Do NOT record. Tell user to fix issues and re-run /vibe.

评审委员会给出结论后：

如果结论是通过或警告：
- 执行：
```
ao ratchet record vibe --output "<report-path>" 2>/dev/null || true
```
- 建议："执行/post-mortem以捕获经验教训并完成整个流程。"
如果结论是失败：
- 不记录。告知用户修复问题后重新运行/vibe。

Integration with Workflow

与工作流的集成

/implement issue-123
    │
    ▼
(coding, quick lint/test as you go)
    │
    ▼
/vibe                      ← You are here
    │
    ├── Complexity analysis (find hotspots)
    └── Council validation (multi-model judgment)
    │
    ├── PASS → ship it
    ├── WARN → review, then ship or fix
    └── FAIL → fix, re-run /vibe

/implement issue-123
    │
    ▼
（编码过程中，随时进行快速lint/测试）
    │
    ▼
/vibe                      ← 当前步骤
    │
    ├── 复杂度分析（找出热点）
    └── 评审委员会验证（多模型判断）
    │
    ├── 通过 → 发布
    ├── 警告 → 评审后决定发布或修复
    └── 失败 → 修复问题后重新运行/vibe

Examples

示例

Validate Recent Changes

验证最近的变更

bash

/vibe recent

Runs complexity on recent changes, then council reviews.

bash

/vibe recent

对最近的变更运行复杂度分析，然后由评审委员会进行评审。

Validate Specific Directory

验证指定目录

bash

/vibe src/auth/

Complexity + council on auth directory.

bash

/vibe src/auth/

对auth目录运行复杂度分析和评审委员会验证。

Deep Review

深度评审

bash

/vibe --deep recent

Complexity + 3 judges for thorough review.

bash

/vibe --deep recent

复杂度分析 + 3位评审员进行全面评审。

Cross-Vendor Consensus

跨供应商共识评审

bash

/vibe --mixed recent

Complexity + Claude + Codex judges.

bash

/vibe --mixed recent

复杂度分析 + Claude + Codex评审员。

Relationship to CI/CD

与CI/CD的关系

Vibe runs:

Complexity analysis (radon, gocyclo)
Council validation (multi-model judgment)

CI/CD runs:

Linters
Tests
Security scanners
Build

Developer workflow:
  /vibe recent → complexity + judgment

CI/CD workflow:
  git push → lint, test, scan → mechanical checks

Both should pass before shipping.

Vibe执行的内容：

复杂度分析（radon、gocyclo）
评审委员会验证（多模型判断）

CI/CD执行的内容：

代码检查器（Linters）
测试
安全扫描器
构建

开发者工作流：
  /vibe recent → 复杂度分析 + 智能判断

CI/CD工作流：
  git push → 代码检查、测试、扫描 → 机械性检查

两者都通过后才能发布。

Consolidation

冲突解决

For conflict resolution between agent findings, follow the algorithm in

.agents/specs/conflict-resolution-algorithm.md

如果Agent的发现存在冲突，请遵循

.agents/specs/conflict-resolution-algorithm.md

中的算法进行解决。