session-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Session Review — the adversarial closing loop

会话审查——对抗式收尾循环

Stress-test a session's work before it sets, using reviewers who don't share your blind spots. You wrote the work, so you are the worst person to spot what you assumed. The loop ends in action: cheap-safe fixes applied immediately, the rest recorded as a measurable plan, and anything you disagree with explicitly challenged — not silently accepted, not silently dropped.

Invocation is usually EXPLICIT (

/session-review

) — "review" is something the agent does natively, so don't expect auto-triggering; invoke it by name at session close.

在会话成果“定型”前，利用与你存在不同盲区的审查者对其进行压力测试。你是成果的创作者，因此最难以发现自己的预设假设。本循环最终要落实到行动上：立即实施低成本、安全的修复方案，为剩余问题记录可衡量的计划，对任何不认同的内容明确提出质疑——既不默默接受，也不悄悄搁置。

触发方式通常为显式触发（

/session-review

）——“审查”是Agent的原生功能，因此不要指望自动触发；需在会话结束时明确调用该指令。

The loop

流程步骤

1. Assemble the brief (the load-bearing step)

1. 整理简报（核心支撑步骤）

Write ONE self-contained markdown brief (e.g. to

/tmp/<repo>-session-review.md

). It is the only context the reviewers get. It must contain:

An assigned role that fits the work ("Principal Engineer" for a feature slice, "Security reviewer" for auth work) — the role is the lens.
Project context a stranger can follow, the session goal, and what was built, with concrete file:line references.
The specific decision points you most want challenged — and for anything that turns on CURRENT best practice, an explicit ask to web-check with sources.
What to return — a structured verdict with severity, file refs, a short MEASURABLE plan.

Never let the brief be the reviewer's only window: tell the code-reader explicitly "do not trust this summary — read the actual files." Your summary is where your blind spots live.

撰写一份独立完整的Markdown简报（例如保存至

/tmp/<repo>-session-review.md

）。这是审查者获取的唯一上下文，必须包含：

指定角色：与工作内容匹配（例如，功能模块对应“首席工程师”，认证工作对应“安全审查员”）——角色是审查的视角。
项目上下文：让陌生人也能理解的项目背景、会话目标以及已完成的工作，并附上具体的文件:行号引用。
你最希望被质疑的特定决策点——对于任何依赖当前最佳实践的内容，明确要求通过网络核查并提供来源。
审查输出要求：一份包含严重性、文件引用、简短可衡量计划的结构化结论。

绝不能让简报成为审查者的唯一信息窗口：明确告知代码阅读器**“不要依赖此摘要——请读取实际文件。”**你的摘要中存在你的盲区。

2. Run the reviewers IN PARALLEL (same message)

2. 并行运行审查者（同一消息触发）

Reviewer A — the isolated code-reader. Spawn
```
idea-validator
```
pointed at the brief AND the actual files, with the currency instruction: "web-check whether every library / runtime / pattern I chose is still the right choice this year, cite sources." Without that line it only verifies claims you explicitly made — dated tech slips through.
Reviewer B — an external-family model (if available), reviewing from the brief only. Different training distribution, different blind spots; lean on it for concept and tech-currency, not file-level facts.
One reviewer alone (A) is still a valid light review — note the absence and proceed.

审查者A——独立代码阅读器。启动指向简报及实际文件的
```
idea-validator
```
，并附上时效性核查指令：“通过网络核查我选择的每个库/运行时/模式在今年是否仍是合适的选择，并引用来源。”如果没有这条指令，它只会验证你明确提出的主张——过时的技术会被遗漏。
审查者B——外部系列模型（若可用）：仅基于简报进行审查。这类模型的训练数据分布不同，盲区也不同；可依靠它进行概念和技术时效性审查，但不要用于文件级事实核查。
仅使用单个审查者（A）也属于有效的轻量审查——只需注明缺少审查者B即可继续流程。

3. Synthesize — agree vs diverge

3. 综合分析——共识与分歧

Where reviewers independently land on the same finding — high-confidence signal, promote it. Where they diverge — the highest-value rows: adjudicate on merits. On facts about the code the code-reader wins; never count votes. The full adjudication procedure — acceptance layers, the claim→check table, how a disputed finding is allowed to close — is

reference/orchestrator-fact-check.md

审查者独立得出相同结论的部分——属于高可信度信号，需重点跟进。存在分歧的部分——是最有价值的环节：根据实际情况进行裁决。对于代码相关事实，代码阅读器的结论具有权威性；绝不要以投票数定胜负。完整的裁决流程（包括接受层级、主张→核查表、争议结论的处理方式）详见

reference/orchestrator-fact-check.md

。

4. Act (the loop must end in action)

4. 采取行动（循环必须以行动收尾）

Accept now: cheap, safe, low-blast-radius fixes — apply this session, verify by artifact (typecheck / lint / tests), don't round toward success.
Plan, measured: larger items become backlog entries, each with a metric for the win. A plan item with no measurable outcome is a task for task's sake — drop it.
Challenge: for anything you disagree with, write back WHY. Holding your ground with a reason is the partnership — blind acceptance defeats the loop.

立即执行：低成本、安全、影响范围小的修复方案——在本次会话中实施，通过工件验证（类型检查/代码扫描/测试），不要刻意追求“成功”结果。
制定可衡量计划：较大的问题需纳入待办事项，每个事项都要有明确的成功指标。没有可衡量结果的计划项只是无意义的任务——应舍弃。
提出质疑：对于任何不认同的内容，书面说明原因。有理有据地坚持立场是协作的一部分——盲目接受会使本循环失去意义。

5. Measure the outcome

5. 衡量成果

Close with what the loop produced: findings found / applied / planned / challenged, what you had missed, what tech-currency facts updated. That's how you know it earned its tokens.

最后总结本循环产生的成果：发现的问题/已实施的修复/已制定的计划/已提出的质疑，你之前遗漏的内容，以及更新的技术时效性事实。通过这些内容判断本流程是否物有所值。

6. Retrospective on the machine (so quality compounds)

6. 系统回顾（让质量持续提升）

Steps 1-5 review the WORK; this reviews the SYSTEM that produced it. Three questions, backed by what actually happened this session:

What foundation element (a rule, a MEMORY line, a handoff, a pattern) EARNED its keep — name the concrete moment. Keep those.
Where did the foundation give friction or a gap — stale, duplicated, missing? Fix/merge/prune.
How did the orchestration go — right agents, good-enough briefs, honest adjudication? (
```
reference/parallel-development.md
```
for the fan-out defaults and stop-conditions.)

A CONFIRMED finding is worth a row in the findings-class registry, and a class recurring three times earns promotion into the cheapest layer that prevents it —

reference/review-loop.md

Output: at most 1-3 minimal, evidence-backed adjustments, biased to subtract before add. "Keep doing" is a valid output — most sessions should change the foundation little.

步骤1-5是对工作成果的审查；本步骤是对产生工作成果的系统进行审查。结合本次会话的实际情况，回答三个问题：

哪些基础要素（规则、MEMORY行、交接流程、模式）发挥了作用——指明具体场景。保留这些要素。
哪些基础要素产生了摩擦或存在缺口——过时、重复、缺失？进行修复/合并/删除。
编排流程表现如何——Agent选择是否恰当、简报是否合格、裁决是否公正？（详见
```
reference/parallel-development.md
```
中的并行展开默认设置和终止条件。）

已确认的问题需在问题分类注册表中添加一条记录；同一类问题出现三次后，需将其纳入能预防该问题的最低成本环节——详见

reference/review-loop.md

。

输出：最多1-3个基于证据的最小调整，优先删减而非新增。“继续执行当前操作”也是有效的输出——大多数会话无需大幅调整基础系统。

Guardrails

约束规则

Never blind-accept. Rejecting a finding with a reason is a success, not a failure.
Separate "now" from "plan" by RISK, not importance — big-blast-radius changes at the end of a long session belong in the plan, done fresh.
Scale to the work: small session → light brief, single reviewer; architecture change → the full role-assigned, fact-checked, multi-reviewer pass.

绝不要盲目接受。有理有据地拒绝结论是成功，而非失败。
根据风险而非重要性区分“立即执行”与“计划执行”——长会话结束时的大范围变更应纳入计划，留待后续处理。
根据工作规模调整流程：小型会话→精简简报、单个审查者；架构变更→完整的指定角色、事实核查、多审查者流程。