What I Kept After Comparing EGM and Superpowers

When using AI coding tools, changing the order of the work can matter as much as changing the model. When should the agent ask questions? What should it write down? Who should review the design before implementation begins? While looking at tools that organize this process, I came across EGM in Google's GitHub organization. I was already using Superpowers, so I wanted to understand what EGM could add to my workflow.

Superpowers packages a development process into composable skills: understanding requirements, designing a solution, planning implementation, testing, and reviewing code. It helps an agent establish what it is supposed to build before turning an agreed design into engineering tasks.

EGM stands for Elephant-Goldfish Model. The author retains project context and earlier discussion. Fresh reviewers read the document and specified evidence without inheriting that conversation. I was interested in how this arrangement checks whether assumptions that seem obvious to the author are actually present in the document.

Superpowers also uses a fresh reviewer through its Builder Check. That reviewer asks what they would still need to know before planning the build, focusing on consequential decisions where a wrong guess would change the result. The useful comparison was therefore what each review examined and what it actually changed.

At first, a feature list seemed like a reasonable starting point. But finding brainstorming and review in both projects did not establish which was better. I wanted to see which questions were resolved, which contracts remained open, and how the documents changed after review.

I used a signing-service planning problem. The initial brief covered submitting a job and checking its result. I then added a CI requirement, followed by an incident in which a newly added signing method produced an incorrect result. Each stage's documents were preserved before the next requirement was revealed.

Separate drafting agents followed Superpowers 7.0.1 and a pinned EGM revision, with actual fresh reviewers. They were not given the other side's documents, future requirements, or the existing implementation. Interview answers and choices were simulated, however. This was a source-guided planning and review exercise, rather than a performance test of the two original plugins running unchanged in the same environment. I did not measure real user effort, inference cost, or speed.

The core product flows ended up quite similar. Both covered inputs, requests, progress, results, and evidence an operator could follow. Even their first questions took a similar approach: describe how a recent real request moved from preparation to using the result.

The differences appeared in specific decisions. For a CI call retried after a connection failure, the Superpowers side proposed reconnecting to the existing request when intent and content matched, and treating changed content as a conflict. That proposal was selected during the exercise. The EGM side retained request identity and retransmission handling as contracts still to be decided. One document contained a selected product rule; the other explicitly retained an open decision. The facilitator's choices and deferrals influenced that difference. Assessing which choice fit the actual service would require evidence about its lookup and duplicate-handling capabilities.

What I wanted to keep from EGM was the connection between review and revision. A fresh reader restated both the proposal and the existing situation described in the document, and the author checked those explanations against the intended meaning. No mismatch was found in that comprehension check. It still provided a clear record of what had been checked. EGM's specification-review procedure separates this comprehension work from design, structural, and wording critiques.

An actual revision was small but concrete: wording about “restarting” an unstarted request became permission to start execution. Findings were linked to evidence, dispositions, and exact changes, making it possible to check that a wording edit preserved the existing policy. The observed changes concerned terminology, references, and repeated explanations. I did not count them as newly created recovery policies.

The exercise did not establish enough benefit to replace my entire development process with EGM. It did give me reasons to use its multi-lens brainstorming and independent specification review where they fit. Applying cost, usability, migration, observability, simplicity, and maintenance perspectives to the same hypothesis was also worth keeping.

I settled on the following arrangement:

• Use egm-brainstorm when a new feature's audience, problem, or scope is still unsettled.
• Use egm-review for the feature specification when a substantial design draft exists.
• Continue with the existing Superpowers process for implementation planning, development, testing, and code review. Retain the distinct Builder Check objective of resolving unanswered decisions that affect the build.

To support that arrangement, I adapted the relevant EGM instructions into two skills with their own reference material and documented their entry conditions and return path in AGENTS.md. I left the Superpowers plugin files unchanged. The routing also avoids restarting questions already answered for the same hypothesis or running two complete brainstorming passes back to back. These are instruction-based selection rules; automatic invocation has not been verified in every environment.

For now, Superpowers remains my default development process, with EGM's methods available where I need hypothesis exploration or specification review. The comparison also left me with a practical evaluation criterion: look at which decisions and documents actually changed through the process, rather than treating the number of review stages as a quality score.