在 OpenBot 的 pstack 技能包中，interrogate负责把一次代码变更分发给多个异构模型并行挑刺，再由主评审收敛成可执行的结论。这套流程的质量上限，几乎完全由分发给每个评审子代理的那份提示词决定。本文以模板文件 reviewer-prompt.md 为核心，讲清它的占位符契约、逐段设计意图、填充方法，并结合仓库中真实的打包与安装源码，说明这份模板在 OpenBot 里是如何被改名、分发和校验的。

模板在 interrogate 技能中的位置

interrogate不是一个单文件提示词，而是一个由四个文件协作的目录结构：

marketplace/production-catalog/bundles/pstack/skills/interrogate/ ├── SKILL.md └── references/ ├── reviewer-prompt.md # 本文主角：评审子代理的提示词模板 ├── rubric.md # 填充 {RUBRIC_CONTENTS} ├── code-quality-review.md # 填充 {CODE_QUALITY_CONTENTS} └── lead-judgment.md # 只给主评审读，不进入子代理提示词

各文件的职责边界非常清晰，值得先说清楚，否则很容易误把lead-judgment.md也塞进子代理的提示词里：

依据 SKILL.md 的 Step 3 与 Step 5：前三者用于填充模板，第四个只在收敛阶段由主评审阅读。这个划分是整篇模板能够保持"纯粹对抗"的前提。

模板原文与五个槽位

模板本身只有六十余行，但每一段都承担明确职责。以下为完整原文（保留英文，便于直接复制使用）：

You are an adversarial code reviewer. Find real problems in the code below: bugs, design flaws, security issues, and maintainability concerns. You are not here to be helpful or encouraging. You are here to stress-test. ## Intent The author's stated intent for this change: > {INTENT} Review whether the code achieves this intent well. Do NOT question the intent itself. Assume the goal is correct and challenge the execution. ## Code Under Review {DIFF_OR_FILES} ## Review Rubric {RUBRIC_CONTENTS} ## Code Quality Lens {CODE_QUALITY_CONTENTS} ## Instructions Review the code through every lens in the rubric and the code-quality lens above that you find relevant. Do not force lenses that don't apply. A simple bug fix does not need paragraphs about architectural integrity. For each finding, provide: 1. **Severity**: `critical` | `warning` | `nit` 2. **Finding**: What the problem is, in concrete terms. Reference specific lines/functions. 3. **Evidence**: Why you believe this is a problem. Show your reasoning. Don't just assert. 4. **Suggestion** (optional): What you'd do instead, only if you have a concrete alternative. A good finding references specific code, not vague concerns ("this could be better"). It distinguishes between "this is broken" and "I would have done this differently". It considers the stated intent. A finding that ignores the context of what's being built is a bad finding. Do not restate what the code does without identifying a problem. Do not praise the code. If you find nothing wrong, say "no findings" and stop. An empty review is a valid outcome. ## Output Return your findings as a structured list: ## Findings ### 1. [Severity] Short title **Location**: file:line or function name **Finding**: What's wrong **Evidence**: Why this matters **Suggestion**: (optional) What to do instead

模板共有四个占位符、一个上下文块，共五个可变量：

有一点容易忽略：{RUBRIC_CONTENTS}与{CODE_QUALITY_CONTENTS}应当直接嵌入两份参考文件的正文。若为了节省 token 把它们压缩成"请检查正确性、安全性"之类的一句话，评审者就失去了逐条透镜的触发点，输出会立刻退化为泛泛而谈。这一点在 SKILL.md 里有明确要求：对每一个评审者填入同一份模板，内容为意图、diff 或文件内容、rubric 以及 code-quality lens。

逐段拆解：为什么这段提示词能产生有效信号

角色锚定：明确禁止"帮忙"和"鼓励"

开头两句是全模板最锋利的地方：

You are not here to be helpful or encouraging. You are here to stress-test.

通用助手的默认倾向是配合、肯定、给建议。对抗式评审需要的恰恰相反：只报问题。模板随后用三条禁令把这个倾向钉死：

• Do not restate what the code does without identifying a problem.—— 禁止复述代码功能。这是评审输出里最常见的注水方式。
• Do not praise the code.—— 禁止表扬。
• If you find nothing wrong, say "no findings" and stop.—— 给"零发现"一个合法出口。

最后一条尤其重要。如果没有明确许可，评审者会倾向于凑数：找不到真问题就抬高级别或编造问题。把空结果定义为有效结果，才能让主评审在收敛阶段信任"某模型确实没发现问题"这一信号。

Intent 前置且不可质疑：把"目标"与"执行"分离

## Intent段先声明作者意图，紧跟一条硬约束：

Review whether the code achieves this intent well. Do NOT question the intent itself. Assume the goal is correct and challenge the execution.

这条约束解决的是多模型评审中最常见的跑题：模型开始质疑"这个功能该不该做""这个需求方向不对"，而不是"实现是否达成目标"。把意图固定为公理，评审火力就全部落在实现层。

模板还特别说明A finding that ignores the context of what's being built is a bad finding.——脱离上下文的"发现"不算发现。这与 lead-judgment.md 中"Missing Context Signals"一节形成呼应：子代理只看到代码切片，主评审拥有完整对话上下文，因此上下文相关的裁决必须留给主评审。

两级透镜：rubric 负责"找什么"，code-quality 负责"重构到什么程度"

模板注入了两套互补的透镜，而不是一套。这个设计值得展开，因为它是模板能同时覆盖"正确性"和"结构质量"的关键。

rubric.md 提供六个经典审查维度：

1. Correctness（正确性）：空输入、nil/undefined、边界值、并发访问；错误是被捕获、传播还是静默吞掉；off-by-one、类型强制转换、整数溢出、字符串编码；竞态、过期闭包、悬垂引用；happy path 与 sad path；幂等性（重复执行或中途崩溃会留下什么状态）；并发访问是否结构化串行化（锁、顺序阶段、独占所有权），还是依赖不会成立的约定。
   • 该维度还附了一条方法论：When you find a potential bug, trace the execution path. Don't just flag "this could be nil". Show the call chain that makes it nil.—— 必须给出使变量为 nil 的调用链，而不是抛出一句"这里可能为 nil"。
2. Root Causes vs. Symptoms（根因与症状）：修复的是真问题还是掩盖症状。典型反模式包括：掩盖更深层不变量违背的 guard clause、隐藏契约破损的重试逻辑、掩盖建模错误的类型断言、只存在于注释里的"约定"。该节还鼓励跳出改动文件，用 Read/Grep/Glob 追踪调用者与被调用者。
3. Structural Integrity（结构完整性）：边界处一次性校验而非散落业务逻辑；抽象层级是否混杂；耦合是否增加未来改动成本；数据结构是否匹配实际访问模式；新需求若一开始就知道，代码是否还会长成现在这样；是否留下"legacy 双路径"（新增 API 却保留旧 API，在没有外部消费者时应当同一波迁移并删除）。
4. Verification（可验证性）：测试是否测行为而非实现细节；有无回归断言；bug fix 是否配了复现测试；跨集成边界的路径是否被完整测试；是否用 mtime 或缓存状态去"代理"真实值；异步/委派工作是否校验真实产物，而不是相信自我报告。
5. Complexity Budget（复杂度预算）：本可更简单的代码；只服务一个调用点的抽象；为不存在的场景预留的参数化；死代码与残留参数；为"以防万一"写的分支；迁移完成后仍保留的兼容脚手架。
6. Security（安全）：用户输入流向危险 sink（SQL、shell、eval、innerHTML）未经净化；新端点缺少鉴权；代码、日志、错误信息中的密钥；安全关键路径上的 TOCTOU。每个安全结论都要求把输入路径追出来并展示。

code-quality-review.md 提供的是另一类标准——它不是"找 bug"，而是"找结构性退化"。它开宗明义要求评审者"对代码结构保持野心"，主动搜索"code judo"：在保持行为不变的前提下，让实现显著更简单、更小、更直接、更优雅的重构。

它的基线提示词是：

Perform a deep code quality audit of the current branch's changes. Rethink how to structure / implement the changes to meaningfully improve code quality without impacting behavior. Work to improve abstractions, modularity, reduce Spaghetti code, improve succinctness and legibility. Be ambitious, if there is a clear path to improving the implementation that involves restructuring some of the codebase, go for it. Be extremely thorough and rigorous. Measure twice, cut once.

其八个维度（编号 0–7）覆盖：

• 0. 结构性简化优先：不要停在"这里能再干净一点"，要寻找能让整批分支、辅助函数、模式、条件、层消失的重新表述。
• 1. 文件规模护栏：不允许一个 PR 把文件从 1k 行以下推到 1k 行以上而不给出极强理由；优先抽出 helper、子组件或模块。
• 2. 禁止意大利面增长：对插入无关流程的新增临时条件、散落特例、一次性分支保持怀疑，把它当设计问题而非风格小瑕。
• 3. 倾向清理设计而非接受"能跑"：行为不变但结构明显更干净时，推更干净的版本；优先删除活动部件，而非把同样的复杂度摊开。
• 4. 直接、朴素优于魔法：警惕隐藏简单数据形状假设的通用机制；标记只增加间接层的薄抽象、身份包装、透传 helper。
• 5. 类型与边界整洁：质疑不必要的可选性、unknown、any、大量 cast；偏好显式类型模型；用静默兜底掩盖不清不变量时，要求把边界显式化。
• 6. 逻辑留在规范层：指出特性逻辑渗入共享路径、实现细节从 API 泄漏；优先复用既有规范工具，而不是就地造一个一次性实现。
• 7. 顺序编排与原子性：独立工作无缘无故串行化是设计味道；相关更新可能半途生效时，推更原子的结构。

该文件还定义了明确的通过门槛（Approval Bar）：行为看似正确不足以放行；以下情形默认视为阻塞项——存在能删掉大量偶然复杂度的 code-judo 机会却被保留、文件跨过 1000 行、把临时分支缠进既有流程、在共享代码里散落特性检查、新增不必要的抽象/包装/cast 密集契约、在已有明确规范归属时重复 helper 或放错层。

这两套透镜的组合，使同一个子代理既会指出"这个 guard 掩盖了不变量违背"，也会指出"这次改动把文件推过了 1000 行"。

严重级别：三档且带判定标准

模板把发现分为三档，并在括号内给出判定口径：

三档而非五档，是为了让主评审在收敛阶段能快速分桶。注意warning的定义刻意包含"暂未爆"的正确性问题——这类问题往往是最有价值、也最容易被普通审查漏掉的一类。

输出契约：四字段结构

每个发现必须包含：

1. Severity
2. Finding：具体是什么问题，引用具体行/函数
3. Evidence：为什么相信这是个问题，展示推理，不要只下结论
4. Suggestion（可选）：只有存在具体替代方案时才给

模板对Suggestion的可选性做了强调：only if you have a concrete alternative。这一条抑制了"我要是写会不一样"式的空建议——而这正是 lead-judgment.md 点名的最常见误报：

A finding that amounts to "I prefer a different approach" is not a bug, not a design flaw, and not actionable unless the reviewer shows a concrete problem with the current approach.

模板末尾给出了机器可解析的输出骨架：

## Findings ### 1. [Severity] Short title **Location**: file:line or function name **Finding**: What's wrong **Evidence**: Why this matters **Suggestion**: (optional) What to do instead

固定字段名并保留file:line位置，是为了让主评审在 Step 4 合并时能做结构化解析与去重：**Location**提供合并键，**Innovation**之外的**Finding**提供语义比对，而**Evidence**决定这条发现是否有资格进入 "Act On"。模板还有一句评价标准，值得单独抄进团队规范：

It distinguishes between "this is broken" and "I would have done this differently".

从模板到一次真实运行：五个步骤的填充方法

SKILL.md 给出了前两步的取材规则，直接决定模板能否被填好。

Step 1，Scope（确定审查范围）

• 用户点名了文件或 diff：直接用。
• 在特性分支上：跑git diff main...HEAD（或对应的基础分支），取完整变更集。
• 用户消息提到最近的工作：收集相关文件。

然后Package the diff or file contents with any surrounding context files the reviewers need to understand the code.—— 对{DIFF_OR_FILES}而言，裸 diff 常常不够。评审者需要看到类型定义、被调用的兄弟模块、以及让 diff 成立的上游校验，否则就会产生"这里可能为 null"式的假阳性。这一步的取舍直接对应 lead-judgment.md 的 "Hypothetical vs. Actual" 原则：调用点能不能真的传 null，取决于你是否把调用点一起给了评审者。

Step 2，Intent（写定意图）

在派发评审者之前，用一段清晰的话写出意图，素材来自用户消息、commit message、PR 描述（若有）以及代码本身。若不确定意图，先问用户再继续。这段话就是{INTENT}的全部内容，它会以引用块形式出现在子代理提示词中。

一个可用的填充示例（示意，非仓库真实变更）：

## Intent > 本次改动让 readAgent 在 skill 目录的 SKILL.md 缺少 frontmatter 时返回结构化的 > problem 字段，而不是抛出异常，从而让调用方能把该技能标记为不可用并继续列出其余技能。 > 目标是不改变成功路径的行为，也不改变 problem 的取值集合。

注意这段文字的形态：只讲目标与不变量，不讲实现方案。因为实现方案正是要被挑刺的对象。

Step 3，Spawn Reviewers（并行派发）

同一轮消息里用 Task 工具启动全部评审者，每个对应~/.cursor/rules/pstack-models.mdc中interrogate reviewers行的一个条目，按条目数量依次标记 Reviewer A、B……。若规则文件或该行缺失，使用默认表：

每个评审者的参数固定为subagent_type: generalPurpose、readonly: true，model设为其配置条目或默认值。当条目为auto或inherit-parent时省略model，让该评审者跑在父模型上。

模型不可用时的降级链在 SKILL.md 中定义得相当细：

1. Task 工具拒绝某个配置条目 → 该评审者改用同族默认值（族按前缀判定：claude-*、grok-*），并说明此事。
2. 无族匹配 → 使用 Reviewer A 的默认值。
3. 连默认值也被拒 → 从其错误信息中的合法 slug 里选同族、同推理档位的最接近者，并另开 PR 更新默认表。
4. 不要因为 slug 问题阻塞评审；auto/inherit-parent这类别名永远不算被拒绝的 slug，也不触发任何回退。

这里有一条容易误读但很关键的设定：The adversarial signal comes from model diversity, not assigned personas.对抗信号来自模型差异，而非分配人设。因此同一个模板原样填给每个评审者，唯一变化的是模型。这也解释了为什么模板里没有任何"你是安全专家""你是性能专家"的角色设定——那是另一种（更弱的）多样性来源。

Step 4，Synthesize（合并）

结果陆续返回时构建统一图景：

• 解析每个评审者的发现，合并描述同一问题但措辞不同的项，并记录是哪些模型提出的。
• 两个及以上模型独立提出的发现，信号最强。
• 单个模型的发现仍要读，但按此加权。
• 记录分歧：若一个模型提出问题、另一个明确给出相反结论，这本身就是裁决的重要上下文。

Step 5，Lead Judgment（主评审判断）

主评审不是中立聚合器，而是务实的资深工程师。按 lead-judgment.md 的框架，把每条发现放进四个桶，标注提出它的模型与一行理由：

最终输出结构（SKILL.md）固定为：

### Intent > [Step 2 写定的意图段落] ### Reviewers - Reviewer [label]: [model name], [N findings] ### Act On ### Consider ### Noted ### Dismissed ### Agreement Map

Agreement Map记录模型在哪里一致、在哪里分歧，以及这个模式说明了什么——它把"三个模型都说 X"和"两个模型对立"这两种情况区分开，而这正是多模型评审相对单模型的核心增量。

模板之外：主评审的过滤纪律

模板负责"多产"，lead-judgment.md负责"少收"。它列出的五条过滤原则，实质是对模板输出的反制设计：

1. Nitpick Gravity（挑剔引力）：对抗式评审者会填满篇幅。若某评审者的发现全是 nit 和风格偏好，代码大概率没问题——直接这么说。
2. Hypothetical vs. Actual："What if someone passes null here?"只有在调用方确实能传 null 时才算发现。追调用点；若上游已校验或类型系统已禁止，驳回。只看 diff 的评审者看不到完整调用链，你能。
3. Premature Abstraction Warnings（过早抽象警告）：评审者常建议抽函数、加接口、造抽象。问一句：这代码会以第二种方式变更吗？不会，就是过早抽象。
4. "I Would Have Done It Differently"：最常见的假阳性，除非能指出当前方案的具体问题，否则驳回并说明原因。
5. Missing Context Signals（上下文缺失信号）：建议修改作者并未写过的代码、把与代码库其余部分一致的模式标为问题、推荐与你已知约束冲突的方案——这些是评审者在信息受限下的诚实错误，优雅驳回。

同时它也警告不要因为"不舒服"就驳回，并给出四条值得注意的信号：多模型独立共识、指出具体执行路径、暴露你心智模型的盲区、读完后心里"……确实"。安全类和正确性 bug 即便只来自单一模型，也要额外审视。

最后两条校准建议非常实用：

• 好的裁决是有用，而非全面。用户读完 "Act On" 就能修完放心发布。若 "Act On" 超过 5 条，说明过滤不够狠。
• "Dismissed" 不是凑数，而是信任机制。展示你驳回了什么、为什么，用户才能在不同意时覆盖你的判断——这比隐藏被驳回的发现更有价值。

在 OpenBot 中这份模板如何被安装与改写

模板位于 marketplace 生产目录的pstackbundle 中。catalog.json 把pstack声明为一个pack：来源记为cursor，带aliasPrefixes: ["principle-"]，并说明它"安装全部 52 个 pstack 技能"，以$pstack-<name>形式调用。

catalog.json 里这个条目把pstack描述为 poteto 的 pstack agent workflows 打包：严谨的 playbook、工程原则、刻意设计的子代理以及经过验证的产出。而 README 进一步说明了打包产物形态：bundles/pstack/是上游 pluginskills/与agents/的未改动副本（MIT 许可），构建时发布为一个Skillpstack；其压缩包内含索引SKILL.md、LICENSE、NOTICE.md，以及把每个skills/子目录映射为skills/pstack-<folder>/的目录；应用会把其中每一项作为独立技能安装，与pstack并列，共享一条 lock 记录——一次下载、一份安装回执。

这意味着本文的主角在安装后落在：

.agents/skills/pstack-interrogate/ ├── SKILL.md └── references/ ├── reviewer-prompt.md ├── rubric.md ├── code-quality-review.md └── lead-judgment.md

构建脚本 build-production-catalog.ts 逐文件处理：目录下所有文件都被复制（sources来自join(root, "skills", folder)的递归相对路径），其中.md文件额外走一次renamePackReferences，.md之外的文件原样按字节复制。SKILL.md还要再过一次packSkillMarkdown。因此references/下的四份参考文件会被完整保留，只做链接与名称改写。

改写规则集中在 renamePackReferences，与本模板直接相关的有三条：

• 相对链接重写为安装后相对路径：](target)形式若匹配 pack 内某个技能的已安装路径，就改写成从当前安装文件出发的相对路径（installedPackPath负责判断skills/<folder>/...是否属于已安装技能，L377-L382）；不属于任何技能的链接则指向钉住的上游 commit。
• 斜杠命令与提及加前缀：/<name>变成$pstack-<name>，`name`与**name**也加上pstack-前缀，<upstreamPath>/skills/<name>/变成.agents/skills/pstack-<name>/。
• frontmatter 调整：在 packSkillMarkdown 中，name:被改写为pstack-<folder>，同时过滤掉disable-model-invocation: true这一行。

最后这条对interrogate有直接影响。上游 SKILL.md 的 frontmatter 里带着disable-model-invocation: true，即该技能只能由用户显式调用。OpenBot 构建时移除该行，使$pstack-interrogate在各种 provider 下都能被调用——README 对此的表述是"removesdisable-model-invocationso$pstack-<name>works with every provider"。

同时，packSkillMarkdown 会在每个SKILL.md末尾追加一节## pstack in OpenBot，内容包括：技能名映射规则（<name>即pstack-<name>）、alias 提示（principle-前缀规则）、子代理兜底方式——当 harness 不认识subagent_type: "<agent>"时，启动一个 general 子代理，先把agents/<agent>.md的正文交给它，再给任务；若目录里有scripts/，提示用解释器运行且安装后的文件不可执行；以及许可证与 notice 的相对位置。agents/的打包条件在 L264-L271：只有当某个技能文本中提到了agents/下某个文件名时，才把该 agent 文件一并纳入。仓库中bundles/pstack/agents/下有poteto-agent.md与comment-sicko.md两个文件。

安装侧还有一道校验。skill-frontmatter.ts 中的readSkillFrontmatter会检查SKILL.md的 YAML frontmatter：name必须等于所在文件夹名，description长度必须在 1 到SKILL_DESCRIPTION_MAX_LENGTH之间，解析失败或字段非法则返回相应的problem码（frontmatterMissing、frontmatterInvalid、descriptionLength、nameMismatch）。这解释了为什么构建必须把name: interrogate改成name: pstack-interrogate——否则装进.agents/skills/pstack-interrogate/后名称不匹配，技能会被判为不可用。README 亦明确"provider 也可能跳过该技能"，所以校验口径与 provider 保持一致。

home-skills.ts 进一步说明了安装位置：HOME_SKILL_FOLDER = ".agents/skills"，用户自有技能与 Agent Skills 工具在这个目录共享；技能数上限MAX_HOME_SKILLS = 200，单个SKILL.md上限MAX_SKILL_FILE_BYTES = 256 * 1024；某个文件夹读不到时按"不存在"处理，因为该目录属于用户而非 OpenBot。

让模板产出稳定结果的六个工程细节

把模板真正用于日常评审时，以下细节决定了输出质量，它们全部可以从模板与配套文件中找到依据：

1. 意图只写一段，且不夹带实现评价。模板把{INTENT}放在引用块中，语义上就是"作者陈述"。混入"我顺便重构了 X"会把子代理引向为重构辩护。
2. 不要裁剪 rubric。{RUBRIC_CONTENTS}与{CODE_QUALITY_CONTENTS}是整份文件。裁剪等于关掉部分透镜，而模型不会告诉你它少了哪一维。
3. 给足上下文，但标清边界。{DIFF_OR_FILES}里应包含让评审者能判断"调用方是否可能传 null"的调用点。模板明确说这段是 "Code Under Review"，所以附带的上下文文件要标明是"上下文，不在审查范围"，避免评审者去挑未改动代码的毛病。
4. 保留全部输出字段。尤其是**Location**与**Evidence**：前者用于 Step 4 合并去重，后者用于 Step 5 判断是否够格进 "Act On"。删掉 Evidence 只留结论，会让主评审无法区分"断言"和"有推理支撑的发现"。
5. 接受空结果。no findings是模板授权的合法输出。逼模型产出会直接制造噪音，而这些噪音要靠 Step 5 的 "Dismissed" 桶来消化，成本更高。
6. 不要在子代理层做裁决。模板明确Do NOT question the intent itself；分桶、权衡、驳回是主评审的职责（见lead-judgment.md）。把裁决塞进子代理提示词，会让"多模型独立共识"这个最强信号失效——因为模型不再独立判断同一件事。

复用清单

若要把这套模板迁移到其他评审流程，最小可用的移植步骤是：

• 保留角色锚定与三条禁令（不复述、不表扬、允许no findings）。
• 把{INTENT}定为不可质疑的公理，并明确"挑战执行，不挑战目标"。
• 用分级透镜：一份负责正确性与安全（对应 rubric.md），一份负责结构简化与可维护性（对应 code-quality-review.md），整份注入而非摘要。
• 固定critical/warning/nit三档并写明判定口径。
• 固定四字段输出，Suggestion标注为可选且要求具体替代方案。
• 每个评审者用同一份模板，只切换模型；多样性来自模型而非人设。
• 收敛阶段独立成文，规定四桶分类与Agreement Map，并要求 "Act On" 保持精简。

模板本身没有一句多余的话：角色、输入、透镜、指令、输出五段，各自解决一个失效模式。真正决定这套流程能否落地的，是它外部的三个约束——意图来自完整上下文、透镜按整份注入、裁决由主评审而非子代理完成。理解了这三点，reviewer-prompt.md 才能从一个"看起来很凶的提示词"变成可复用、可验证、可收敛的工程化审查组件。