EGM, Superpowers, Ouroboros and pstack: Planning Workflows Compared
Applying pstack to the same internal signing tool task showed clear overlap in planning, design and review. My current choice is to keep EGM and Superpowers as the baseline, select pstack's original route when a plan needs a traceable sequence of decisions and checks, and use an Ouroboros Seed when a structured handoff is useful.
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.
Here EGM refers to the route used for hypothesis exploration and concrete design review. Superpowers is a skill collection that moves from narrowing a design through questions to implementation, debugging and verification. I began this comparison to see where those routes actually helped.
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. The earlier Ouroboros comparison covers that path; this follow-up adds a separate pstack trial.
I first reviewed pstack for distribution and compatibility. Its original workflow also covers planning, design, questions and review. Treating it only as execution management would miss its overlap with EGM, Superpowers and Ouroboros, so I applied it to the same internal signing tool planning task.
I released the same internal signing tool requests to pstack in stages and compared its planning documents and actual review results.
The same three staged inputs, separate authors
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 EGM and Superpowers outputs and released the same original requests in order to a separate Ouroboros author, followed by a separate pstack author:
- 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 original request was revealed. Authors did not use other workflows' outputs or unreleased request text as product evidence. Closure reviewers read frozen inputs in fresh contexts. Follow-up answers came from the same simulated fact reservoir; I did not force identical dialogue or policy choices. Unavailable task contracts and KMS capabilities stayed unknown. The pstack protocol disclosed broad later-stage topics, so this was not a fully blinded experiment.
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.
For pstack I used pinned source version 0.9.120, following original poteto-mode into figure-it-out. This is separate from the selective managed entry and native plugin activation testing. The comparison is a sequential extension of planning documents and actual reviews. It does not control an identical resolved backend or measure gains in real-user effort, cost or speed.
Where the four outputs differed
The initial requester flows and first-question topics were similar. All four asked about a representative signing task and the actual requester, input and result flow. Their plans covered finding the task and preparation requirements, providing inputs, connecting the request to its result, and understanding what to do after failure or an indeterminate outcome. None established actual KMS query, deduplication or recovery capabilities that had not been observed.
| 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 |
| pstack | Design a task-specific planning process with a completion predicate, verifiable units and a decision trail | Intermediate documents and actual tool outputs establish the selected CI unit sequence. The incident plan separates execution history, current result judgment and external use | Trace and hand off decisions across several requirement changes |
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.
In the earlier EGM–Superpowers–Ouroboros comparison, the first two documents contained more selected behavior. The pstack path also leaves some actual policies and KMS contracts open. Both author proposals and facilitator choices contributed to those differences. I compared the specificity of selected behavior and unresolved contracts without converting different simulated conversations into an intrinsic capability ranking.
The pstack planning process observed
The figure-it-out route first designs a task-specific completion predicate, verifiable units and decision trail. The planning predicate was explicitly separate from product release.
Its first question asked for one representative signing task, requester, input and successful result. With no actual example available, the plan narrowed the first scope to requesting one task, finding its result and tracing failures as an operator. It separated authoring from operating promotion, confirmed results from acceptance responses, and confirmed failure from an unknown outcome. Implementation architecture and actual KMS capabilities stayed open.
For CI it first asked whether automatic signing could proceed without human approval. After the simulated facilitator reported that policy as unknown, the plan separated build success from signing authority and permission to omit approval. It bound the result to the original build, input, request and signing task, and separated completed signing from result-delivery failure. A failed delivery was not proposed as grounds for another signing operation. Request-identity fields and automatic retry contracts stayed open pending actual CI and KMS guarantees.
The incident plan distinguishes confirmed incorrect results, potentially affected but unverified requests, requests with normal-result evidence, and untraceable scope. Missing records do not become evidence of no impact. It also separates execution history, current result judgment and delivery/use evidence: completed execution remains in history even when a result is later judged incorrect, and a corrective result should not silently overwrite the original record.
It proposes separate controls for suspect intake and unverified-result delivery, conditional on real capability and operating policy. An internal delivery hold does not establish external recall or deployment recovery. It compares correction and validation, a prior state whose suitability is established, linked corrective results and recovery by external owners. Continuing existing-method use also requires actual task and shared-path evidence.
The initial independent review requested no product-content edit. The changes concerned evidence provenance, coverage and the checklist. Earlier batching of work units, missed pre-code design gates for the evidence checker, and the absent original planning-effort estimate remained in the history. Later corrections were not presented as earlier executions. This prevents a claim of complete fidelity to the original pstack procedure.
Separate product and trail reviews for the CI and incident stages also supported their bounded planning predicates and found no product defect or trail contradiction within the inspected scope. Actual intermediate documents and selected tool calls and outputs supported their write-and-check sequence; neither review requested a body edit. This does not retrospectively resolve the initial omissions or establish complete hidden-context coverage and cross-model review diversity.
Specificity in the incident documents also concerns different populations. EGM more explicitly separated intake reopening, execution of accepted unstarted requests, held-result release and recovery for already-delivered results. pstack emphasized execution history, current result judgment and delivery/use evidence. An equal number of labels would not make these the same design or establish a ranking.
The earlier Ouroboros article retains its delivery-condition correction and individual techniques. This separate follow-up covers the new pstack planning run and combinations across the four workflows.
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.
| Classification and recommended combination | What it helps with | A use case in my work | Why this classification |
|---|---|---|---|
| Baseline · EGM planning/design review → Superpowers Builder Check and the existing work route | Connect exploration and specification review with decisions that change implementation | Set a new signing feature's scope, then identify retry, approval and result-delivery policies to resolve before building | The selected baseline has useful observed roles with distinct purposes. This exercise did not establish a reason to replace its ordinary coordinator |
| Selectable original route · Agreed brief → pstack figure-it-out | Handle task-specific completion predicates, verifiable units and a decision trail in one procedure | Hand off the reasons and checks for a plan that receives CI and incident requirements in successive stages | The original planning route and actual intermediate-artifact reviews were observed. Its use need not be limited to individual borrowed techniques; select it for the relevant planning segment while carrying prior agreements forward |
| Selectable handoff route · Agreed plan → Ouroboros Seed | Fix goals, constraints, assumptions and acceptance criteria as a contract for the next worker | Hand off mandatory artifacts separately from unknown contracts | An actual delivery-condition conflict was found and corrected. That supports use when a structured handoff helps, without requiring a separate Seed after every plan |
| Individual techniques · Add pstack predicates, unit checks and a decision trail to the current route | Record why a particular stage can close without replacing the larger workflow | Add a completion condition and the checked document version to an ongoing design review | These elements can also be borrowed separately. A small agreed task does not automatically need a complete new planning pass |
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, including when selecting pstack. This table proposes uses based on the roles observed in each route; it is not the result of running all four as an integrated workflow.
Complete native Ouroboros and pstack 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. I recommend selecting the planning, review and handoff routes that a task needs while carrying agreed requirements forward.
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
Additional sources: pstack poteto-mode, figure-it-out