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

egm-review-loop

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

原文原文の説明を見る

Executes the Antagonistic-Review process from the Elephant-Goldfish Model (EGM) via an automated multi-agent review loop to audit documents against qualitative standards and structural templates, and automatically apply approved fixes. Use when reviewing design docs, READMEs, feature specifications, implementation plans, or verifying document completeness and tone.

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

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • 設計書を複数の観点からレビューしたいとき
  • 仕様書の抜けや前提を確認したいとき
  • 実装計画の準備状況を点検したいとき
  • 承認したレビュー修正を反映したいとき

日本語での紹介

できること

設計書、README、機能仕様、実装計画などを、複数の専門エージェントで繰り返しレビューします。各レビュー担当は独立した新しい文脈で対象文書を読み、指定された基準や参考資料に照らして指摘を出します。結果は重複を整理した一覧にまとめ、egm-resolve の手順で指摘への対応を検討し、利用者が受け入れた修正を文書に反映します。各ラウンドの前に対象範囲を読み直して行番号を更新し、未解決の重大な指摘やレビュー担当の実行失敗も考慮して次のラウンドへ進むかを判断します。最大5ラウンドまで実行し、連続して問題が収束したか、上限に達したかなどを報告します。

こんなときに便利

一人の視点では見落としやすい前提や説明不足を探したいときに向いています。文書の読みやすさ、構成、設計内容、実装準備状況など、複数の観点から確認したい場合に使えます。

使い方の例

  • 「この設計書を構成と読みやすさの観点でレビューしてください」
  • 「この実装計画を実装準備の基準に沿って確認してください」
  • 「この仕様書を複数の観点でレビューし、承認した修正を反映してください」

注意点

複数のサブエージェントを利用できる環境が必要です。利用できない場合、このスキルの方式によるレビューは実行できません。対象ファイル、レビュー範囲、担当レビューア、基準、参照資料を指定します。

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

含まれるファイル(5)

  • SKILL.md9.5 KB
  • agents/openai.yaml204 B
  • assets/icon.svg544 B
  • test_scenarios.yaml2.6 KB
  • TEST.md1.0 KB

SKILL.md(原文)

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

Goldfish Review: Loop (Orchestration Driver)

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 acts as the central orchestration engine driving the multi-agent review loop. It coordinates two distinct agent memory models:

  • The Goldfish (Adversarial Auditors): Subagents spawned in isolated, fresh context windows to catch unstated assumptions without historical bias.
  • The Elephant (Persistent Resolver): The primary agent context holding institutional knowledge to evaluate findings and apply approved repairs.

The driver manages argument intake, resolves paths for reviewers and standards, unconditionally re-parses target line ranges before every iteration, spawns concurrent specialized Goldfish auditors based on configuration, and coordinates with the Elephant context to resolve findings.

Delegation

A Goldfish runs in a fresh context with no conversation history. Spawn each subagent with your harness's subagent tool (Antigravity: invoke_subagent; Claude Code: Agent; Codex: spawn_agent). Each subagent is defined in agents/<file>.md, and its frontmatter name (for example egm-zoom-out) is the subagent type to request where your harness registers named subagents. Otherwise spawn a general-purpose subagent and tell it to read that persona file first. Pass the prompt verbatim and wait for the report. If your harness cannot nest subagents, use direct dispatch instead of the synthesizer. See docs/harnesses.md. If your harness has no subagent tool, stop and tell the user: a review in the same context is not a Goldfish review.

Inputs

The caller or user provides exactly these parameters:

  • TargetFile: Absolute or relative path to target document.
  • SemanticTarget: Descriptive targeting string (e.g., "Target the H4 block with SS-ID 'S1.12'"), or full file.
  • Reviewers: List of reviewer names (shortnames or paths).
  • Standards: Mapping of reviewer names to standard names (shortnames or paths).
  • GoldfishContext: A reading list (source files, directories, or documentation URLs) fed to reviewers to establish their baseline.

Path & Standard Resolution Logic

When resolving names in Reviewers and Standards:

  • Reviewer Shortnames: Map reviewer shortname (e.g., design_critic, structural, style, implementation_readiness, codebase_details, comprehension, zoom_out) to agents/{name}.md. The persona file defines the reviewer's core mandates, audit vectors, and output format.
  • Standard Shortnames: Map standard shortname (e.g., feature-spec-standard, implementation-readiness-standard, zoom-out-standard, heilmeier-standard, re-implementation-standard) to resources/document_standards/{name}.md.
  • Custom Paths: If the name contains a slash (/), treat it as an absolute or workspace-relative path and read it directly.

Execution Workflow

Step 1: Intake & Configuration UX

Evaluate the provided inputs (TargetFile, SemanticTarget, Reviewers, Standards, GoldfishContext).

  1. Identify Missing Inputs: Determine which of the required parameters are missing.
  2. Interactive Onboarding:
    • If all inputs are present, proceed to Step 2.
    • If some or all inputs are missing, interactively prompt the user only for the missing inputs, one at a time via chat messages.
  3. Reviewer Recommendations:
    • Feature Specs: Recommend design_critic (mapped to resources/document_standards/feature-spec-standard.md) and structural (mapped to resources/document_standards/feature-spec-standard.md).
    • Implementation Plans: Recommend implementation_readiness (mapped to resources/document_standards/implementation-readiness-standard.md) and codebase_details.
  4. Confirm Configuration: Display the consolidated plan (Target, Reviewers, and mapped Standards) and ask the user to confirm before proceeding.

Step 2: The Sharpening Loop (Iterative Cycle)

Execute the following sequence in a continuous loop:

2.1 Unconditional Target Resolution

Before every iteration, unconditionally re-scan TargetFile by reading it and using the stable SemanticTarget string (e.g., locating the target header) to dynamically determine the updated absolute start and end line numbers. This ensures absolute accuracy even if the file was edited in prior rounds. (If full file mode is specified, confirm full-file line bounds).

2.2 Review Swarm Execution

  1. Launch Subagent Swarm: Spawn subagents to execute the review:
    • Hierarchical Dispatch (Synthesizer): Spawn the intermediate synthesizer subagent (agents/synthesizer.md / egm-synthesizer). The synthesizer spawns the Goldfish review swarm in parallel, deduplicates findings, writes the report artifact, and returns a single summary message to avoid context pollution in the root conversation. Pass it the Failed Reviewers rule below. Its summary must give a status, completed or not run, for each requested reviewer.
    • Direct Dispatch (Flat Swarm): Alternatively, spawn each requested reviewer subagent in Reviewers directly. Instruct each subagent to first read its persona definition in agents/{name}.md, then audit TargetFile at the resolved line range against its designated standard in resources/document_standards/, supplying GoldfishContext.
    • Each reviewer produces findings with severity (🔴 Blocker, 🟡 Major, 🟢 Nit), line numbers, discrepancy descriptions, and rationales.
  2. Consolidate Findings: Collect all findings across reviewers into a single flat FindingsList. Give each finding a stable id (<reviewer>-<round>-<n>) and record its reviewer, severity, and affected scope.
  3. Failed Reviewers: A reviewer that times out, fails, or returns no report did not review. Retry it once. If it fails again, record it as not run in the report. Never count it as a reviewer with zero findings. If the synthesizer summary has no status for a requested reviewer, record that reviewer as not run.

2.3 Aggregated Resolution Hand-off

  1. Pass TargetFile, the active line range, and the aggregated FindingsList to the egm-resolve workflow.
  2. Execute the resolution workflow in the primary Elephant context:
    • Categorize findings into CONTEST vs. PROPOSE FIX.
    • Save goldfish_review_report.md with your file-writing tool.
    • Present the interactive decision gate (Auto accept, Continue, Interactive breakdown).
    • Apply approved text repairs to TargetFile using your file-editing tool.

2.4 Iteration Check & Turn Boundary

Fresh reviewers sample differently each round, so a round with zero findings is rare even when the document improves. Use these rules instead:

  • Settled findings: A finding is settled when it is contested or recorded without a fix (accepted risk). Keep the settled list across rounds. If a new reviewer raises a settled finding again (same affected scope, same issue), do not re-open it.
  • Fixed findings: An applied fix does not settle a finding. If a later reviewer raises the same issue at the same scope, the fix failed or a later edit reintroduced the issue. Re-open the finding.
  • Clean round: A round is clean when no reviewer raises a Blocker or Major finding that is not settled. Nits do not block. A reviewer recorded as not run makes the round not clean. Decide this from the review results, before you apply the fixes of that round.
  • Converged: Two consecutive clean rounds. One clean round is not enough, because the next fresh reviewer can find a different gap in the same text.
  • Cap: 5 rounds.
  • Churn: A new finding is at the scope of an applied fix, and reverting that fix would resolve it.

On converged, go to Step 3. On cap or churn, write a short list of the open findings by severity, then ask the user one question: accept and proceed, continue past the cap, or return the document to drafting.

Crucial Turn-Taking Requirement: After the resolution phase finishes for a given round, the loop driver MUST respect the turn-taking checkpoint in egm-resolve. The driver must remain idle across human turns, only looping back to Step 2.1 when the user explicitly confirms they wish to run another round of review.

Step 3: Output Boundary & Final Checkpoint

Upon completion (converged, cap or churn accepted by the user, or manual halt):

  • Programmatic Callers: If running as a subflow of egm-review, exit cleanly to hand execution back to the parent workflow.
  • Manual Invocations: Output a summary of completion in chat: "The review loop has completed after [N] rounds ([converged | accepted at cap | halted]). Open findings are in the report. Would you like to proceed to the next stage, or do you have any final questions?"

レビュー

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

コメント

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

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

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。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-resolve

Google 公式無料概要あり

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

  • 複数のレビュー指摘を整理したいとき
  • 指摘への反論や修正案を文書化したいとき
  • 修正を項目ごとに判断したいとき
google/elephant-goldfish-model5,7282026年10月29日 更新

egm-review

Google 公式無料概要あり

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

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

google のスキルをすべて見る

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