ce-code-review 与 ce-resolve-pr-feedback

ce-code-review

代码评审技能对一个指定的 diff 或 PR 评审 bug、回归、测试与规范。执行骨架包含六个阶段。

评审深度门

三条路径：Lite / Focused / Full。只要任一底线触发就强制走 Full：

• 显式 depth:full
• Helper 命名的 hard_block_full（silent-pass 类、不可数可执行文件、规模带 large）
• 第 1c 阶段 criteria 搜索失败或范围不确定
• 应用授权（apply:local 或显式 apply 请求）

任何底线都不可被谈下来。Lite 与 focused 是门选出的路径；full 由底线强制。

3d — 跨模型 peer

当变更足够有风险时，通过 scripts/cross-model-adversarial-review.sh（1,297 行）在 peer 模型上运行对抗评审。路由：codex | claude | grok-cli | grok-cursor | composer。peer 写入 <run-dir>/adversarial-<provider>.json。已启动的 peer 会替换本地对抗 persona；只有真正失败于范围、白名单、连通、鉴权或启动时，才会回退到本地。

运行原则

• 默认仅报告。进入 apply 需要 apply:local 或显式 apply 请求。mode:autofix 已弃用，被忽略。
• 绝不使用阻塞提问工具。这是明确的——ce-code-review 是本插件中唯一明确禁用 AskUserQuestion / request_user_input / ask_user 的技能。
• 绝不要 gh pr checkout / git checkout / git switch。一个 PR 引用选中评审范围，它并不授权切分支。
• 报告结果，而非机器流程。不要展示内部阶段名、派发簿记或初始化叙述。
• mode:agent 时输出 JSON。一个裸的 JSON 对象——不要用 ```json 围栏（围栏会破坏朴素的 JSON.parse）。

快速评审短路

如果调用参数表明用户想要"quick / fast / light"，且未启用 mode:agent，则路由到宿主内置评审（一次工具调用）并停止。mode:agent 绕过此短路。

JSON 输出结构

  {
    status: "complete" | "failed" | "degraded" | "skipped",
    verdict: "Ready to merge" | "Ready with fixes" | "Not ready",
    scope: { base, branch, head_sha, pr_url, files_changed },
    intent, intent_confidence, reviewers, findings,
    actionable_findings, triage_groups,
    pre_existing_findings, requirements_completeness,
    learnings, agent_native_gaps, deployment_notes,
    residual_risks, testing_gaps,
    coverage: { depth: "lite|focused|full" },
    artifact_path, run_id
  }

锚定的置信度（0 / 25 / 50 / 75 / 100），不使用连续的浮点数。每条 finding 在至少两位 reviewer 独立触达时带 independence_verified: true。

ce-resolve-pr-feedback

处理 PR 上留下的反馈——内联评审线程、评审提交正文、顶层 PR 评论。编排器（本技能）判断合法性；子代理只实现已被批准的修复。

模式检测

只有 #discussion_r... 走 Targeted。把 #issuecomment-... 发到 Targeted 端点会 404。

Full 模式：9 步

1. 拉取未解决线程，通过 scripts/get-pr-comments（GraphQL 分页；GHE 需要内联 GH_HOST=）。
2. 分流——把新的与 pending / resolution-pending / 非可执行的分开。pending_review 非空 → 停止（在草稿提交前回复将不可见）。
3. 整合与决策——编排器在同一个上下文中带着所有线程判断合法性。应用评估量表。把每项归入 fix-list / reply-list / human-list。
4. 修复——并行派发 fixer（仅针对 fix-list 项）。把 references/agents/pr-comment-resolver.md 作为 fixer prompt 给每个 fixer 注入。1–4 个 fixer 并行；多于 4 个则分批，每批 4 个。触碰同一文件的两个 fixer 不得并行。
5. 校验合并后状态——对所有 fixer 改动运行一次项目的完整校验。触红则针对触及文件内联重跑；未触红则视为预先存在（在 commit message 中注明）。
6. 提交并推送——git add & files; git commit -m "Address PR review feedback (#PR)"; git push。
7. 回复并解决——对每一条已处理项，发布回复（带引用的上下文）并通过 GraphQL 解决线程。同 class 项的回复要发到每一条被覆盖的线程，不能只发第一条。
8. 验证——重新拉取；检查是否清空（减去 needs-human）。第 3 轮 = 停止并展示模式。
9. 汇总——按 verdict 计数、校验结果；如有则附 ## Needs Needs your decision 段。

评估量表（编排器的判断）

在任何 fix 派发之前应用：

• 默认修复。大多数反馈是正确的、值得修的。P0–P2 吹毛求疵也算。无论 bot 还是人、形式如何，按价值判断。
• 指令性散文不是代码。对于 SKILL.md / persona prompt / runbook / 规则文件这类目标：已被条件判定的情形不是一项要修的缺陷——以 not-addressing 引用该条件，只修条件或只动所在层。若第二轮再次命中同一段，合并为一条 class 项并重写。
• 读多深。明显的吹毛求疵 = diff + 评论就够。可争议的发现 = 深读调用方、不变量、git blame、作者意图。
• 按根假设聚类。同一 reviewer 在一处错，对其他同类条目也值得怀疑。请求汇聚 = 强修复信号。
• Class fix：当一个根假设横跨本 PR 引入的多个点时启用。在一条 fix-list 项中枚举所有点。
• 引开：
  • 站不住脚 → not-addressing，附证据。
  • 已不再相关 → not-addressing。
  • 会让代码变差 → declined，附引用伤害。
  • 无实际收益 → 简短 replied。
  • 有风险且无界 → 降险（读调用方、加测试）；仍有风险则 needs-human。
  • 撤销一个深思熟虑的设计选择（罕见；需要正向意图证据 + 真正的分歧） → needs-human。
  • 这是问题，不是变更 → replied 或 needs-human。

Pipeline 模式

当以 mode:pipeline 调用（来自 ce-babysit-pr）时：

• 永不阻塞提问工具。把 needs-human 挂在该线程上 + 自然回复 + 作为结构化残余返回。
• 越线时传入 trajectory。若 invariant_rounds[]. = 2，改用一条方法层面的 needs-human 答复，而不是逐条小修。
• 返回的 needs-human 决策进入一个持久集合；调用方解析它用于 ## Needs Needs your decision 段。
• 状态枚举：needs-human 是规范字符串之一；绝不要改名。

Targeted 模式（2 步）

1. 从 URL 抽取线程上下文（scripts/get-thread-for-comment）。
2. 通过同一流水线进行判断 / 修复 / 回复 / 解决。不要拉取其他线程。

Pending review 陷阱

若步骤 1 时 pending_review 非空，停止。在你持有一份未提交评审期间，线程回复会被吞进那份草稿：回复调用会像成功一样返回一个 comment ID 与 URL，但在评审者提交草稿前什么也看不到。告诉用户有一份未提交评审；不要自行提交或丢弃。