AIDiveThe plan nobody reviewed
Google's Elephant-Goldfish Model (EGM) is a free Claude Code plugin that has reviewers with no memory read your plan before any code is written. We installed it and took a real feature of our own app from plan to working code: a reservation system for a family gift list, built on Next.js with a Notion database, run on a copy of the repo.
The planner found the race condition on its own. The holes that mattered were two it never saw: the parents could read who reserved what in their own hosting logs, and a saved browser cookie could be replayed to cancel someone else's reservation. Only the memory-less reviewers found them. The feature built from the reviewed plan had a single winner in all thirty races on the last gift, against a stand-in for Notion. And on a small fix, the review costs far more than the fix itself, so you skip it.
The workflow below is five steps: install, brainstorm and draft, review, resolve, build. The last section gives the rule for when to skip all of it.
What EGM is, and the two-command install
When you ask Claude Code to plan a feature, the agent that wrote the plan is the same one you ask to check it, and it cannot see its own blind spots. EGM, the Elephant-Goldfish Model, is Google's free plugin for that problem. The repository states plainly that it is not an officially supported Google product.
The elephant is the agent you have been talking to: it holds the whole conversation and writes the plan with you. The goldfish are reviewer agents with no memory. They read only the plan and your code, the way a colleague reviews a pull request without having sat in the design meeting. They can read your code but cannot change it, they do not see your project notes, and you make the final call on every choice they raise. The idea comes from Dave Rensin, who wrote that if we are not careful, we are not just writing code faster, we are mass producing our mistakes.
The install runs from your project folder with two commands:
claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm --scope project
The first adds Google's repo as a plugin marketplace, a list Claude Code can install plugins from. The second installs the plugin for this project only. Both returned a green check in about five seconds; start a new session so the plugin loads. The docs ask for Claude Code 2.1.271 or later, because the reviewers rely on the omitClaudeMd setting that hides your project notes from them.
Then add one line to your CLAUDE.md so the reports land in one folder instead of the root of the repo:
EGM artifact directory: docs/egm
The commands cost nothing until you type one: none of them loads into your session on its own. The limit is that the goldfish only read documents. They do not run your app, and they use the same model as you, so they can share its blind spots.
The brainstorm and the draft on a real feature
The brainstorm is for the moment you are about to build something where a wrong decision will cost you later. Our app is a family gift list: relatives tick what they have bought, and the list lives in a Notion database. Everything ran on a copy of the repo with no access to the real list.
The feature: let a relative reserve a gift so nobody buys the same present twice, keep the parents from seeing who reserved what, and allow a cancel. You type the brainstorm command followed by the feature in one sentence:
/egm:egm-brainstorm Let a relative reserve a gift on the list so two people never buy the same one. Parents must not see who reserved what. A reservation can be cancelled.
Before asking anything, it read the code and pointed out that the app has no idea who anyone is, because everybody logs in with one shared password. It then asks questions in several rounds, and a small swarm of goldfish looks at the idea before any section is written. You answer like the product owner. Ours: one shared password, a relative types only a first name, and nothing that names them goes anywhere the parents look. The swarm raised something we had not named: the old edit route that would still let anyone change a quantity by hand.
The planner also named the race condition itself: relatives pressing reserve at the same moment. A race condition is when two requests read the same old value and both write, so one update is silently lost, and Notion's docs offer no way to add a number atomically.
Next, /egm:egm-draft docs/egm/concepts_brief.md writes the design document one section at a time: the written plan of every file before any code. It stopped to ask fifteen times. You approve a section, or pick between architecture options, each listed with how it fails. One choice was where a relative's reservation lives; we picked a signed cookie in their own browser, so nothing with their name reaches the server. The draft even admitted in its own known limits that its fix for the race did not work, because both relatives would read the same value. You end this step with an approved design document in your repo.
The blind review: nine reviewers, two holes the planner never saw
The review is for when you and your agent both think the plan is solid, which is exactly when you cannot see what is missing. You type /egm:egm-review docs/egm/gift-reservations.md; it asks whether the reviewers should read anything else, then asks for a mode. The consolidated mode runs all stages without stopping and hands back one merged list of actions.
The five stages are Initial Zoom Out Review (does the design solve the right problem), Comprehension Review (would a newcomer understand it), Design Critique (structure and wording), Intermediate Zoom Out Review, and Implementation Readiness, which reads your actual code and checks every step of the plan against it. Each stage sends fresh goldfish that have never seen the conversation.
On our design it ran nine reviewers in 7 minutes 24 seconds and did not touch the document; it only wrote reports.
| Review output | Count |
|---|---|
| Reviewer subagents | 9 |
| Raw findings | 77 |
| Blocker / Major / Nit | 1 / 42 / 34 |
| Merged action items | 12 |
It did not find the race: every finding about the race quoted the planner's own admission back. It found two holes nobody had raised:
- Privacy. The parents own the hosting account, and its request logs, with the time and the gift, would let them work out who reserved what.
- Security. A saved copy of the browser cookie could be replayed to cancel someone else's reservation.
It also caught code details that would have surfaced at build time, such as the framework's route parameters being asynchronous and a build that would stay broken for a large part of the plan. On the race it already knew about, its fix was to weaken the goal, which is advice to push back on.
Resolve: you decide, even against the reviewers
The resolve step is where a pile of findings becomes a decision. /egm:egm-resolve turns every report into one table, each issue with a suggestion: escalate, contest, decline, or propose a fix. You accept a fix or contest it with your reason, and it applies only what you accept. You can answer the escalated issues yourself and let it auto-accept the rest.
Ours listed thirty-seven issues, and resolve had already checked the reviewers against the code: it flagged one finding as wrong, a file called unused that the login page still imports.
The big one was the race. The Blocker proposed rewriting the goal as "reduces duplicate purchases, does not prevent them". We contested it and asked for exactly one winner, with Notion as the only store and no names. The agent refused to fake it: "Notion has no way to do that. It has no conditional write and no atomic increment." It offered a few ways out, and we picked a claim ledger: a list of anonymous notes on the gift's own Notion page, one per reservation, read in order to decide who got it. That also closed the cookie hole, since the browser now holds only your own claim, so you can only cancel what you reserved.
The limit: this fix came after the review, so no goldfish read it, and it relies on Notion keeping one order for simultaneous writes, which its docs do not promise. The design says to run its race check on a copy of the real database before shipping.
Build to the plan in a fresh session, then test the race
The risk at build time is an agent that improvises halfway through and drifts from what you decided. Open a fresh session, a new conversation that only knows what is in your files, and give it the design:
Build the feature exactly to the approved design in docs/egm/gift-reservations.md; add tests.
Ours worked alone for 7 minutes 56 seconds, changed 24 files, and the suite came back with Tests 216 passed (216). It flagged where it stepped off the plan (an older test runner version, because the newest needed a newer package) and asked before upgrading. It also found a flaky test in its own setup and made it predictable.
Then test the risky path yourself, because a green suite only proves what somebody thought to test. Two relatives on the last gift at the same second, run thirty times with different timings: each time exactly one reservation went through and the other was told the gift was taken. The parents' view showed the gift complete with no name anywhere, and a cancel put it back.
Those tests run against a stand-in for Notion that behaves like it, with no atomic add and random delays. That is the general rule for outside services in tests: fake them, but make the fake as hostile as the real thing. Before shipping, run the design's own race check on a copy of the real database; the test file even documents the case where both relatives would win.
When to skip it: the rule
On the same app, the README still said there was no login at all although the site has a password: a one-line fix. Plain Claude Code checked the code and fixed it in seconds, without any plugin.
| Path | Cost (API prices, Sonnet 5.5) | Time |
|---|---|---|
| README fix, plain Claude Code | $0.0455 | 10 s |
| EGM brainstorm, draft, review, resolve (before any code) | $7.10 | 32 min |
Google's README says the same thing: "Use it when a feature needs design decisions before implementation. For a small, clear bug fix, use your normal coding workflow." Its FAQ adds that completing the workflow does not prove a productivity gain, and a small pilot on a coding blog found the review added nothing on a feature a plain plan already handled.
EGM pays where a mistake hides outside the conversation, like the parents' logs and the replayable cookie here. On the problem the planner already knew, the decision that fixed it was ours. The rule: before you type the build prompt, ask whether a mistake here touches someone else's data, privacy, permissions or money. If it does, run the review before you build.
