review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/review

A second opinion before committing. Review checks alignment between intent and execution, detects drift, and decides: continue, adjust, or salvage.

This is part of the Intent > Execution > Review loop that runs at every scale--from a single commit to a multi-week project. Review closes the loop.

提交前的二次校验。Review会检查意图与执行结果是否一致，检测偏差，并决定后续动作：继续推进、调整方向或止损重构。

这是意图>执行>审查循环的一部分，该循环适用于所有规模的工作——从单次提交到持续数周的项目。审查环节用于闭环收尾。

When to Use

使用场景

Invoke

/review

when:

Before committing - natural checkpoint before code hits the branch
At natural pause points - end of a work session, end of a subtask
Something feels off - you've been coding a while and lost track of where you are
Scope seems to have grown - the task feels bigger than when you started
Before PRs - final check before requesting review from humans

Do not use when: You're in deep flow and making progress. Don't interrupt productive work. Review at natural breaks, not arbitrary intervals.

在以下场景中调用

/review

：

提交代码前——代码合并到分支前的自然检查点
自然停顿节点——工作时段结束、子任务完成时
感觉工作异常时——编码一段时间后，对当前进度失去把控
任务范围扩大时——实际任务量远超最初规划
发起PR前——请求人工审查前的最终检查

请勿在以下场景使用：正处于高效流畅的编码状态且进度顺利时。不要打断高效的工作流程，应在自然的休息节点进行审查，而非按固定间隔强制执行。

The Review Process

审查流程

Step 1: State the Original Aim

步骤1：明确初始目标

Before reviewing anything, restate what we set out to do:

"The aim was: [original intent in one sentence]"

If you can't state the aim clearly, that's the first finding. Go find it or clarify with the user before proceeding.

在开始审查前，重新明确我们最初的目标：

"初始目标为：[用一句话描述最初的意图]"

如果无法清晰表述目标，这就是第一个需要解决的问题。先找到或与用户确认目标后再继续。

Step 2: Check Alignment (Five Questions)

步骤2：一致性检查（五大问题）

Work through these checks against the original aim:

对照初始目标，逐一完成以下检查：

1. Still Necessary?

1. 是否必要？

Is this solving a real, current problem--not a hypothetical future one?

Are we building something that's actually needed right now?
Or did scope expand to "future flexibility" or premature optimization?

If unnecessary work crept in: "This adds [X] which wasn't part of the original aim."

当前工作是否在解决真实的、当下存在的问题——而非假设的未来问题？

我们正在开发的功能是当前真正需要的吗？
任务范围是否因考虑“未来扩展性”或过早优化而扩大？

如果发现不必要的工作：“本次新增了[X]，但这并非初始目标的一部分。”

2. Still Aligned?

2. 是否一致？

Is the work still pointed at the original aim?

Does what we're building actually address the stated problem?
Are we on the critical path, or did we drift to tangents?

Signs of drift:

"While I'm at it..."
Refactoring unrelated code
Solving problems the user didn't mention

If misaligned: "The aim was X, but current work addresses Y."

当前工作是否仍与初始目标对齐？

我们正在开发的内容是否真的能解决既定问题？
我们是否在推进关键路径的工作，还是偏离到了无关的支线任务？

偏差信号：

“顺手就把这个也改了...”
重构无关代码
解决用户未提及的问题

如果出现偏离：“初始目标是X，但当前工作在解决Y问题。”

3. Still Sufficient?

3. 是否适配？

Is the approach appropriately sized for the problem?

Could this be done with less code, fewer files, less abstraction?
Are we building infrastructure for a one-off task?

Complexity signals:

RED: 3+ files for simple feature; new patterns for one-offs
YELLOW: proliferating Manager/Handler/Service classes
GREEN: direct solution; one file when possible; reuses existing patterns

If over-complex: "A simpler approach would work. Consider [alternative]."

当前方案的复杂度是否与问题规模匹配？

是否能用更少的代码、更少的文件、更简单的抽象来实现？
我们是否在为一次性任务搭建复杂的基础设施？

复杂度信号：

红色预警：简单功能涉及3个以上文件；为一次性任务引入新架构
黄色预警：Manager/Handler/Service类数量激增
绿色正常：直接的解决方案；尽可能单文件实现；复用现有架构

如果过于复杂：“更简单的方案即可满足需求，可考虑[替代方案]。”

4. Mechanism Clear?

4. 机制是否清晰？

Can you articulate WHY this approach works?

Is there a clear "because" statement?
If the mechanism can't be stated simply, the problem may not be understood

If unclear: "What's the mechanism? Why will this solve the problem?"

你能否清晰说明该方案为何可行？

能否用一句“因为...”来解释？
如果无法简单说明机制，可能意味着对问题本身理解不到位

如果机制不清晰：“该方案的运行机制是什么？为何它能解决这个问题？”

5. Changes Complete?

5. 变更是否完整？

Are all ripple effects handled?

New fields initialized everywhere the struct is created?
Persistence changes have migration paths?
Contract changes updated in all callers?

If incomplete: "This adds [X] but doesn't update [related site]."

是否处理了所有连锁影响？

结构体新增的字段是否在所有实例化的位置都完成了初始化？
持久层变更是否有对应的迁移方案？
契约变更是否在所有调用方都完成了更新？

如果不完整：“本次新增了[X]，但未更新[相关关联部分]。”

Step 3: Detect Drift

步骤3：检测偏差

Drift is the gap between where you started and where you are. Explicitly name any drift found:

Scope Drift - The task grew beyond original boundaries Solution Drift - The approach changed from what was planned Goal Drift - The aim itself shifted without explicit decision

For each drift detected:

Drift: [type]
Started as: [original]
Became: [current]
Impact: [what this means]

偏差指的是初始状态与当前状态之间的差距。明确指出发现的所有偏差类型：

范围偏差——任务规模超出了最初的边界 方案偏差——实现方式偏离了最初的规划 目标偏差——目标本身在未经过明确决策的情况下发生了变更

对于检测到的每一种偏差，按以下格式记录：

偏差类型：[具体类型]
初始状态：[最初的内容]
当前状态：[现在的内容]
影响：[该偏差带来的后果]

Step 4: Decide Next Action

步骤4：决定后续动作

Based on the review, choose one:

Decision	When	Action
Continue	Aligned, on track	Proceed with confidence
Adjust	Minor drift, recoverable	Correct course and continue
Pause	Unclear aim or major questions	Stop, clarify with user, then resume
Salvage	Significant drift, restart needed	Extract learning with `/salvage` , then restart

根据审查结果，选择以下其中一种动作：

决策	适用场景	执行动作
继续推进	与目标一致，进度正常	放心推进工作
调整方向	存在轻微偏差，可修正	调整后继续推进
暂停工作	目标不明确或存在重大疑问	停止工作，与用户确认后再恢复
止损重构	存在严重偏差，需重启	运行 `/salvage` 提取经验后，重新开始

Output Format

输出格式

undefined

undefined

Review Summary

审查总结

Aim: [original intent] Status: [Continue / Adjust / Pause / Salvage]

初始目标： [最初的意图] 状态： [继续推进/调整方向/暂停工作/止损重构]

Alignment Check

一致性检查

Necessary: [Yes/No - brief note]
Aligned: [Yes/No - brief note]
Sufficient: [Yes/No - brief note]
Mechanism clear: [Yes/No - brief note]
Changes complete: [Yes/No - brief note]

是否必要：[是/否 - 简要说明]
是否一致：[是/否 - 简要说明]
是否适配：[是/否 - 简要说明]
机制是否清晰：[是/否 - 简要说明]
变更是否完整：[是/否 - 简要说明]

Drift Detected

检测到的偏差

[List any drift found, or "None detected"]

[列出所有偏差，或“未检测到偏差”]

Decision

决策理由

[Reasoning for the status decision]

[状态决策的依据]

Next Steps

后续步骤

[Concrete actions to take]

undefined

[具体执行动作]

undefined

Examples

示例

Example 1: Clean Review (Continue)

示例1：审查通过（继续推进）

/review

I've been working on the auth endpoint for 30 minutes.

Output:

undefined

/review

我已经花了30分钟开发认证接口。

输出：

undefined

Review Summary

审查总结

Aim: Add JWT validation to the /api/users endpoint Status: Continue

初始目标： 为/api/users接口添加JWT验证 状态： 继续推进

Alignment Check

一致性检查

Necessary: Yes - endpoint currently accepts any request
Aligned: Yes - implementing exactly what was specified
Sufficient: Yes - using existing auth middleware, minimal new code
Mechanism clear: Yes - middleware validates token, rejects invalid
Changes complete: Yes - endpoint updated, tests added

是否必要：是 - 该接口目前接受任意请求
是否一致：是 - 完全按照需求实现
是否适配：是 - 复用现有认证中间件，新增代码量极少
机制是否清晰：是 - 中间件验证token，拒绝无效请求
变更是否完整：是 - 接口已更新，测试用例已添加

Drift Detected

检测到的偏差

None detected

未检测到偏差

Decision

决策理由

Work is aligned and on track. JWT validation implemented using existing patterns.

工作内容与目标一致，进度正常。已使用现有架构完成JWT验证功能。

Next Steps

后续步骤

Run tests
Commit
Open PR

undefined

运行测试
提交代码
发起PR

undefined

Example 2: Drift Detected (Adjust)

示例2：检测到轻微偏差（调整方向）

/review

Started adding error handling to the API. Now I'm refactoring the logger.

Output:

undefined

/review

开始为API添加错误处理，现在正在重构日志系统。

输出：

undefined

Review Summary

审查总结

Aim: Improve error handling in /api/orders endpoint Status: Adjust

初始目标： 优化/api/orders接口的错误处理 状态： 调整方向

Alignment Check

一致性检查

Necessary: Partially - error handling yes, logger refactor no
Aligned: Drifted - logger refactor wasn't part of the aim
Sufficient: Over-scoped - touching infrastructure for a single endpoint
Mechanism clear: Yes for error handling, unclear for logger
Changes complete: No - error handling incomplete

是否必要：部分是 - 错误处理有必要，但日志重构无必要
是否一致：已偏离 - 日志重构并非初始目标的一部分
是否适配：范围过大 - 为单个接口修改基础设施
机制是否清晰：错误处理部分清晰，日志重构部分不清晰
变更是否完整：否 - 错误处理未完成

Drift Detected

检测到的偏差

Drift: Scope Drift Started as: Add try/catch and proper error responses to /api/orders Became: Refactoring the entire logging system Impact: Original task incomplete, unrelated system being modified

偏差类型：范围偏差初始状态：为/api/orders接口添加try/catch和标准错误响应当前状态：重构整个日志系统影响：初始任务未完成，无关系统被修改

Decision

决策理由

Revert logger changes. Complete the original error handling task. If logger needs work, that's a separate task.

回滚日志系统的修改，先完成最初的错误处理任务。如果日志系统确实需要优化，应作为独立任务处理。

Next Steps

后续步骤

```
git stash
```
the logger changes
Complete error handling for /api/orders
Commit that work
If logger refactor is still needed, create separate task

undefined

使用
```
git stash
```
暂存日志修改
完成/api/orders接口的错误处理
提交该部分工作
如果仍需重构日志系统，创建独立任务

undefined

Example 3: Major Drift (Salvage)

示例3：严重偏差（止损重构）

/review

Third attempt at fixing the build. Each fix breaks something else.

Output:

undefined

/review

第三次尝试修复构建问题，每次修复都会引发新的问题。

输出：

undefined

Review Summary

审查总结

Aim: Fix failing CI build (test timeout issue) Status: Salvage

初始目标： 修复CI构建失败问题（测试超时） 状态： 止损重构

Alignment Check

一致性检查

Necessary: Yes - build must pass
Aligned: No - now touching unrelated config
Sufficient: No - complexity increasing with each fix
Mechanism clear: No - unclear why tests timeout
Changes complete: No - in unstable state

是否必要：是 - 构建必须通过
是否一致：否 - 目前在修改无关配置
是否适配：否 - 每次修复都会增加复杂度
机制是否清晰：否 - 不清楚测试超时的原因
变更是否完整：否 - 工作处于不稳定状态

Drift Detected

检测到的偏差

Drift: Solution Drift Started as: Increase test timeout Became: Modifying test infrastructure, CI config, and mock setup Impact: Build in worse state than when started, root cause unknown

偏差类型：方案偏差初始状态：增加测试超时时间当前状态：修改测试基础设施、CI配置和模拟环境影响：构建状态比最初更差，根本原因未知

Decision

决策理由

Stop. The approach has reversed multiple times. Extract what was learned about the test infrastructure and restart with better understanding.

停止当前工作。方案已多次变更，应先提取关于测试基础设施的经验，在充分理解问题后重新开始。

Next Steps

后续步骤

Run
```
/salvage
```
to capture learnings
Revert to known-good state
Investigate root cause before attempting fix
Start fresh with clear hypothesis

undefined

运行
```
/salvage
```
记录经验
回滚到已知的稳定状态
在尝试修复前先调查根本原因
基于明确的假设重新开始

undefined

Session Persistence

会话持久化

This skill can persist context to

.oh/<session>.md

for use by subsequent skills.

If session name provided (

/review auth-refactor

Reads/writes
```
.oh/auth-refactor.md
```
directly

If no session name provided (

/review

After producing the review summary, offer to save it:

"Save to session? [suggested-name] [custom] [skip]"
Suggest a name based on git branch or the work being reviewed

Reading: Check for existing session file. Read Aim (what outcome we wanted), Problem Statement, Solution Space (approach taken), and Execute status. This is essential for detecting drift.

Writing: After review, write the assessment:

markdown

undefined

该技能可将上下文持久化到

.oh/<session>.md

，供后续技能调用。

如果指定了会话名称（如

/review auth-refactor

）：

直接读写
```
.oh/auth-refactor.md
```

如果未指定会话名称（如

/review

）：

生成审查总结后，会询问是否保存：

"是否保存到会话？[建议名称] [自定义] [跳过]"
会根据git分支或当前审查的工作内容建议会话名称

读取逻辑：检查是否存在会话文件，读取其中的目标（预期结果）、问题描述、解决方案范围（采用的实现方式）和执行状态。这对检测偏差至关重要。

写入逻辑：审查完成后，将评估结果写入文件：

markdown

undefined

Review

审查记录

Updated: <timestamp> Verdict: [ALIGNED | DRIFTED | BLOCKED]

[review findings, drift analysis, recommendations]

undefined

更新时间： <时间戳> 结论： [对齐/偏离/阻塞]

[审查发现、偏差分析、建议]

undefined

Adaptive Enhancement

自适应增强

Base Skill (prompt only)

基础版本（仅提示词）

Works anywhere. Produces review summary based on conversation context. No persistence.

可在任意环境使用。基于对话上下文生成审查总结，无持久化功能。

With .oh/ session file

搭配.oh/会话文件

Reads
```
.oh/<session>.md
```
for aim, constraints, selected solution
Compares actual work against session aim
Writes review verdict and findings to the session file

读取
```
.oh/<session>.md
```
中的目标、约束条件、选定的方案
将实际工作内容与会话中的目标进行对比
将审查结论和发现写入会话文件

With git diff

搭配git diff

Compares actual changes against stated aim
Detects file count, complexity signals
Identifies incomplete changes

将实际变更内容与既定目标对比
检测文件数量、复杂度信号
识别未完成的变更

With CI Integration

搭配CI集成

Checks if tests pass before marking complete
Verifies linting, type checking
Confirms PR checks would pass

在标记任务完成前检查测试是否通过
验证代码规范、类型检查结果
确认PR检查能否通过

With Open Horizons MCP

搭配Open Horizons MCP

Pulls related past decisions for context
Logs review outcomes to graph
Session file serves as local cache

拉取相关历史决策作为上下文
将审查结果记录到图谱
会话文件作为本地缓存

Completion Gate (Before "Done")

完成校验（标记“完成”前）

When the user or agent claims work is complete, verify:

PR Intent Clear? - Can you state what the PR delivers in one sentence?
Changes Reviewed? - Has the branch diff been reviewed against intent?
CI Passing? - Have automated checks been run and passed?
Feedback Addressed? - Have reviewer comments been resolved?

If incomplete:

"Completion gate: [missing step]. Run the check before marking complete."

当用户或Agent声称工作已完成时，需验证以下内容：

PR意图清晰？ - 能否用一句话说明该PR的交付内容？
变更已审查？ - 是否已对照初始目标审查分支的代码差异？
CI已通过？ - 自动化检查是否已运行并通过？
反馈已处理？ - 审查者的评论是否已全部解决？

如果有未完成的步骤：

"完成校验：缺少[步骤]。请先完成该检查再标记工作为完成。"

Position in Framework

在框架中的定位

Comes after:

/execute

(natural checkpoint after building). Leads to:

/ship

if aligned,

/salvage

if drifted, back to

/aim

if fundamentals are unclear. This is the gate: Review decides whether to continue, adjust, or restart.

前置环节：

/execute

（开发完成后的自然检查点） 后续环节： 若对齐则进入

/ship

，若偏离则进入

/salvage

，若基础目标不清晰则回到

/aim

核心作用： 审查环节决定了后续是继续推进、调整方向还是重新开始。

Leads To

后续流向

After review, typically:

Continue - Proceed to commit, PR, or next task
Adjust - Make corrections, then continue
Salvage - Run
```
/salvage
```
to extract learning before restart
Clarify - Return to
```
/aim
```
or
```
/problem-statement
```
if fundamentals unclear

Remember: Review is not bureaucracy. It's the moment you catch drift before it compounds. Five minutes of review saves hours of wrong-direction work.

审查完成后，通常会进入以下环节：

继续推进 - 提交代码、发起PR或进入下一个任务
调整方向 - 修正问题后继续推进
止损重构 - 运行
```
/salvage
```
提取经验后重新开始
确认目标 - 若基础目标不清晰，回到
```
/aim
```
或
```
/problem-statement
```
环节

注意： 审查不是形式主义，而是在偏差扩大前及时发现的关键环节。五分钟的审查能避免数小时的无效工作。