Elephant-Goldfish Model: Design with Context, Review with Fresh Eyes

After a long conversation with an AI assistant, a plan can sound complete because both of you remember decisions that never made it into the document. A new reader will not have that advantage.

The Elephant-Goldfish Model, or EGM, turns that handoff problem into a design workflow. One context-rich session helps develop the idea and write the specification. Fresh reviewers examine the document without the earlier conversation. You decide which findings matter and approve the design before asking an agent to implement it.[4]

Despite its name, this is a plugin made of skills, reviewer instructions and document standards, not a new foundation model or a replacement for your coding assistant.[4][8]

The elephant remembers; the goldfish asks what the document actually says

The Elephant is the design session. It knows your project, requirements and earlier decisions. Its job is to explore trade-offs and make the plan explicit.[4]

The Goldfish is a reviewer with fresh conversation context. It receives the review task, the document and, where appropriate, referenced source material. It should not need the private history of how the author arrived at the proposal.[4][7]

This does not mean every reviewer knows nothing about the codebase. The comprehension phase reads the document alone; other phases can use an approved reading list and source files. The useful distinction is no inherited design conversation, not “no information.”[6]

Consider an order-confirmation webhook. A happy-path description might say, “Send the event to the customer.” An implementer still needs to know:

What happens when the receiver times out?
Can the same event be delivered twice, and how is it identified?
Which failures are retried, and when do retries stop?
How are requests authenticated and failures made visible?

These are illustrative design questions, not results from a test I ran. A fresh reviewer can expose decisions the author assumed were obvious. The document then becomes a better handoff to another engineer or agent.

What the plugin produces

The core sequence is familiar engineering work, with agents helping to organize it:[5]

Brainstorm: clarify the idea and challenge assumptions; save the agreed direction in concepts_brief.md.
Draft: turn the brief into a design document, reviewing sections with the human. The README’s quickstart uses design_draft.md; approved specifications can be kept under docs/designs/.
Review: fresh reviewers return findings about the proposal and its implementation plan.
Human decision: accept or contest findings, resolve trade-offs and approve the specification.
Implement separately: ask your coding agent to build the reviewed plan, then run the appropriate tests.

EGM also includes bootstrap for generating or updating codebase documentation, and drift reporting for comparing designs with current source. A drift report identifies differences; it does not establish that the code is wrong or automatically decide whether the code or the document should change.[5][11]

The plugin does not replace implementation testing. A clear specification can still describe the wrong product, and a plausible review can still miss a defect.

The current review is more than “ask another AI”

Google’s October 22 launch article describes three broad checks: comprehension, adversarial critique and implementation readiness. The current pinned review skill specifies five sequential phases:[1][6]

Initial zoom-out review: challenge the framing and consider alternatives.
Comprehension: restate the proposal and explain the existing system as the document describes it.
Design critique: inspect the design, structure and writing.
Intermediate zoom-out: revisit the whole proposal after the earlier findings.
Implementation readiness: check whether the detailed plan is actionable and consistent with the code.

The comprehension review is especially useful: asking a reviewer to explain a plan in its own words can reveal a misunderstanding that a list of grammar corrections would miss. EGM’s reviewer prompt explicitly asks for that paraphrase.[6]

There are interactive checkpoints and an uninterrupted reporting mode. The full pipeline is not mandatory for every task; the guide recommends choosing the skill that addresses the current bottleneck rather than forcing a design ceremony onto a simple fix.[5][6]

Fresh context is not a security sandbox

EGM requires a host session that can create fresh subagents. Its review instructions say to stop if that capability is absent, rather than pretend that another answer in the same conversation is a Goldfish review.[6]

There is another boundary worth checking: removing parent conversation turns does not necessarily remove host-injected instruction files. The current documentation distinguishes those two forms of isolation. Issue #237 reports that tested Codex and Antigravity versions still supplied project or user instruction files to reviewers even though parent conversation history was absent.[3][7]

Claude adapters use omitClaudeMd: true; that is a host-specific mechanism, not a universal property of every EGM installation. The docs do not establish a verified equivalent for excluding instruction files on Codex or Antigravity.[7]

Fresh reviewers can therefore help challenge unstated assumptions without being guaranteed unbiased, independent of every prior, or isolated from the filesystem. Human approval steps and “read-only” persona instructions should not be mistaken for a universal permission-enforcement layer.

Installation depends on the actual host

Install the complete plugin, not just its skills/ folder: the skills read reviewer prompts and document standards from other directories.[7]

For Claude Code, the reviewed README gives:[4]

claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm

Start a new session. In Claude Code, use the /egm: prefix, for example:[4]

/egm:egm-brainstorm Add reliable order-confirmation webhooks.
/egm:egm-draft
/egm:egm-review design_draft.md

Run those as separate workflow steps, using the draft path the agent actually returns. Do not paste them as a single shell command.

For Codex CLI, the README gives a different install verb:[4]

codex plugin marketplace add google/elephant-goldfish-model
codex plugin add egm@egm

Then select the EGM skill from the skill picker. An installed plugin is not enough if the current session cannot create fresh reviewers.[4][7]

The support matrix is more precise than the phrase “works with AI assistants.” Antigravity CLI, Claude Code and Codex have upstream-recorded workflow fixtures, with specific isolation limits. Standalone Antigravity IDE is documented as unsupported for Goldfish reviews because it lacks the required delegation tool. Cloud surfaces have remaining trace-verification gaps, and the v0.1.1 release describes Cursor, OpenCode and GitHub Copilot adapters as experimental.[2][7][10]

These are installation instructions and upstream support claims, not installations I performed.

Privacy, cost and evidence

The runtime has no separate EGM account, hosted backend, database or telemetry endpoint. That does not make the workflow automatically local or confidential. Your chosen assistant processes files, prompts and reviewer activity under its own settings and policies. Generated documents may repeat sensitive input, and local artifacts persist until deleted.[8]

Bootstrap can run discovery commands and a project-configured formatter. EGM declares no MCP server and installs no permission-approval hook; review access and command execution still depend on the host’s controls. Supply only the files needed and inspect project commands before authorizing them.[8]

The project is Apache-2.0 licensed and explicitly not an officially supported Google product. Open-source licensing does not remove your model provider’s quota, inference bill or review time.[4]

Google’s launch post says thousands of its engineers use the plugin. That is an attributed adoption claim, not a controlled benchmark proving fewer bugs, a particular productivity gain or cost savings.[1]

The repository records offline structural tests and version-specific native workflow fixtures. Its FAQ is refreshingly direct: completing the workflow alone does not demonstrate a productivity improvement. The v0.1.1 release also leaves native end-to-end verification of its exact release ZIPs open, despite artifact checksum and attestation checks.[2][9][10]

I reviewed documentation, selected prompts and manifests at e9e1f06aa4e26e95cd4ed37210a0632202c429e9. This is a source review, not a live EGM session, an installation test, a security audit or a reproduction of an effectiveness benchmark.

Where I would use it

I would try EGM on a feature with consequential decisions: authentication, payments, a public API, data migration or a multi-service change. Those are cases where an omitted assumption can be expensive after implementation.

For a typo or a small, well-understood bug, several review rounds may add more overhead than value. The project’s own FAQ acknowledges that documentation and review can become a bottleneck.[9]

Before adopting the full process, compare it with your normal workflow on similar tasks. Record total elapsed time, model cost, useful findings, false alarms and rework discovered after implementation. More reviewer reports are not automatically better engineering.

My takeaway: use a long-context session to develop the plan, then make the plan survive a handoff. If a fresh reviewer cannot explain what you intend, fix the specification before generating more code.

Sources