The design looks complete until someone asks what happens when the same webhook arrives twice. The answer was settled in yesterday's chat, but never made it into the specification. A fresh reviewer cannot remember that conversation. That is the point.

Google's Elephant-Goldfish Model plugin, or EGM, separates a context-rich drafting session from reviewers who read the document and its references without the earlier discussion. The person building the software resolves the trade-offs and approves the specification. The useful question is whether the plan survives without its author's running commentary.

New coverage, not a new launch

MarkTechPost covered EGM on November 8, but Google's announcement is dated October 22. The current release page lists v0.1.1 on November 6. This is a look at the project's present boundaries, not a claim that Google launched it today.

The announcement describes brainstorming, drafting and review. The current README offers separate skills for those jobs, resolving findings, documenting an existing codebase and reporting drift between documents and code. You do not have to run the full sequence for every task. A small fix does not automatically need a design ceremony.

Fresh eyes still need evidence

The README says Goldfish reviews require fresh subagent contexts and stop when the host cannot provide them. A second opinion in the same conversation is not the arrangement the project describes. That does not make the reviewer infallible: it still needs the right document and referenced source material.

The Claude Code integration guide makes the boundary concrete. It requires version 2.1.271 or later for its documented isolation support. A reviewer unable to read a required persona or standard must report the limitation and stop. The guide also says review stages stay sequential, even in uninterrupted mode. Skipping human checkpoints does not mean skipping dependencies between checks.

That distinction matters more than a reassuring final paragraph. Before trusting a review, ask what it could actually read, which checks finished and what remained unverified. A polite summary cannot supply missing evidence.

A verified download is not a verified workflow

The v0.1.1 release notes say ZIP checksums and GitHub Actions attestations were verified against the workflow-built artifacts. They separately say native end-to-end verification of those exact release ZIPs remains open. Integrity answers whether you got the intended package. It does not answer whether that package completes an isolated review in your host.

The same notes label the Cursor, OpenCode V1 and GitHub Copilot adapters experimental. The repository is Apache-2.0 licensed and explicitly not an officially supported Google product. Neither the brand nor a successful download should erase those qualifications.

Try a question the document must answer

For a first evaluation, use a small proposed change and ask a reviewer to explain its failure path from the specification alone. For webhook delivery, that might mean duplicate events, retries and the moment a delivery counts as finished. If the answer depends on a chat the reviewer never saw, revise the document before asking for code.

This is a documentation-led assessment, not a GigSoul runtime test. A reviewed specification still needs implementation tests and human judgment. EGM's most useful promise is earlier disagreement, while changing the plan is cheaper than changing shipped software.