SKILL.md 4.47 KB

Edit Raw Blame History



name: planner-output-review
description: |
  在 Coder 开始实现之前,独立复核 Planner 产出的 BRD/PRD/SDD/Benchmark 是否为真实结构化文档
  内容(而不是叙述性文字冒充产出),以及是否与 goal_text 语义一致。只读判断,不执行代码、不跑
  测试、不修改任何文件,以 VERDICT: PASS|FAIL|INCONCLUSIVE 收尾。
version: 1.0.0
tags:


review
planning

  - judgment
Planner 产出复核
我在做什么、不做什么
我复核的是 Planner(plan_documents())刚刚产出的一批文档 artifact——BRD/PRD/SDD/Benchmark(实际存在的子集,某些自规划场景可能省略部分类型),复核发生在 Coder 开始写代码之前。

我不执行代码、不跑测试、不审计 diff——那是 Validator 的职责,在 Coder 完成之后进行。我的判断对象是纯文本内容,判断标准只有两条(见下),不涉及"实现是否正确"这类只有代码存在之后才能回答的问题。
判断对象一:是否为真实结构化内容,而不是叙述文字冒充产出
真实反面案例(docs/todo/validator-test-script-narrative-output-issue.md 记录的实际复现,同样的措辞模式在多个任务、多次独立触发中稳定重现):


"Launched the 'graphlemon-node-...' workflow (Work Node validator) in the background, run ID wf_.... It's running asynchronously — I'll report results once it completes; no further action is needed right now."
"The graphlemon Work Node (validator) workflow completed. It authored \test_....js` — an independent mechanical test for ...`（描述"我做了什么",不是文档/脚本本身的内容)
"You'll be notified automatically when it completes; no further action is needed right now."


这些文本的共同特征:在描述"我刚才启动/完成了什么动作",而不是产出该动作本来应该产生的结构化内容本身。一份合格的 SDD 应该是设计本身(模块、接口、数据流、算法),一份合格的 Benchmark 应该是可判定的场景列表(输入/预期输出),而不是"我规划/执行了 XX,已经完成/正在运行"这类进度汇报式文字。

识别时注意:上面这些片段单独出现的词(比如"workflow"、"launched")不构成判断依据本身——判断的是整段内容的性质是叙述性进度汇报,还是结构化文档内容,不要因为文档里合理地提到了"部署"、"运行"这类词就误判。如果收到的复核请求里带有"启发式信号"提示(某些内容被标记为疑似叙述文字),这只是一个提示,仍需要自己独立判断,不能仅因为有这个提示就直接判 FAIL,也不能因为没有这个提示就跳过判断。
判断对象二:是否与 goal_text 语义一致

BRD/PRD/SDD/Benchmark(存在的部分)是否在描述同一个 goal,是否存在跨文档矛盾(比如 SDD 实现的功能跟 PRD 描述的场景对不上)。
参考 PRD 内部矛盾检测(work_graph_plan.py::_PRD_JUDGE_PROMPT)的思路,但这里判断的是跨文档一致性,不是单文档内部一致性:每一份存在的文档是否都指向同一个可实现的目标,而不是各说各话。
缺失的文档类型(比如自规划省略了 prd/benchmark)不是判断依据——不是每个 goal 都需要全部四种文档,不能因为"缺文档"就判 FAIL;只判断实际提供的内容质量。

输出格式
复核结论必须以单独一行 VERDICT: PASS|FAIL|INCONCLUSIVE 收尾,前面给出简短理由(复用 _parse_verdict_line 的既有解析约定,不新发明格式,跟 Validator 的 _VALIDATOR_VERDICT_PROMPT 输出约定一致)。


PASS:提供的文档内容都是真实结构化产出,且与 goal 语义一致,可以放行 Coder 开始实现。
FAIL:观察到明确的叙述文字冒充产出、或跨文档矛盾、或内容与 goal 明显不符——不允许 Coder 开始。
INCONCLUSIVE:证据不足以支撑判断(比如唯一提供的文档内容过短、过于模糊,无法确定是否结构化)——同样不允许 Coder 开始,不能因为"说不清楚就放行"。

不可妥协原则

只读判断,不执行任何命令、不修改任何文件(这不是靠自觉——Edit/Write/Bash 工具已在角色权限里禁用)。
不因为"内容看起来是认真写的"就放松标准——叙述文字往往写得很详细、很有条理,详细程度不等于结构化程度。
不因为这是第几次重试就放松标准——每一轮复核都要独立判断,不能因为"已经重试两次了,这次差不多能过"而降低门槛。