Adding Ouroboros to the EGM–Superpowers comparison
In the previous article, I applied EGM and Superpowers to the same product-planning problem. I wanted to see which decisions and passages actually changed, rather than judge the process by its number of questions or reviewers. I kept the existing workflow and added EGM's hypothesis exploration and design review where they fit.
I then gave Ouroboros the same problem. Its interview-to-Seed flow caught my attention: goals, constraints, assumptions, acceptance criteria and an information model become an explicit specification for the next worker. This article extends the earlier comparison with that path.
The same three stages, a new author
The product was a small internal signing service. People should request signing and find results in one place instead of repeatedly asking an operator to run project-specific scripts. It should reuse an existing KMS and support additional signing methods. I preserved the earlier outputs and released the same requests to a fresh Ouroboros author in order:
- Plan the initial self-service request and result experience.
- Add CI calls after a successful build, with the signing result consumed by the next deployment stage.
- Handle incorrect results from a new signing method while keeping existing-method users working and helping operators understand impact and recovery.
Each document was frozen before the next request was revealed. The author did not use the other workflows' outputs or future requirements as product evidence. Closure reviewers read frozen inputs in fresh contexts. Follow-up answers came from the same simulated fact reservoir, and unavailable task contracts or KMS capabilities remained unknown.
Ouroboros MCP tools were absent from this environment. The pinned source's plugin manifests reported version 0.59.9, so I used its documented Path B for the interview, Seed and review roles, then authored planning documents. This did not execute native run/evolve, real signing or a CI pipeline. The configuration fingerprints also differed between the earlier and new runs, so this was not a controlled same-model performance comparison.
Where the three outputs differed
The initial requester flows were similar: find the signing task and preparation requirements, provide inputs, connect the request to its result, and understand what to do after failure or an indeterminate outcome. None invented KMS query, deduplication or recovery capabilities.
| Workflow | Emphasis in this run | Observed evidence | Where I would use it |
|---|---|---|---|
| EGM | Review a plan from several perspectives and expose responsibilities and conditions | Cost, observability, UX and transition findings entered the brief. Fresh comprehension and critique reviews ran, and incident recovery was separated into four decisions | Explore a new feature or review omissions in a concrete design |
| Superpowers | Narrow product behavior into rules and expose owner decisions that change the build | It proposed a CI reconnection rule that the simulated facilitator selected. Builder Check clarified unknown acceptance versus an unknown KMS outcome | Choose among behaviors for retries, reconnection or result delivery |
| Ouroboros | Package goals, constraints, assumptions and the finished outcome as a separate Seed handoff contract | QA found and corrected an assumed output path that was also mandatory. CI and incident closure reviews required no document edits | Hand agreed requirements and completion criteria to another worker |
Some product behavior was more settled in the earlier outputs. Superpowers proposed reconnecting the same intent identifier and content to the existing request, with different content under the same identifier treated as a conflict; the facilitator chose that proposal. EGM and Ouroboros left actual request identity and retransmission policy open.
For the incident scenario, the Superpowers path selected restrictions on suspect new intake and ordinary automatic delivery of prior suspect results. EGM separated reopening intake, permitting unstarted requests to begin execution, releasing held results, and completing recovery for already-delivered results. Ouroboros compared limiting the entire new method with limiting a reliably identified affected condition, and separated future normalization from follow-up on past results, while leaving the policies unadopted.
The earlier documents therefore contained more selected behavior. The author's proposals and the facilitator's actual choices both contributed to that difference. I did not force every path to select the same policies, so this simulated conversation does not establish a ranking of intrinsic framework capability.
What Ouroboros QA actually fixed
The first Seed put the document's delivery location under assumptions but also made that exact location a mandatory acceptance artifact. A changeable proposal had become a condition for completion.
An independent QA reviewer identified the conflict. The facilitator explicitly adopted the location as a delivery requirement, after which it moved from assumptions to constraints. The goal, acceptance content and information model stayed fixed. I checked that only those two fields changed. After one explicitly selected refinement pass, a fresh QA review confirmed that the conflict was resolved.
This corrected a document-delivery contract. It did not solve a new signing policy or incident-recovery capability. The CI and incident closure guards requested no text edits. I did not turn question counts, reviewer counts or model-assigned QA scores into comparative quality scores.
Four techniques I chose to borrow
Replacing a complete harness and adding a small technique to an existing workflow have different scopes. I chose to bring these four techniques into the existing skills.
| Technique | What it helps with | A use case in my work | Why borrow the technique separately |
|---|---|---|---|
| Confirm consequential interpretations and keep an unknowns ledger | Check how an answer changes scope or constraints and carry unknowns forward | Clarify whether “support CI” means the first release or later work, or whether “keep existing methods working” is a goal or a verified capability | The answer–interpretation–confirmation sequence actually ran. It can be used at consequential interpretation points without reopening a full interview for a small edit |
| Separate closure, hidden-assumption and gap checks | Give reviewers different questions over the same frozen evidence | Distinguish a missing incident-policy decision from an unavailable fact about KMS capabilities | Fresh reviews actually ran. Their objectives, inputs and stopping criteria can fit an existing review; this run did not measure defect reduction |
| Separate constraints, assumptions and finished outcomes, and trace accepted edits | Catch a proposal silently becoming mandatory and check that only adopted changes were applied | Distinguish required handoff artifacts, assumptions and unknown functionality, then compare revisions | A real delivery-path conflict was found and fixed. That contract check does not require the complete execution harness |
| Separate model feedback from executed acceptance authority | Report a favorable QA opinion, an executed check and observed behavior as different evidence | Distinguish copying a skill, discovering a tool and successfully executing a real task | The pinned evaluation instructions make that authority boundary explicit. Local document and YAML checks were not promoted into native approval |
These examples are proposed future uses, not measured benefits in those other projects. The decision to adopt a technique and evidence that it has been applied in each environment are also recorded separately.
Its place in the current workflow
I am keeping egm-brainstorm for a new hypothesis with an unsettled audience, problem or scope, and egm-review for the feature specification of a concrete design draft. Superpowers Builder Check retains its distinct purpose: resolving owner decisions where guessing would change the implementation.
I recommend the Ouroboros interview-to-Seed route selectively when requirements remain unclear and a structured handoff is useful. An already-agreed brief and answers should carry forward into that handoff. Automatically repeating a complete Ouroboros interview after every EGM brainstorming pass is not an integration tested here.
Complete native Ouroboros adoption remains insufficiently evaluated. This exercise did not establish automatic execution or evolution, the mechanical verification pipeline, or gains in real-user effort, cost or speed. For now I am keeping the EGM–Superpowers workflow and adding the parts useful for explicit specifications and handoffs.
In future comparisons I will keep recording which evidence led to a decision and which passage an actual review changed, rather than treating the number of questions or documents as the result.
Related article: What I kept after comparing EGM and Superpowers
Sources: Ouroboros interview instructions, Seed instructions, evaluation instructions