What pstack Taught My Copilot Agents Dojo

I opened a pstack commit expecting to collect a few prompt-writing tricks. Instead, I found a missing layer in my own framework.

The Copilot Agents Dojo already had a strong spine: plan before coding, use tests, review the diff, prove the work, capture lessons, and keep dangerous operations behind guardrails. It was good at governing an engineering session from start to finish.

pstack, created by Lauren Tan, was sharper at a different moment: the instant an agent meets a particular kind of hard problem. Its architect, arena, and prove-it-works skills do not merely say “think carefully.” They provide a playbook for how to think, what artifact to produce, and when to throw the first answer away.

That distinction changed the Dojo.

The gap was between principles and action

The Dojo had principles. It had a mandatory lifecycle. It had enforcement scripts, persistent lessons, specialist personas, and a distribution model for installing skills into GitHub Copilot.

What it did not always have was a precise move for the difficult middle of a task.

“Plan before code” is sound advice. It still leaves several questions unanswered:

• What exactly should the plan contain when a change crosses a service boundary?
• When should several agents split the work, and when should they independently attempt the same design?
• What counts as proof when the tests pass but the browser, API, CLI, or migration has not been exercised?

pstack answers questions at that level. Its task playbooks sit between a principle and an implementation. The principle says what good looks like. The playbook gives the agent a sequence it can run.

I did not need to replace the Dojo. I needed to fill that layer.

The three patterns I adopted

1. Sketch the contract before filling in the code

pstack’s architect skill starts with types, signatures, module boundaries, and alternatives. Implementation follows the selected shape. If implementation repeatedly needs casts, escape hatches, locks, or special cases, the sketch is treated as disproven and gets replaced.

Most architecture documents become promises that teams defend long after the code has shown them to be wrong. pstack treats the design as a hypothesis.

I turned that idea into a new Dojo skill: architecture-sketching.

For a change that crosses a function, module, service, process, or persistence boundary, the agent now writes a small design contract:

• the problem and a falsifiable success condition;
• inputs, outputs, states, identifiers, errors, and invalid states;
• public signatures, commands, events, or endpoints;
• module ownership and dependency direction;
• credible alternatives and the trade-off that selected one;
• static checks and a real-artifact verification plan;
• observable signals that would invalidate the design.

The skill stays out of the way for a local change with an obvious existing pattern. That was an important adaptation. pstack is deliberately rigorous; the Dojo has to apply rigor proportionally across many repositories and task sizes.

2. Separate parallel work from competing designs

My original subagent-strategy skill treated sub-agents mainly as a decomposition tool. One agent researches the API, another inspects tests, another checks the data layer. Each owns a different workstream.

pstack’s arena exposed a second mode: give several isolated agents the same consequential task, then judge the whole artifacts against one rubric.

Those modes solve different problems.

Decomposition buys throughput. It works when the work can be separated.

Competition buys design diversity. It works when choosing the first plausible architecture would be expensive to reverse.

The revised Dojo skill names both modes. Competition now requires isolated outputs, the same task statement, a concrete rubric, a model-blind judge, and a lead who reads every candidate before selecting a coherent base. The lead may graft compatible strengths from the losing candidates, but it must not average incompatible designs into a committee-shaped mess.

I also added a cost boundary. Routine work with strong local precedent does not belong in an arena. Two or three competing attempts are justified when the decision is consequential and the design space is genuinely open, not because parallel agents look impressive in a terminal.

3. Verify the affected surface

The Dojo already said: tests, logs, and diffs, or it did not happen.

pstack’s prove-it-works principle made the weakness in that sentence obvious. Tests can become a proxy. A green unit suite does not prove that the affected browser flow works, the CLI produces the right output, the public package behaves for a consumer, or a migration survives a retry.

The updated verify-before-done skill now starts with a falsifiable success predicate and ends with one of three verdicts:

Verdict	Meaning
VERIFIED	Evidence on the real affected surface proves the success predicate.
NOT VERIFIED	Evidence shows failure or regression.
INCONCLUSIVE	The check was missing, used the wrong surface, or could not distinguish success from failure.

Only VERIFIED permits the agent to mark the task complete.

The skill also requires the baseline and result to use the same measurement method. If latency was measured one way before a change and another way after it, the comparison is not evidence. If a UI bug was “verified” by reading the source rather than driving the UI, the verdict is INCONCLUSIVE.

This sounds strict until you count how many production mistakes begin with a sentence like “the test passes, so it should be fine.”

What I deliberately did not copy

Learning from another framework is not the same as merging identities.

pstack is strong because its skills are opinionated and deep. The Dojo serves a broader governance role. It has to coordinate planning, implementation, review, memory, safety, installation, drift detection, and repeatable use across GitHub Copilot environments.

So I kept three boundaries.

First, architecture ceremony is conditional. A private helper following an established pattern does not need a design tournament.

Second, competition is exceptional. Most sub-agent work remains decomposition because independent workstreams are cheaper and easier to verify.

Third, a sub-agent summary is never accepted as proof. The lead inspects the cited evidence and the produced artifact. Delegation changes who does the work; it does not change the standard of evidence.

The result is still the Dojo. Its governance model did not become pstack-shaped. Its task reasoning became more precise.

The first evaluation caught a new failure

The most useful part of the work happened after the skills looked finished.

I tested the new architecture skill against a generic cross-boundary payment-webhook design. The first run produced a polished answer with project names, technologies, and business rules that were not in the prompt. It had quietly borrowed context from an unrelated workspace.

The architecture was plausible. The grounding was false.

That failure would have been easy to miss in a style review because the answer looked specific and confident. Specificity is only a virtue when it is earned.

I changed the skill so every project-specific claim must point to repository evidence. When no repository or product context exists, the sketch must stay provider-neutral and label its assumptions. Then I ran the behavior check again.

This was a useful reminder about adopting sophisticated workflows: a stronger reasoning structure can produce a more convincing hallucination if grounding is not part of the structure. Better ceremony does not rescue invented evidence.

What changed in the Dojo

The update added one skill and materially changed two others:

• architecture-sketching now defines data shapes, contracts, ownership, alternatives, verification, and redesign signals before cross-boundary implementation.
• subagent-strategy now distinguishes decomposition from competition and adds isolated candidates, rubric-based judging, and selective synthesis.
• verify-before-done now requires the real affected artifact and records VERIFIED, NOT VERIFIED, or INCONCLUSIVE.

I updated the generated skill index, CLI discovery, bundled manifest, changelog, README, and wiki. The attribution is explicit under the Dojo’s license section: these patterns were adapted from Lauren Tan’s MIT-licensed pstack project rather than presented as ideas that appeared from nowhere.

The updated Dojo plugin is also installed in my GitHub Copilot CLI environment. The practical difference is visible in the agent’s behavior. Before it writes a cross-boundary feature, it can sketch the contract. Before it fans work out, it decides whether the agents should divide the problem or compete on the same one. Before it says “done,” it must prove the result on the surface that a user or system will touch.

The lesson I am keeping

Frameworks for coding agents often have plenty of principles and plenty of tools. The missing piece is the executable reasoning between them.

A principle such as “design first” becomes useful when it names the artifact, the alternatives, the invalidation signal, and the exit condition. “Use multiple agents” becomes useful when it distinguishes parallel ownership from independent competition. “Verify your work” becomes useful when a wrong-surface check is recorded as INCONCLUSIVE instead of quietly passed.

That is what I learned from pstack: make the difficult move explicit enough that an agent can perform it, inspect it, and know when it failed.

The next time one of my agents reaches for code too early, the correction is no longer “think harder.” It is concrete: sketch the boundary, choose the mode, and prove the real thing.

---

Acknowledgement: This article studies the pstack workflow created by Lauren Tan (@poteto) and the Claude Code port commit by Michael Denyer that prompted my review. pstack is MIT-licensed. The Copilot Agents Dojo adaptations retain explicit attribution in the project README, changelog, skill documentation, and wiki.