mcpField
E
egm-resolve

egm-resolve

github.com/google文档处理4.7k60 次安装今天更新
代码仓库

关于 egm-resolve

用于处理 Goldfish 审阅者对目标文档提出的汇总意见。它判断意见应予反驳还是修正，生成审阅报告，并按用户选择处理文本修改。

主要功能

  1. 01解析审阅意见
  2. 02判断意见应反驳或采纳
  3. 03生成按优先级排列的报告
  4. 04提供交互式处理选项
  5. 05应用获批的文本修正

适用场景

  1. 01梳理文档审阅意见
  2. 02用代码或设计依据回应批评
  3. 03准备待审阅的修改建议
  4. 04批量应用获批修正

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/google/elephant-goldfish-model --skill egm-resolve

安装后在 Claude Code 中输入/egm-resolve确认已加载。

附带文件test_scenarios.yamlTEST.md

详细介绍

Goldfish 审查：解决

在 Codex 或 ChatGPT Work 中运行时，请先阅读 Codex 集成。 在 Claude Code 或 Cowork 中，请先阅读 ${CLAUDE_PLUGIN_ROOT}/docs/claude.md。

概述

此技能指导 Agent 如何在 Elephant 的主要上下文窗口中工作，以解析来自并发 Goldfish 审查者的扁平缺陷报告。它会维护准确的设计决策、应用自动文本修复，并管理交互式协商检查点。

前提条件与上下文策略

  • 上下文建议（Elephant Memory）：此技能应在生成目标文档的持久对话会话（Elephant）中运行，以便回顾早期推理并制定更高质量的修复方案。

输入

调用方或编排驱动程序会提供以下参数，且仅限这些参数：

  • TargetFile：目标文档的绝对或相对路径。
  • LineRange：准确的行号（或 full file）。
  • FindingsList：Goldfish 审查者汇总的扁平发现列表。

执行工作流

步骤 1：验证输入并收集上下文

  1. 混合执行体验：检测是否提供了执行参数：

    • 自动模式：如果已提供所有参数，则以子进程方式静默执行。
    • 独立人工模式：如果省略了参数，则启动友好的引导流程。每次提示用户提供一项输入，并在每轮后等待用户回复。指定所有输入后，显示最终设置并确认用户是否准备继续。

  2. 读取 TargetFile 中 LineRange 指定的内容，并解析 FindingsList。

步骤 2：评估并分类

针对列表中的每条发现，确定：

  • 提出异议（CONTEST）：批评不准确，或基于对代码库的误解。提供确切的代码或设计文档作为证据，说明为何应保留当前文本。
  • 建议修复（PROPOSE FIX）：批评有效。明确提出文本替换或结构格式调整方案，以弥补不足。
步骤 3：报告修复方案

编写最终报告，并使用文件写入工具将其保存为工作目录中的 goldfish_review_report.md（如果运行环境有专用产物目录，则保存到该目录）。 使用以下布局：

# Goldfish Annotated Review Report

**Target:** `[TargetFile]` (`[LineRange]`)

## Prioritized Findings & AI Suggestions

{{range findings, ordered by Severity}}
### [Issue 1] [`[ReviewerPersona]`] - Severity: [High | Medium | Low]
*   **Affected Scope:** [Lines Start-End]([RelativePath]#L[Start]-L[End]) ([Sub-header])
*   **Discrepancy Description:** [copied from FindingsList]
*   **Rationale:** [copied from FindingsList]
*   ***AI Suggestion:*** [CONTEST | PROPOSE FIX]
*   ***Justification:*** [Detailed reason]
*   ***Proposed Edit:***
    *   Location: [Line/Header]
    *   Change: [Precise replacement string or deletion note]
{{end}}
步骤 4：交互式处理确认

继续之前，向用户发送一条可见的聊天消息：*"我已将审核发现汇总到 goldfish_review_report.md。请在其中查看这些发现，并选择接下来的处理方式：

  • 直接在文件中评论：在聊天中或文件里查看 goldfish_review_report.md，并留下评论或编辑，以批准、拒绝或质疑具体条目。
  • 自动接受：回复“auto accept”，批量应用所有建议的修复（跳过有争议的条目）。
  • 继续下一阶段：回复“continue”或“no changes”，不应用修复并继续。
  • 交互式逐项说明：回复“interactive breakdown”，在聊天中逐项查看，并在做出决定前详细了解每项建议的编辑或有争议的发现。
  • 自定义指示／其他请求：回复任何自定义指示、问题或额外请求。"*

在本轮载荷中，你必须立即停止主动执行，并且不调用任何工具。你必须停止执行并进入空闲状态，等待人类开发者评论或编辑该产物，或在聊天中回复。

按以下方式解读用户的操作／回复：

  • “Auto accept”／“Accept all suggestions”／用户未提出异议而点击“Proceed”：使用文件编辑工具，在一次批处理中将 AI 建议为 PROPOSE FIX 的所有修复直接应用到 TargetFile 的 LineRange。明确跳过归类为 CONTEST 的条目。然后继续步骤 5。

  • “Continue to next phase”／“No changes”：不应用任何自动修复。然后继续步骤 5。

  • “Interactive breakdown”：对所有发现条目（包括 PROPOSE FIX 和 CONTEST）依次进行逐项说明：

    1. 对每个条目 i，发送一条可见的聊天消息，以丰富的 Markdown 格式展示完整的发现详情和说明：

      ### 逐项说明 [i]：[Issue Title] [`[ReviewerPersona]`]
* **范围：** [Lines Start-End]([RelativePath]#L[Start]-L[End]) ([Sub-header])
* **描述：** [Description]
* **AI 建议：** [CONTEST | PROPOSE FIX]
* **解释与依据：** [Detailed reason and background explaining why the fix is proposed or why the finding is contested]
* **建议的编辑：** [Precise replacement text or deletion note]

      然后在聊天中询问用户对此条目的决定（不调用任何工具，并进入空闲状态）：

      • 如果是 PROPOSE FIX：请用户回复 Accept proposed fix、Skip / ignore 或 Discuss。
      • 如果是 CONTEST：请用户回复 Skip / agree with contest、Overrule contest (propose fix) 或 Discuss。

    2. 将用户的决定记录在内部记忆清单中（例如：条目 1：已接受、条目 2：已忽略、条目 3：已推翻异议）。在此逐项处理过程中，不要调用任何文件编辑工具。

    3. 所有条目均已决定后，汇总已接受的编辑，使用文件编辑工具执行这些编辑，然后继续步骤 5。

  • 自定义指示／额外编辑：如果用户提供了针对性的指示，则应用这些指示并继续。

步骤 5：处理后同步与退出
  1. 重新验证行号：如果修改了 TargetFile，请验证文件结构完整且 Markdown 有效。
  2. 将报告标记为已解决（在顶部添加一行 Status: resolved）。
  3. 交接：干净地退出并返回调用方（例如 egm-review-loop），并提供已接受的修复数量、有争议的条目数量，以及尚未处理的问题数量。

评论

支持 Markdown