← Elephant-Goldfish ModelCONTENT HISTORY

Update to Elephant-Goldfish Model

Snapshot Nov 5, 2026 · 01:21 UTC · version 0.1.0

Collection source: downloaded plugin package.

WHAT CHANGED

First saved snapshot

No earlier snapshot is available to establish a change.

Save Elephant-Goldfish Model and check future changes in Following.

Up to 10 plugins free · no card required.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Run a configured group of reviewers for a specific review task.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 204
    },
    {
      "relative_path": "assets/icon.svg",
      "size_in_bytes": 544
    }
  ],
  "name": "egm-review-loop",
  "skill_md_contents": "---\nname: egm-review-loop\nlicense: Apache-2.0\ndisable-model-invocation: true\ndescription: Run a configured group of reviewers for a specific review task.\n---\n\n# Goldfish Review: Loop (Orchestration Driver)\n\nWhen running in Codex or ChatGPT Work, first read [Codex integration](../../docs/codex.md).\nIn Claude Code or Cowork, read `${CLAUDE_PLUGIN_ROOT}/docs/claude.md` first.\n\n## Overview\n\nThis skill acts as the central orchestration engine driving the multi-agent\nreview loop. It coordinates two distinct agent memory models:\n\n*   **The Goldfish (Adversarial Auditors)**: Subagents spawned in isolated,\n    fresh context windows to catch unstated assumptions without historical bias.\n*   **The Elephant (Persistent Resolver)**: The primary agent context holding\n    institutional knowledge to evaluate findings and apply approved repairs.\n\nThe driver manages argument intake, resolves paths for reviewers and standards,\nunconditionally re-parses target line ranges before every iteration, spawns\nconcurrent specialized Goldfish auditors based on configuration, and coordinates\nwith the Elephant context to resolve findings.\n\n## Delegation\n\nA Goldfish runs in a fresh context with no conversation history. Spawn each\nsubagent 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\nfrontmatter `name` (for example `egm-zoom-out`) is the subagent type to request\nwhere your harness registers named subagents. Otherwise spawn a general-purpose\nsubagent and tell it to read that persona file first. Pass the prompt verbatim\nand wait for the report. If your harness cannot nest subagents,\nuse direct dispatch instead of the synthesizer. See `docs/harnesses.md`.\nIf your harness has no subagent tool, stop and tell the user: a review in the same\ncontext is not a Goldfish review.\n\n## Inputs\n\nThe caller or user provides exactly these parameters:\n\n*   **`TargetFile`**: Absolute or relative path to target document.\n*   **`SemanticTarget`**: Descriptive targeting string (e.g., *\"Target the H4\n    block with SS-ID 'S1.12'\"*), or `full file`.\n*   **`Reviewers`**: List of reviewer names (shortnames or paths).\n*   **`Standards`**: Mapping of reviewer names to standard names (shortnames or\n    paths).\n*   **`GoldfishContext`**: A reading list (source files, directories, or\n    documentation URLs) fed to reviewers to establish their baseline. An empty\n    list from the caller counts as provided; do not ask for it again. Some\n    reviewers cannot open URLs, so before the first round save the raw page of\n    each URL as a new file in the working directory (or your harness's artifact\n    directory) and pass its absolute path instead. If a page cannot be saved,\n    ask the user for a local copy and end your turn; if no one can answer,\n    as in a headless run, leave it out, tell the user, and keep going.\n\n## Path & Standard Resolution Logic\n\nWhen resolving names in `Reviewers` and `Standards`:\n\n*   **Reviewer Shortnames**: Map reviewer shortname (e.g., `design_critic`,\n    `structural`, `style`, `implementation_readiness`,\n    `codebase_details`, `comprehension`, `zoom_out`) to `agents/{name}.md`.\n    The persona file defines the reviewer's core mandates, audit vectors, and\n    output format.\n*   **Standard Shortnames**: Map standard shortname (e.g., `feature-spec-standard`,\n    `implementation-readiness-standard`, `zoom-out-standard`, `heilmeier-standard`,\n    `re-implementation-standard`) to `resources/document_standards/{name}.md`.\n*   **Custom Paths**: If the name contains a slash (`/`), treat it as an\n    absolute or workspace-relative path and read it directly.\n\n## Execution Workflow\n\n### Step 1: Intake & Configuration UX\n\nEvaluate the provided inputs (`TargetFile`, `SemanticTarget`, `Reviewers`,\n`Standards`, `GoldfishContext`).\n\n1.  **Identify Missing Inputs**: Determine which of the required parameters are\n    missing.\n2.  **Interactive Onboarding**:\n    *   If **all** inputs are present, proceed to Step 2.\n    *   If **some or all** inputs are missing, interactively prompt the user\n        **only for the missing inputs**, one at a time via chat messages.\n3.  **Reviewer Recommendations**:\n    *   *Feature Specs*: Recommend `design_critic` (mapped to\n        `resources/document_standards/feature-spec-standard.md`) and\n        `structural` (mapped to `resources/document_standards/feature-spec-standard.md`).\n    *   *Implementation Plans*: Recommend `implementation_readiness`\n        (mapped to `resources/document_standards/implementation-readiness-standard.md`)\n        and `codebase_details`.\n4.  **Confirm Configuration**: Display the consolidated plan (Target, Reviewers,\n    and mapped Standards) and ask the user to confirm before proceeding.\n\n### Step 2: The Sharpening Loop (Iterative Cycle)\n\nExecute the following sequence in a continuous loop:\n\n#### 2.1 Unconditional Target Resolution\n\nBefore every iteration, unconditionally re-scan `TargetFile` by reading it\nand using the stable `SemanticTarget` string (e.g., locating the target header) to\ndynamically determine the updated absolute start and end line numbers. This\nensures absolute accuracy even if the file was edited in prior rounds. (If `full\nfile` mode is specified, confirm full-file line bounds).\n\n#### 2.2 Review Swarm Execution\n\n1.  **Launch Subagent Swarm**:\n    Spawn subagents to execute the review:\n    *   **Hierarchical Dispatch (Synthesizer)**: Spawn the intermediate\n        synthesizer subagent (`agents/synthesizer.md` / `egm-synthesizer`).\n        The synthesizer spawns the Goldfish review swarm in\n        parallel, deduplicates findings, writes the report artifact, and\n        returns a single summary message to avoid context pollution in the root\n        conversation. Pass it the Failed Reviewers rule below and\n        `GoldfishContext`, and tell it to give those files to each reviewer.\n        Its summary must give a status, `completed` or `not run`, for each\n        requested reviewer.\n    *   **Direct Dispatch (Flat Swarm)**: Alternatively, spawn each requested\n        reviewer subagent in `Reviewers` directly.\n        Instruct each subagent to first read its persona definition in\n        `agents/{name}.md`, then audit `TargetFile` at the resolved line range\n        against its designated standard in `resources/document_standards/`,\n        supplying `GoldfishContext`.\n    *   Each reviewer produces findings with severity (🔴 Blocker, 🟡 Major, 🟢\n        Nit), line numbers, discrepancy descriptions, and rationales.\n2.  **Consolidate Findings**: Collect all findings across reviewers into a single\n    flat `FindingsList`. Give each finding a stable id\n    (`<reviewer>-<round>-<n>`) and record its reviewer, severity, and affected\n    scope.\n3.  **Failed Reviewers**: A reviewer that times out, fails, or returns no report\n    did not review. Retry it once. If it fails again, record it as **not run**\n    in the report. Never count it as a reviewer with zero findings. If the\n    synthesizer summary has no status for a requested reviewer, record that\n    reviewer as not run.\n\n#### 2.3 Aggregated Resolution Hand-off\n\n1.  Pass `TargetFile`, the active line range, and the aggregated `FindingsList`\n    to the **`egm-resolve`** workflow.\n2.  Execute the resolution workflow in the primary Elephant context:\n    *   Categorize findings into `CONTEST` vs. `PROPOSE FIX`.\n    *   Save `goldfish_review_report.md` with your file-writing tool.\n    *   Present the interactive decision gate (Auto accept, Continue, Interactive\n        breakdown).\n    *   Apply approved text repairs to `TargetFile` using your file-editing tool.\n\n#### 2.4 Iteration Check & Turn Boundary\n\nFresh reviewers sample differently each round, so a round with zero findings\nis rare even when the document improves. Use these rules instead:\n\n*   **Settled findings**: A finding is settled when it is contested or\n    recorded without a fix (accepted risk). Keep the settled list across\n    rounds. If a new reviewer raises a settled finding again (same affected\n    scope, same issue), do not re-open it.\n*   **Fixed findings**: An applied fix does not settle a finding. If a later\n    reviewer raises the same issue at the same scope, the fix failed or a\n    later edit reintroduced the issue. Re-open the finding.\n*   **Clean round**: A round is clean when no reviewer raises a Blocker or\n    Major finding that is not settled. Nits do not block. A reviewer recorded\n    as not run makes the round not clean. Decide this from the review results,\n    before you apply the fixes of that round.\n*   **Converged**: Two consecutive clean rounds. One clean round is not enough,\n    because the next fresh reviewer can find a different gap in the same text.\n*   **Cap**: 5 rounds.\n*   **Churn**: A new finding is at the scope of an applied fix, and reverting\n    that fix would resolve it.\n\nOn converged, go to Step 3. On cap or churn, write a short list of the open\nfindings by severity, then ask the user one question: accept and proceed,\ncontinue past the cap, or return the document to drafting.\n\n**Crucial Turn-Taking Requirement**: After the resolution phase finishes for a\ngiven round, the loop driver **MUST respect the turn-taking checkpoint in\n`egm-resolve`**. The driver must remain idle across human turns,\nonly looping back to Step 2.1 when the user explicitly confirms they wish to run\nanother round of review.\n\n### Step 3: Output Boundary & Final Checkpoint\n\nUpon completion (converged, cap or churn accepted by the user, or manual\nhalt):\n\n*   **Programmatic Callers**: If running as a subflow of `egm-review`, exit\n    cleanly to hand execution back to the parent workflow.\n*   **Manual Invocations**: Output a summary of completion in chat: *\"The review\n    loop has completed after [N] rounds ([converged | accepted at cap | halted]).\nOpen findings are in the report. Would you like to proceed to\n    the next stage, or do you have any final questions?\"*\n"
}

SHA-256 of public snapshot: c7c86249879c99a9aea3733b8ae77a66f9d9d03d35cf3fe023e54106e03dbf19