本文へ移動
cccskills
Google 公式無料GitHub で公開日本語紹介

egm-resolve

複数のレビュー担当から集めた文書の指摘を根拠に沿って分類し、修正案の提示や修正適用、利用者との確認を進めるスキルです。

原文原文の説明を見る

The Elephant resolution skill. Ingests flat deficiency reports from concurrent Goldfish reviewers, applies automated fixes for PROPOSE FIX items via UI multiple-choice gates, and presents interactive negotiation/re-sync checkpoints.

google/elephant-goldfish-modelスター 5,728(GitHub 5,728 + cccskills 0)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • 複数のレビュー指摘を整理したいとき
  • 指摘への反論や修正案を文書化したいとき
  • 修正を項目ごとに判断したいとき
  • 受け入れた修正を対象文書に反映したいとき

日本語での紹介

できること

複数のレビュー担当が挙げた文書の指摘を読み、根拠に基づいて「反論」「利用者に確認」「修正案」「対応しない」に分類します。反論する場合は、レビュー担当が確認できるファイルや記録上の判断を示します。妥当な指摘には置き換える文章や構成上の修正を定め、指摘の内容、理由、対象箇所とともに goldfish_review_report.md にまとめます。その後、利用者がまとめて修正を受け入れるか、変更せず先へ進むか、項目ごとに判断するかを選べるようにします。受け入れられた修正を対象文書に反映し、内容とMarkdownの構造を確認して、解決件数などを呼び出し元へ返します。

こんなときに便利

設計書や仕様書などに複数人・複数エージェントのレビュー結果が集まり、指摘の妥当性を整理してから修正したいときに向いています。チームの慣習など、文書やコードから確認できない事情を利用者に判断してもらいたい場合にも使えます。

使い方の例

  • 「この設計書のレビュー指摘を分類し、修正レポートを作ってください」
  • 「この指摘が妥当か確認し、受け入れる修正案を整理してください」
  • 「修正案を項目ごとに確認しながら進めてください」

注意点

対象ファイル、対象行または全文、レビュー指摘一覧を入力します。レビュー結果を活用するには、元の文書を作成した会話で実行することが推奨されています。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(5)

  • SKILL.md8.3 KB
  • agents/openai.yaml193 B
  • assets/icon.svg506 B
  • test_scenarios.yaml1.9 KB
  • TEST.md871 B

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Goldfish Review: Resolve

When running in Codex or ChatGPT Work, first read Codex integration. In Claude Code or Cowork, read ${CLAUDE_PLUGIN_ROOT}/docs/claude.md first.

Overview

This skill instructs the agent on how to operate within the primary Elephant context window to parse flat deficiency reports from concurrent Goldfish reviewers. It defends accurate design choices, applies automated textual repairs, and manages interactive negotiation checkpoints.

Prerequisites & Context Strategy

  • Context Recommendation (Elephant Memory): This skill should be run in the persistent conversation session that generated the target document (the Elephant) to recall earlier reasoning and craft higher-quality fixes.

Inputs

The caller or orchestration driver provides exactly these parameters:

  • TargetFile: Absolute or relative path to target document.
  • LineRange: Exact line numbers (or full file).
  • FindingsList: Aggregated flat list of findings from Goldfish reviewers.

Execution Workflow

Step 1: Intake Validation & Gather Context

  1. Hybrid Execution UX: Detect if execution arguments are present:

    • Automated Mode: If all parameters are provided, execute silently as a subprocess.
    • Standalone Human Mode: If parameters are omitted, trigger a friendly onboarding flow. Prompt for one piece of input at a time, waiting for the user's response after each turn. Once all inputs are specified, display the final setup and verify the user is ready to continue.
  2. Read TargetFile at LineRange by reading it and parse the FindingsList.

Step 2: Evaluate & Categorize

Give each finding exactly one category:

  • CONTEST: The critique is inaccurate or relies on a misunderstanding of the codebase. Cite evidence that the reviewer could read: a file and symbol, or a decision recorded in the document.
  • ESCALATE: The critique is inaccurate, but the evidence is outside every file the reviewer could read (for example, a team convention or a verbal decision). State that fact. Do not fix the finding. Give it to the user.
  • PROPOSE FIX: The critique is valid. Define precise textual replacements or structural formatting adjustments to resolve the gap.
  • DECLINE: The finding is a Nit. Record it. Do not fix it. You can use PROPOSE FIX for a Nit if the fix is worth it.

Apply these rules:

  • A contest must be checkable. "This was intentional" is not evidence. If you cannot cite evidence the reviewer could read, use ESCALATE or PROPOSE FIX.
  • Do not add context only to satisfy a reviewer. Add context when a human reader of the document needs it. If only a zero-context subagent needs it, use ESCALATE.
  • Do not contest a comprehension gap. If a fresh reader could not follow the document, the document is missing context.
  • Do not change a severity. If you think a Blocker is a Nit, CONTEST it and state the reason.
  • You wrote the document under review. A wish to contest is not evidence that the reviewer is wrong.

Step 3: Report Fixes

Construct the final report and save it named goldfish_review_report.md in the working directory (or your harness's artifact directory, if it has one) using your file-writing tool. Use this layout:

# 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 | ESCALATE | PROPOSE FIX | DECLINE]
*   ***Justification:*** [Detailed reason]
*   ***Proposed Edit:***
    *   Location: [Line/Header]
    *   Change: [Precise replacement string or deletion note]
{{end}}

Step 4: Interactive Resolution Gate

If any finding is ESCALATE, list those findings first in the chat message. They need the user's knowledge, not only approval.

Before proceeding, output a visible chat message to the user: *"I have compiled the audit findings into goldfish_review_report.md. Please review the findings there and choose how you would like to proceed:

  • Comment directly on the file: Review goldfish_review_report.md in chat or the file and leave comments/edits to approve, reject, or contest specific items.
  • Auto accept: Reply "auto accept" to batch-apply all proposed fixes (skipping contested items).
  • Continue to next phase: Reply "continue" or "no changes" to proceed without applying fixes.
  • Interactive breakdown: Reply "interactive breakdown" for a guided, item-by-item walkthrough in chat with detailed explanations for each proposed edit or contested finding before making decisions.
  • Custom instruction / Wildcard request: Reply with any custom instruction, question, or out-of-band request."*

You MUST immediately yield active execution by calling zero tools in this turn payload. You must stop execution and go idle, waiting for the human developer to comment on/edit the artifact or reply in the chat.

Interpret the user's action/response as follows:

  • "Auto accept" / "Accept all suggestions" / User clicks "Proceed" without contesting: Apply all fixes where the AI suggestion was PROPOSE FIX directly to TargetFile at LineRange in a single batch using your file-editing tool. Any items categorized as CONTEST, ESCALATE, or DECLINE are explicitly bypassed. Then proceed to Step 5.

  • "Continue to next phase" / "No changes": Do not apply any automated fixes. Then proceed to Step 5.

  • "Interactive breakdown": Enter a sequential breakdown loop over ALL finding items (all categories except DECLINE):

    1. For each item i, output a visible chat message formatting the full finding details and explanation in rich markdown:

      ### Breakdown Item [i]: [Issue Title] [`[ReviewerPersona]`]
      * **Scope:** [Lines Start-End]([RelativePath]#L[Start]-L[End]) ([Sub-header])
      * **Description:** [Description]
      * **AI Suggestion:** [CONTEST | ESCALATE | PROPOSE FIX]
      * **Explanation & Justification:** [Detailed reason and background explaining why the fix is proposed or why the finding is contested]
      * **Proposed Edit:** [Precise replacement text or deletion note]
      

      Then prompt the user in chat for their decision on this item (calling zero tools and going idle):

      • If PROPOSE FIX: Ask the user to reply with Accept proposed fix, Skip / ignore, or Discuss.
      • If CONTEST: Ask the user to reply with Skip / agree with contest, Overrule contest (propose fix), or Discuss.
      • If ESCALATE: Ask the user to reply with Confirm (no change), Add the fact to the document, or Discuss.
    2. Record the user's decisions in an internal memory checklist (e.g., Item 1: Accepted, Item 2: Ignored, Item 3: Overruled). Do NOT call any file editing tools during this sequential loop.

    3. Once all items have been decided, summarize the accepted edits, execute them using your file-editing tool, and proceed to Step 5.

  • Custom instruction / Out-of-band edit: If the user provides targeted instructions, apply them and proceed.

Step 5: Post-Resolution Synchronization & Exit

  1. Re-verify Lines: If changes were made to TargetFile, verify that the file remains structurally coherent and valid markdown.
  2. Mark the report as resolved (add a Status: resolved line at the top).
  3. Handoff: Exit cleanly back to the caller (such as egm-review-loop) with the count of accepted fixes, contested items, escalated items, declined items, and remaining unaddressed issues.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

egm-bootstrap

Google 公式無料概要あり

リポジトリ内のソースコードを調べ、各ディレクトリの役割や公開インターフェース、制約をまとめたREADME.mdを階層的に作成・更新するスキルです。

  • リポジトリのREADMEを階層ごとに整備したいとき
  • 各パッケージの公開インターフェースを記録したいとき
  • 既存のREADMEをコードに合わせて更新したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

egm-brainstorm

Google 公式無料概要あり

曖昧なアイデアを質問と多角的な検討で仮説やRFC要約に整理し、必要に応じて詳細設計へ引き継ぐスキルです。

  • 初期の機能案を具体化したいとき
  • 前提や制約を洗い出したいとき
  • チーム相談用の企画概要を作りたいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

egm-draft

Google 公式無料概要あり

要件や解決方針をまとめたブリーフやメモをもとに、概要から実装計画までを段階的に設計書へまとめ、各章を確認しながら仕上げるスキルです。

  • 合意した要件から設計書を作りたいとき
  • 機能メモを技術計画にまとめたいとき
  • 設計の代替案と不採用理由を残したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

egm-drift-report

Google 公式無料概要あり

設計書やREADMEと現在のコードを照合し、仕様にない実装や未実装の機能、設計との差異を見つけて、文書ごとの報告書に整理します。

  • 設計書と実装の差異を調べたいとき
  • READMEの記述をコードと照合したいとき
  • 未実装の仕様を洗い出したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

egm-review

Google 公式無料概要あり

設計文書を全体像・理解しやすさ・設計上の課題・実装準備の観点から段階的にレビューし、指摘をレポートにまとめるスキルです。

  • 設計文書の抜けを実装前に確認したいとき
  • 仕様が読み手に伝わるか確かめたいとき
  • 実装準備の状態を評価したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

egm-review-loop

Google 公式無料概要あり

複数の専門エージェントで設計書や仕様書を繰り返しレビューし、指摘の整理、修正案の確認、承認された修正の反映まで進めるスキルです。

  • 設計書を複数の観点からレビューしたいとき
  • 仕様書の抜けや前提を確認したいとき
  • 実装計画の準備状況を点検したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

google のスキルをすべて見る

このスキルの問題を報告する