What it takes to trust an agent

Rob Shocks' video "Pocock vs Pstack vs Osmani: Which Skill Pack Wins?" puts Matt Pocock's skills, pstack from poteto (Lauren Tan) at Cursor, and Addy Osmani's agent-skills side by side. Read closely, all three answer the same question: how can work be handed to an agent and the result trusted?

That question is easy to blur into two others. It isn't "automated software development." That is the hoped-for outcome, the place the work ends up once the trust exists. And it isn't blind trust either. Blind trust is the exact failure these packs were written to prevent.

What separates the packs is a theory of where agent work goes wrong. Each one picks a failure point and stacks its checks there. Read that way, the comparison stops being a contest and becomes a map.

Rob's own routing fits the frame. Reach for Pocock when the problem is fuzzy, so intent is the weak point. Reach for Osmani when a team ships to production and needs a process everyone recognizes. Reach for pstack when it gets gnarly: a bug that won't reproduce, a migration, an overnight run that has to be trustworthy by morning. In every case, pick the pack that guards the failure point most likely to bite.

Rob's point that the slash commands aren't the interesting part holds up. The skill files are. Three checks from the Osmani pack transfer to any setup, whether or not the pack itself gets installed.

Anti-rationalization tables. The test-driven-development skill lists the familiar excuses: the code is too simple to test, it was tested manually, the tests can come after, it's only a prototype. Next to each sits the reason it doesn't hold. A prototype becomes production code. A manual check doesn't persist to tomorrow's change. Anyone who has reviewed an agent's reasoning, or a junior engineer's pull request, has heard every line on that list. Writing the excuses down ahead of time is cheap, and it changes the agent's default. The rule is no longer only "write tests." It is also "here is the exact sentence that will tempt a skip, and here is the answer to it."

Doubt-driven development. For any non-trivial decision mid-build, the skill starts a fresh-context review whose only job is to doubt the claim: claim, extract, doubt, reconcile, stop. The repo scopes it to high stakes: production, security, irreversible changes, unfamiliar code. The value is the timing. Adversarial review usually waits for the finished diff. Here it runs while the decision is still cheap to reverse.

/build auto. Approve the plan once and the agent runs every task without a human stepping in between. It removes the stepping, not the checks. Each task is still test-driven, each one gets its own commit, and the run pauses on a failure or a risky step. That is what earned delegation looks like: fewer approvals, the same evidence.

Delegation done right removes the human from between the tasks, not the verification from inside them.

The strongest part of the video argues against installing all of it. A button-color change does not need a PRD, a task breakdown, a five-axis review and a security auditor. It needs the change and a look at the result. Rob calls it matching ceremony to stakes. In trust terms: the checks a task needs are in proportion to what a wrong result would cost.

The pack authors say much the same about their own work. Osmani's adoption guide splits the path in two. A greenfield project can take the full lifecycle from day one. An established codebase gets an incremental, verification-first rollout, so trust builds where the risk is highest. Pocock's README warns against installing the same skills two ways, because the agent then sees every skill twice.

Over-checking has a cost too. Every installed skill is something the agent has to weigh on every turn, and every description is a trigger that can fire when nobody wanted it. Long skill files crowd the context window. More skills do not make a more trustworthy agent. Past a point, they make a distracted one. Rob's suggestion is to go back through the agent instructions file and the installed skills and prune, because current models need far less hand-holding than the files assume.

The setup behind builddaily.io is a useful test case, because it already covers most of the map. Process is the strongest layer. Engineering work runs through a strict lifecycle loop, from discovery and requirements through design, implementation, testing, review, ship, operate and retro, with a gate between each phase and a playbook for each one. Evidence comes from pstack, installed on top for verification. Intent is settled in the requirements and design phases before code starts.

Read against that, most of the Osmani pack would be a second copy of a process that already exists. Two lifecycles loaded at once don't add trust. They add two sets of instructions for the same step, with no rule for which one wins. The real gap is narrower. The playbooks say what to do. They don't list the sentences an agent uses to talk itself out of doing it. Anti-rationalization tables close that gap, and the fix is a small, local edit: add the table to the playbooks where skips actually happen, and leave the rest of the pack on the shelf.

Earning trust also means removing checks that cost more than they catch. This setup has needed that before. The block of standing rules loaded into every session had grown until the "how to apply it" detail outweighed the rules themselves. One cut moved that detail out of the always-loaded context and into an on-demand lookup, fetched only when a rule is about to be acted on. It removed roughly half of the injected rule text, and nothing about the rules changed. A rule states the norm. The detail only matters once the work is already underway.

Open the skill files and old friends turn up everywhere. The Osmani pack credits Software Engineering at Google directly. Hyrum's Law sits in the API design skill: every observable behavior will eventually be depended on by somebody. The Beyonce Rule sits in testing: if it matters, put a test on it. Chesterton's Fence sits in code simplification: don't remove the fence until the reason it was built is known. Pocock quotes The Pragmatic Programmer, Eric Evans, Kent Beck and John Ousterhout. pstack draws on years of work in large codebases at Meta, Netflix and Cursor. None of it is new. These packs are the practices teams already used to trust each other, rewritten in a form an agent can follow.

That is also the path forward. Trust between engineers is never granted all at once. It grows as the work keeps checking out. The same holds for an agent. Today that looks like /build auto: approve the plan once, let the tasks run, keep the per-task evidence. As those checks keep holding, the leash gets longer, toward unattended overnight runs that can be read and trusted in the morning. The checks don't go away as delegation grows. They are the reason it can grow.

So read the packs like a textbook, not a religion. Take the checks that guard the failure points that actually bite, and leave the rest. When the agent gets something wrong, the fix is not frustration at the model. It is one more line in the skill, one more check that has to hold before the next handoff. That is how all three of these packs got written.

Credit to Rob Shocks and Switch Dimension for the series. Claims about each pack were checked against its repo at the time of writing; the packs change often, so check the source before relying on a detail.