Menü
Use when retikz needs multiple independent LLMs to review the same fixed code, ADR, implementation plan, test contract, commit, or working-tree snapshot before a gate or delivery decision.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Use when changing any retikz apps/docs content, route data, i18n, demo, SourceLinks, or schema reference before loading the matching page-type skill.
Use when an Alpha ADR needs a pre-implementation capability gate, or a Beta milestone needs code-based completeness and package-boundary auditing.
Use when planning a retikz architecture direction, version roadmap, or alpha feature that may need a long-lived ADR before implementation.
Use when retikz work is primarily refactoring, reorganization, renaming cleanup, modularization, or internal simplification and should start from a reviewed implementation plan before code changes.
Use when retikz implementation, adversarial testing, and docs are complete, and an ADR or beta TODO needs changelog, contract consistency review, roadmap status updates, or final human acknowledgement.
Use when retikz alpha-stage work needs to execute an ADR-backed feature through long-lived design, reviewed implementation planning, code, adversarial testing, documentation, and wrapup.
| name | cross-review |
| description | Use when retikz needs multiple independent LLMs to review the same fixed code, ADR, implementation plan, test contract, commit, or working-tree snapshot before a gate or delivery decision. |
本 skill 用多个 fresh、相互独立的 reviewer 实例评审同一份固定快照，再由主 AI 归并、对齐和裁决。快照可以是 ADR、implementation plan、test contract、代码、diff、commit range 或发布范围。reviewer 必须看到相同输入，同轮并发且互不可见结论；优先使用不同模型，只有一个非主 agent 模型可用时使用两个同模型独立实例。
与 cross-test 区别：cross-test 通过测试打破实现；cross-review 只读审查固定材料。两者可以串联使用。
优先使用当前会话可调度的 collaboration subagent；没有该能力时再探测外部只读 CLI。模型名以工具当轮实际暴露为准，不硬编码不存在的模型。
| 评审员 | 调用 | 说明 |
|---|---|---|
| collaboration subagent | spawn_agent + 不同可用 model override | 首选；同轮并发，每个模型一个 fresh agent |
| codex CLI | codex exec review / codex exec | 外部只读通道；可用 -m <model> 选择实际可用模型 |
| claude headless 等外部 CLI | 对应只读命令 | 仅在本机真实可用时采用 |
探测命令：
for c in codex claude; do command -v $c >/dev/null && echo "available: $c"; done
PowerShell：
Get-Command codex, claude -ErrorAction SilentlyContinue | Select-Object Name, Source
至少有 2 个 fresh、独立上下文的外部 reviewer 实例完成才算 cross-review，主 agent 不算外部 reviewer。阵容按以下顺序选择：
subagent 必须避开主 agent 模型；不得派主 agent 同模型 subagent 填数。某名称未被工具暴露时必须跳过并如实记录，不得硬编码、伪造或静默换成主 agent 模型；调度能力支持时按风险与实际可用档位设置 reasoning_effort: high 至 max，并记录调度值与 reviewer 自报值。
| 范围 | 固定方式 |
|---|---|
| ADR / architecture design | 文件路径 + HEAD + 本轮内容 hash / diff |
| implementation plan | ADR、PLAN.md、TEST_CONTRACT.md + HEAD + 工作区摘要 |
| commit / range / staged | commit SHA、A..B、staged diff |
| 版本代码（tag / 分支） | tag / branch + 目标相对 base 的 diff |
| 固定代码块 / 当前工作区 | 文件清单或完整 uncommitted diff + HEAD + git status --short |
调用方必须给出固定范围和评审目标；不要默认全仓。Architecture / Plan Gate 的自动授权只来自根 AGENTS.md 与对应 flow，不由本 skill 自行扩张。
评审 ADR 时只检查长期内容：核心决策、基础数据结构 / 公开契约、功能边界、兼容性、被否决方案和架构完备性。不得要求 ADR 增加具体文件、私有命名、业务逻辑步骤、测试 case、命令、commit 切分或 review 过程。
评审 implementation plan 时检查：
TEST_CONTRACT.md 是否覆盖行为、不变量、反例、最低测试层和正式证据仅当固定快照包含实现代码、diff、commit 或 public surface 时使用本节。ADR Gate 只使用上方“文档评审方向”与 develop-completeness rubric；Plan Gate 只检查 ADR 追溯与实施可执行性，不得用代码 rubric 反向要求 ADR / plan 固定 Zod 拼装或私有命名。
代码评审把下列方向写进每个评审员的 prompt，保证各家可比、且贴合本仓规范。评审前把适用 AGENTS.md 关键规则随 prompt 一起给模型。按本轮代码范围与用户重点可取舍通用项，但必查四项默认都要过。
是否符合 AGENTS.md 代码规范——总纲，逐条对照。命名不缩写写全称（direction 不写 dir、reference 不写 ref、background 不写 bg…，TikZ/SVG/CSS 标准词如 stroke/fill/cx 除外）；目录与非组件文件使用 kebab-case，组件 / 类文件可使用 PascalCase；从目录 barrel import 不深入具体文件；数组用 Array<T> 不用 T[]；函数优先箭头；React 组件用 FC 注解 + 独立导出 Props 类型 + 在函数体内解构 props。
代码是否 LLM 友好——尤其 zod schema 描述与重要数据结构。每个 zod 字段都要有 .describe(...)（含顶层 object、type/kind 这类看似自描述的字段）；描述写含义与用途、不复述字段名、全英文、不中英混写——schema description 直接进 LLM tool definition，是给模型看的契约，必须完整无歧义。重要数据结构的命名与形状对模型是否自解释、模型能否据 description 自我纠错；schema 内部不写 JSDoc（说明全走 .describe），派生类型/常量/函数才写中文 JSDoc。
是否用 const 风格枚举，不裸用字符串——可枚举的取值集 / discriminated union 判别字段，必须用 as const 对象 + 派生类型（ValueOf），不用 TS enum，也不要在代码里散落裸字符串字面量当枚举值。命名走 DrawWay 风格（PascalCase 域前缀 + 成员、export 暴露给用户）；union 成员写 z.literal(X.Member)，整体 z.discriminatedUnion('type', [...])；成员值保持干净判别串，使裸字面量（{ type: 'point' }）仍是有效第一形态。揪出「该用 const 枚举却散字符串」「仍用 TS enum」的地方（旧 SCREAMING_SNAKE 是遗留写法，新代码按 DrawWay 风格）。
数据结构是否可靠——非法状态不可表达——有共现 / 互斥约束的字段，不能摊成一堆全可选字段。反例：{ x?, y?, a?, b? }，而语义要求 x、y 必须同时出现、a、b 必须同时出现。正确做法：① 拆成独立子结构再复合（{ point: { x, y } }）；② 互斥用 discriminated union 表达；③ 共现/条件约束用 zod .refine / .superRefine 校验——保证只要通过 schema 校验，生成的对象就一定有效。揪出「全可选 + 靠运行时假设字段成对出现」的脆弱结构，建议改成类型层面就排除非法组合（make illegal states unrepresentable）。
正确性
0 / 负数 / NaN / Infinity / 空数组 / 角度跨 360 / 极大极小值类型安全
as any / @ts-ignore / @ts-expect-error / 非必要 ! 绕过；让 zod / IR / 第三方真实类型穿透到调用点z.infer 派生不手写（单一真源，避免与 schema 漂移）；由 IR schema object 推导出的公开数据类型命名为 IRXxx，由 const object enum + ValueOf 推导出的取值 union 命名为 XxxValuez.any() / z.unknown() / 函数 / ReactNode分层与架构
type（顶层实体 / paint 变体）vs kind（类型内部子变体）用法是否符合约定一致性
可维护性 / 简洁性
性能
useId、marker dedup 等共享状态是否正确、有无泄漏或非确定性可测试性
git rev-parse HEAD # 记录基准 commit
git status --short # 工作区状态（评审未提交改动时尤其重要）
git --no-pager log --oneline -1
写明本轮编号、确切范围、HEAD、工作区摘要、文件清单与评审目标。ADR / plan 评审要给完整文件，不只给摘要。range 可用 git diff A..B 固定。
reasoning_effort: high 至 max，不写死单一档位。无法同时完成两个独立实例时暂停，不用主 agent 同模型 subagent 填位。fork_turns: "none" 或等价无历史上下文方式，由 prompt 完整传入固定材料。上一轮评审员不得携带旧结论进入新轮。所有评审员收到同一份 scope 与重点，并发启动；不能先等待一位完成再把其结论交给下一位。
collaboration subagent：每个实际可用模型一个 fresh agent，prompt 只给固定材料、适用规则、输出契约和只读限制。不要传主 AI 的预判、其它模型结论或期望答案。原始输出由会话保留；需要恢复记录时写入对应 ignored plan 的 REVIEW.md 或 notes/reports/。
外部 CLI 只作为无 collaboration 能力时的替代通道：
codex —— git 范围（commit / base / uncommitted），用专用 review 子命令：
# 某个 commit
codex exec review --commit <SHA> -m <model> -o notes/reports/cross-review-<scope>/codex-<model>.md
# 相对某分支/版本的改动
codex exec review --base <base-branch> -m <model> -o notes/reports/cross-review-<scope>/codex-<model>.md
# 工作区未提交改动（staged + unstaged + untracked）
codex exec review --uncommitted -m <model> -o notes/reports/cross-review-<scope>/codex-<model>.md
可在 [PROMPT] 位置追加自定义评审重点（如“重点看 IR schema 契约与 zod description 完整性”）。多模型就把上面命令换 -m 再跑一遍，输出文件名带上模型名区分。
codex —— 固定代码块（review 子命令只认 git 改动，固定块走通用 exec + 只读沙箱）：
codex exec -s read-only -m <model> -o notes/reports/cross-review-<scope>/codex-block-<model>.md \
"只读评审下列代码，禁止修改任何文件，只输出问题清单（按 严重/警告/提示 分级）：\n<把代码块或文件路径写进来>"
贴入的零散代码（不在仓库里）：先写进临时文件再让 codex 读，必要时 -C <dir> --skip-git-repo-check。
claude -p —— 独立一路（以下是 POSIX shell 示例；PowerShell 必须用原生命令生成文件并显式读取内容，不直接复制 $() / cat 写法）：
# 先按范围生成 diff 或取出代码，再喂给 claude
git --no-pager diff <range> > notes/reports/cross-review-<scope>/scope.diff
claude -p --model <model> \
--append-system-prompt "你是一个严格的代码评审员，只读评审，输出按 BLOCKING/WARNING/INFO 分级，每条给文件:行 与理由，不要复述代码。" \
"评审以下改动，挑出正确性 bug、设计问题、可维护性与一致性风险：\n$(cat notes/reports/cross-review-<scope>/scope.diff)" \
> notes/reports/cross-review-<scope>/claude.md
给所有评审员的统一评审重点见上方「评审方向」——把同一份重点写进每个评审员的 prompt，保证各家可比、贴合本仓规范（差异才来自模型本身而非 prompt 不同）。评审前最好把 AGENTS.md 关键规则摘要随 prompt 一起给模型，让外部模型按本仓规范评审而非通用直觉。
主 AI 把各家 finding 归并：
Array<T> 当问题）降级或剔除，并说明原因。裁决要克制：主 AI 是把关人，但对拿不准的不要硬下 BLOCKING，标 WARNING + “建议人工/cross-test 确认”。
一轮表示“同一快照上的一组并发多模型评审”，不是一个评审员：
最终回复给出分级报告。落盘优先级固定为：
develop-completeness 返回调用方，不写文件；主 AI 在内存中归并REVIEW.md其它 report 路径：
notes/reports/cross-review-YYYY-MM-DD-<scope>.md
<scope> 用简短 kebab-case。报告必须有三档，并且每条 finding 标注提出模型与共识 / 单点。其它报告放 notes/reports/ 或 _notes/reports/。这些文件默认不 stage、不 commit。
跑完后复核仓库未被改动：
git status --short # 应与评审前一致；codex/claude 评审不应改任何文件
# Cross Review Report: <scope>
日期：YYYY-MM-DD
评审范围：<commit SHA / range / tag / 文件路径 / uncommitted>
基准快照：HEAD=<sha>，工作区=<clean / 含未提交改动摘要>
评审重点：<正确性 / 契约 / 分层 / 一致性 …>
## 评审员阵容
| 评审员 | 模型 | 厂商 | 结果 |
| --------- | -------- | --------- | ------------- |
| codex | <model> | OpenAI | ok / 失败原因 |
| codex | <model2> | OpenAI | ok |
| claude -p | <model> | Anthropic | ok |
多样性说明：<是否跨厂商 / 跨模型；若为同模型 fresh 实例降级，写明局限>
## 结论概览
- 共识 BLOCKING：N 条
- 单点 / 分歧：N 条
- 一致认为良好的点：…
## BLOCKING（真实缺陷，需修）
| # | 位置(文件:行) | 问题 | 提出模型 | 共识/单点 | 主 AI 裁决 |
| --- | ------------- | ---- | -------- | --------- | ---------- |
## WARNING（不一定是 bug，但伤害体验/可维护性）
| # | 位置 | 观察 | 提出模型 | 共识/单点 | 建议动作 |
| --- | ---- | ---- | -------- | --------- | -------- |
## INFO（低优先级 / 一致认为没问题 / 清理点）
| # | 位置 | 观察 | 提出模型 |
| --- | ---- | ---- | -------- |
## 模型分歧明细
> 哪些点各家结论不一致，分别怎么说，主 AI 倾向哪边及理由。
## 后续沉淀
- 建议立即修：…
- 建议转 cross-test 写测试坐实：…
- 建议记入 plan / \_notes/decisions TODO：…
- 误报 / 已剔除（附原因）：…
无问题时也要明确写：
## BLOCKING
无（N 个模型均未提出阻断级问题）。
git status 复核。AGENTS.md 等用户授权。notes/reports/cross-review-YYYY-MM-DD-<scope>.md，且未 stage / commit 该 ignored 报告文件。git status 复核仓库未被评审过程改动。