How Theo Evaluates AI Agent Skills: Matt Pocock’s Collection and PStack

I've been watching Matt Pocock's collection of AI skills for engineers for a long time without digging in. After initially dismissing it, I spent the past week trying several of his skills. I also examined PStack, a collection by Lauren, known as Potato, whose work on the React compiler I've admired.

I audited most of the skills in both collections, selected the ones that fit my work and used them actively. There are a lot of skill repositories I wouldn't recommend installing wholesale. These two have useful ideas, but the way you choose and adapt them matters as much as the files themselves.

My first rule is not to copy someone else's setup blindly. Treat it as a source of ideas while you build a system for the work you actually do. Copying a complete setup without understanding it won't teach you much; examining why an instruction works can help you design your own.

I started by asking an agent to inspect my usage across my main machines, compare it with PStack and rank the skills by fit and potential benefit. It produced a report with short explanations, highlighting skills such as interrogate, blast radius, technical writing, arena and prove it works. That gave me a shortlist to review myself.

The skill that drew me in was unslop. I'd seen writing produced with it and thought it sounded less like the generic prose I normally get from agents. Before looking at its content, there's a useful detail about how skill descriptions work: they help the agent decide when to load a skill.

I think of a description as a trigger, not a complete account of everything the skill can do. Like a thumbnail, it should help the right reader find the material. In the systems I'm showing, the model initially sees the name and description, then loads the Markdown instructions when it decides they're relevant.

Unslop tells the agent to scan for patterns, rewrite while preserving meaning and tone, add a voice, then audit the result. The idea is not just to delete familiar AI phrases. It also encourages specific reactions, varied sentence rhythm and concrete details instead of sterile, generic wording.

The skill calls out inflated claims, context-free name dropping, superficial phrases and excessive promotional language. It also asks for plainer language and warns against overusing em dashes. Examples of a bad formulation and a better one can be useful, although examples can't anticipate every possible problem.

My favorite instruction is to say what something does. Instead of describing a database as somehow 'close at hand,' identify an observable behavior, such as the exact string a method returns. If a sentence could appear unchanged in any project's documentation, ask whether it actually tells this reader anything about this project.

To demonstrate, I ask an agent to explain T3 Code and why someone might use it. I also pull up an existing thread about an app build: it states what was done, what remains unverified and what action is needed. That direct, scannable answer is what I want from my agents.

I compare the explanation with a roughly similar prompt in ChatGPT without my skills. I find the unslop version easier to read, especially because it gives concrete capabilities rather than a lot of rhetorical framing. This is my informal comparison, not a controlled study of the skill's effect across all prompts or models.

That experience sent me back through the rest of PStack and then to Matt's collection. Matt's engineering directory includes skills for review, debugging, domain modeling, interviewing, implementation, testing and planning. I want to understand what each one does before bringing it into my own setup.

Grill-with-docs is strikingly short: it starts an interview to sharpen a plan and uses other skills to help create a domain model and decision records. Some skills have model invocation disabled, so a user explicitly calls them; others, such as diagnosing bugs in the version I inspected, can be invoked by the agent when appropriate.

The grilling skill treats a design as a tree of decisions. It asks questions in rounds, working on decisions whose prerequisites are settled, until the user and agent share an understanding. I dislike some of its writing style, but the underlying workflow is interesting enough that I want to try it.

For a quick experiment, I copy the text of the grilling skill into an agent prompt without installing it and ask it to question me about Lakebed, my project. That is an easy way to try a text-only skill. A skill that depends on scripts or other files needs those dependencies too.

The first run finds stale project guidance and competing execution models, then asks who the user is, who pays, what the next milestone is, and whether a capsule is a specification or an implementation detail. These questions get at real choices rather than simply asking me to restate facts the repository already contains.

I try another model with the same task and get questions about Lakebed's purpose, its primary customer, the meaning of autonomy and the capsule. A higher-effort run also investigates in the background. The quick answer options make it practical for me to respond to several questions without a cumbersome question interface.

As I answer, I clarify the product's users, what the agent should control and the boundary between local development and the hosted system. I also see conflicts in the existing guidance: I want simplicity where possible and rewrites where they are beneficial. Even this first pass makes me realize the project needs cleanup.

Matt's teach skill describes a learning workspace that carries state across sessions. The collection also has ask-matt for finding a suitable flow, triage for moving issues through stages, and improve-codebase-architecture, which can use shared design vocabulary and present candidates in an HTML report.

The distinction between user-invoked and model-invoked skills is useful. An explicit skill acts like an action I choose; an automatically invoked one can guide the agent when the task fits. I've found the debugging skill helpful in my own work, and wizard interests me because it can guide a person through steps the agent cannot perform itself.

I keep my skill files in a fleet repository that manages my machines. During the video I ask an agent to check whether wizard has been installed and include a newly added machine. This is how I adapt and distribute the pieces I want rather than adopting an entire collection unchanged.

Matt's documented main flow connects an interview and recorded decisions to a specification, tickets, implementation and code review. Other skills address shaping vague ideas, planning a large effort with wayfinder, building disposable prototypes, or researching answers from primary sources. The collection is broader than a single prompt.

I also like domain modeling and shared vocabulary. I have been recording project-specific terms and glossaries with my agents, so packaging that discipline as a skill makes sense. I'm tempted to install everything, but I prefer to keep my existing setup focused and pull in the parts I actually want.

Back in the Lakebed interview, the agent asks which kind of simplicity matters, which applications the platform must support, how developers and agents divide control, and whether authorized agents can take irreversible actions. It also asks about payments and local simulation. I disagree with several suggested answers, which is useful: the point is to surface decisions, not accept defaults.

I notice that newer responses in my fleet thread are easier for me to read than older ones on the same project. An agent gives a direct explanation of why wizard was missing and then installs it. My comparison is anecdotal, but the difference in writing has made me more willing to read its reports.

I would like a cross-computer skill manager in T3 Code that can enable or disable groups, such as PStack and Matt's skills, as well as individual entries. Many of these files prescribe mental workflows. I don't want every step of my own process dictated, but I do want to borrow useful pieces such as grilling, wizard and architecture cleanup.

Writing-for-agents interests me because agents can produce poor instructions for other agents. Better guidance may help when writing skills, project Markdown or prompts for subagents. Wait-what is a small user-invoked skill for requesting a simpler explanation of an answer that did not land.

A one-off request for simpler language improves that response but doesn't necessarily fix future jargon. Matt's documentation also suggests building shared language earlier through a domain-modeling interview. The wait-what skill is useful when that foundation isn't there yet.

Writing-for-agents discusses context pointers: short pieces of text that tell an agent when and where to find additional material. A skill description and a link in an agent instruction file both do this. If essential material sits behind a weak pointer, the agent may not find it at the right time; I nevertheless find this particular explanation harder to read than PStack's writing.

I experiment with an AI-writing detector and speculate about how the skill files were written, but that tool's output does not establish authorship. What I can say from reading them is that I personally find PStack's prose more accessible and its workflows more applicable to my day-to-day work.

Arena is one PStack skill I've enjoyed. It runs parallel attempts at a task, reads and compares the candidates, chooses a base, incorporates the best ideas from the others and verifies the result. It tracks the phases so they don't silently disappear, but repeated attempts can consume substantial inference budget; I've spent hundreds of dollars using it.

One limitation is that parts of PStack are tied closely to Cursor. I'd love a more tool-neutral version of the ideas. Its bro skill asks for a simpler restatement in ordinary language, much like Matt's wait-what; in the version shown, it too is manually invoked.

Blast-radius asks what a change could break elsewhere and insists on testing the key facts instead of relying on a convincing write-up. I've used it repeatedly and it has caught issues that would have been painful later. It also routes the response through unslop so the findings are readable.

Show-me-your-work offers another idea for long or unattended runs: keep a reviewable decision trail in a TSV file. Each row records a decision or checkpoint, its reason, evidence and result. Corrections get new rows, and reproducible evidence helps a reviewer understand the work without reconstructing the entire conversation.

This tour has become a demonstration of my actual process. I read the skills, try a few and bring across the parts that fit how I work. Starting small is useful: unslop alone changed how willing I am to read what my agents write, but another person may find a different first skill more valuable.

Ask your agent to compare the collections with your own usage history, then read the Markdown before installing anything. Pick what you want, manage it in a way that works for you and adjust it as you learn. A personal repository is one option; installing hundreds of unfamiliar skills is not a substitute for understanding them.

Don't be afraid to edit the Markdown files in your agent configuration. Tuning them has helped me do more work in parallel with less breakage, in my own experience. Explore Matt's collection and PStack, try things, keep the parts you like, discard the rest and make some skills of your own.