Elephant-Goldfish Model: offener Workflow fuer KI-gestuetzte Code-Reviews

A long conversation with a coding agent can make a plan feel settled. The agent knows what you meant. A fresh reviewer still has to understand what you actually wrote.

That’s the idea behind Elephant-Goldfish Model, an open-source workflow I’ve been working on with a small group at Google. Thousands of Googlers already use it.

It covers the work around implementation: exploring an idea, writing a design, challenging the plan, resolving findings, and checking whether the code still follows it.

Suppose you want to add CSV exports to an app.

“Export the current results” sounds straightforward. But which results? The ones visible when you clicked the button, or the ones available when the export job runs? What happens if your permissions change while it’s running? How large can an export get?

These are example questions, not results from an EGM benchmark. They’re the sort of decisions you want to make explicit before implementation.

You can begin with a plain-language idea:

/egm:egm-brainstorm I want to add CSV exports to this app. Help me work through the behavior and constraints before we implement it. Enter fullscreen mode Exit fullscreen mode Install it For Claude Code:

claude plugin marketplace add google/elephant-goldfish-model claude plugin install egm@egm Enter fullscreen mode Exit fullscreen mode It also works with Codex and Antigravity. The setup guides cover each tool.

Brainstorm. Run the prompt above to explore the feature and its constraints. You don’t need an existing spec.

Draft. Use /egm:egm-draft to turn the discussion into a design. Check the behavior and tradeoffs before moving on.

/egm:egm-review docs/designs/csv-export.md Enter fullscreen mode Exit fullscreen mode The Elephant agent keeps your project context. The Goldfish reviewers get the design and relevant code without the conversation that produced them. They have to work from what’s on the page.

Resolve. Read the findings and use /egm:egm-resolve to work through them. A reviewer may flag a real gap, misunderstand a decision, or simply be wrong. You choose what needs changing.

Check for drift. As you implement, /egm:egm-drift-report checks for differences between the design and code. Sometimes the code needs fixing. Sometimes the design needs updating.

I’d try it on a feature with a few meaningful decisions to make: background jobs, permissions, data changes, or a new service boundary.

The reviews take extra time and model usage. A small, obvious change may not need the whole process. A detailed report also isn’t proof that a design is correct. You still need to check the findings and test the implementation.

The plugin is Apache-2.0 licensed. Your usual coding-agent usage costs apply.

Try it on a feature you’re planning and let me know what the reviewers catch or miss in the comments.

(Built at Google, not officially supported by Google.)