How I used Google's Elephant-Goldfish Model and Superpowers to build one feature

Cristian Calabro — Fri, 13 Nov 2026 18:15:28 +0000

Originally published on X.

On November 7, Google Cloud announced the Elephant-Goldfish Model (EGM), an open-source plugin for designing and reviewing software with coding agents.

Google Cloud Tech announcement on X

An agent with the full project context (the elephant) drafts the specification, and subagents with no earlier context (the goldfish) stress-test it before any code is written. You make the architectural decisions and approve the spec before implementation starts. It installs as a plugin in Antigravity, Claude Code, Claude Cowork, Codex, and ChatGPT, and also has working installs in omp and Muse.

I tried it on one feature in a CLI I'm building to check repositories for engineering best practices. The CLI has a scan command with a --targets parameter, so you can pass a JSON or YAML file with the target repositories to scan. I needed to add documentation to this parameter, so I asked my agent, "scan --targets should show a JSON sample and a YAML sample, for targets.json or targets.yml."

I ran the session in Codex CLI and picked GPT-6 Luna because the task was very simple.

Brainstorm

I started with:

$egm:egm-brainstorm scan --targets should show a JSON and YAML sample of targets.json or targets.yml

It asked where the samples should appear: in scan --help, in an error when the file is missing or invalid, or somewhere else. It asked whether the help and CLI.md samples should show the minimal required fields, or optional fields too. I chose to review the hypothesis with the Goldfish reviewers.

That pass used seven lenses:

design_critic: cost, quota, and whether the architecture holds when load grows.
codebase_details: traces, metrics, and how someone would debug this in production.
zoom_out: whether the feature needs to exist now, or whether existing code or a library already does the job.
comprehension: whether the interface is intuitive, and whether errors and steps add friction.
implementation_readiness: how existing clients or stored data move over, and how a rollback would work.
structural: coupling, and whether this is still maintainable later.
inventive_catalyst: a trade-off treated as unavoidable, and a pattern that might remove it, with the new cost of that pattern stated.

It wrote concepts_brief.md.

The seven-lens review raised two risks. The four examples (in scan --help and CLI.md) could drift apart, and users could misunderstand how file extensions select the format or where relative paths resolve. The brief recommended keeping the samples equivalent, naming them targets.json and targets.yml, and explaining the path base.

I asked it to address the risks. It updated the brief so both locations' examples are identical, added a parity check to the acceptance criteria, and explained the filename extensions and the relative path base beside the samples. I said the risks were resolved.

Draft

I ran:

$egm:egm-draft

It wrote design_draft.md. The Overview, The Problem, Goals, and Non-Goals covered the missing file structure in the current help and docs, the parser's current format and path rules, and a documentation-only scope. I approved Overview and Goals.

It added a Technical Plan. I approved that, and it added Alternatives Considered, with pros, cons, and a reason for rejection. I approved that too.

It then added a Detailed Implementation Plan. That section listed the files to create or modify, and a verification plan: build, unit tests, static analysis and formatting, a manual help review, a scanner check, and a workspace review with git status --porcelain. I approved it.

I kept the draft documents outside the repository, but you can commit them if you'd like. Either way, the final design reconciles those drafts. There were no contradictions or additions that change the architecture, the interface, or the dependencies, so the draft stayed aligned with the brief.

By default, it will create the design document inside of a docs/designs folder. The agent created it for me and placed the scan-targets-examples.md document in there. EGM recommends you have a SITEMAP.md inside this folder as an index of design artifacts.

Typecheck, lint, and all the tests passed. The new design file passed its targeted formatting check. The scanner completed with no critical or high findings, and its output contained no absolute workspace path. I did not run the build because the egm-draft skill prohibits building production outputs during design work. Those checks are from the design stage. The only git status change then was the new docs/designs/ directory.

Review

I ran:

$egm:egm-review docs/designs/scan-targets-examples.md

Before the review mode, it asked whether I wanted any context beyond the design document. It said linked files inside the repo are added automatically, and that external links or URLs require approval. I said no additional files.

I selected implementation plan only, to evaluate implementation readiness.

It reported two major findings. I agreed to resolve them with an agent, using the egm-resolve skill. It wrote goldfish_review_report.md for me to check, comment on, or accept. I auto-approved the report as it looked good, and it updated docs/designs/scan-targets-examples.md.

Implementation and drift

From there, the implementation was managed by the Codex agent, with superpowers skills.

At the end, I ran:

$egm:egm-drift-report

It found one drift and wrote 2026-11-08_DRIFT_REPORT.md. The design requires the help and CLI.md to say commit values are compared exactly, but neither says so. I added that note.

My take

EGM earned its place on this small task by catching things I would have shipped without:

The brainstorm review saw that the four examples in scan --help and CLI.md could drift apart, and turned that into a parity check in the acceptance criteria.
The implementation-plan review flagged that the planned scanner check would write its reports into the repository being scanned. My AGENTS.md says to keep private review material out of the repo, and the reviewer picked that up from there. The plan changed to write to a temporary folder outside the repo, and the scanner check later confirmed its output had no absolute workspace path.
The drift report found that the help and CLI.md never said commit values are compared exactly, even though the design required it.

Next to Superpowers

I used Superpowers for the implementation in this trial. On the steps they share, they do the work differently.

Brainstorm: EGM asks clarifying questions, then runs the Goldfish lenses in parallel, each with no earlier conversation, and writes concepts_brief.md. Superpowers asks one question at a time, reads the existing code, offers two or three approaches to pick, and writes the design doc in that same skill.
Design: EGM writes design_draft.md section by section, with an approval after each section, and saves it under docs/designs/. Superpowers writes one design doc, approved before building, under docs/superpowers/specs/.
Implementation plan: EGM puts it in the last section of the design doc, every file to touch, and no real code. Superpowers has a separate writing-plans skill, with small test-first tasks, under docs/superpowers/plans/.
Review: EGM reviews the design in stages, with reviewers that do not have the earlier conversation, then resolves the findings. Superpowers has a fresh agent check the design as a builder, a self-review of the plan, and a heavier review on the code during and after the tasks.
Drift: Unlike Superpowers, EGM has a drift report you run after the implementation.

Why not just Superpowers

Superpowers already covers the build well, so the question is what EGM adds before and after it.

Before the code, the reviewers have none of the conversation. They only see the document, judged through seven lenses, so they can't inherit the assumptions I built up while brainstorming with the agent. EGM's own design notes call this out: a single thread that interviews you, designs, and codes ends up validating its own mistakes. The long drafts and reports also go into files instead of the chat, which keeps the main conversation clean.

After the code, the drift report checks the design against what was actually built. Superpowers has nothing like that.

So I keep Superpowers for the build and add EGM for the design and the drift check.

What I would add

The stops are meant to be there, like in SDD frameworks. What I would add is a conductor skill, so I don't have to type each skill to run in the conversation, and I choose where to stop. I wouldn't stop between the Technical Plan and the Alternatives. The conductor would auto-approve that middle step and write both in one pass.

I wrote this because I wanted to know if EGM adds something to Superpowers, or if it's just more steps. If you've tried it, or you use another way to review designs with agents, I'd like to hear how it went. Leave your questions in the comments too, and I'll answer them.

References

I'm Cristian Calabro, a software engineer with 15+ years of experience. I help early-stage startups set up engineering foundations and bring AI into their daily development work. More at ccalabro.dev and on my remote engineering & AI advisor page.

Follow me on X or LinkedIn for the next write-up.

DEV Community: Cristian Calabro