The first thing I did with somebody else’s skill was open the file, select all, and paste the text straight into a session. No install, no plugin, no folder in my repository. It ran, I could see what it changed about the reply I got back, and ten minutes later I knew I did not want to keep it.
That trick is worth more than the skill was. I picked it up from a video Theo published on 19 August, in which he spends 38 minutes working through two packages that engineers have put in public: Matt Pocock’s agent folder, and a set called pstack from Lauren Tan.
The process, before the packages
Theo did not start by installing anything. He started by asking his agent to go through his own command history across his machines, weigh it against the skills in a package, and rank them by how well they fit the work he actually does. The output was a ranked document with a line of reasoning per skill.
I have since run the same instruction, and it is the part of the video I would keep if I had to throw the rest away. It starts from your habits rather than from somebody else’s catalogue, and it takes about a minute.
Theo is not a fan of the genre, which is worth knowing before you weigh his enthusiasm. He says he dismissed Pocock’s skills when they first appeared, and that the vast majority of repositories like them are slop that deserves to be ignored. He went through these two anyway, and came out with a handful of files rather than an installation.
Both packages ship under MIT. Pocock’s sits on 228,000 stars and 19,500 forks after 451 commits, which is the number everybody quotes. Tan’s lives inside Cursor’s own plugin repository, and the README is direct about what she is aiming at: she does not want to ship like a team of twenty slop artists, and throughput without quality is not a goal she aspires to.
Why a description is not a description
The mechanism took me a while to understand properly. A skill is a markdown file with a name and a description. Out of every skill you have installed, the model sees those two lines and nothing else. It reads the body only after it has decided, on the strength of that one line, that the file is worth opening. I walked through what this looks like from the outside with the seven design skills that ship inside Claude Code.
Theo calls that line a trigger, which is the same lesson I had already paid for when a skill of my own sat there never being opened. How to write one is the subject of Agent Skills in practice. What matters here is the consequence for borrowed files: a description tuned to get picked up tells you nothing about what the file will do once it is open. Only reading it does.
Sitting next to it is a switch: may the model fire this skill on its own, or do you have to reach for it. Pocock turns model invocation off for most of his, so they wait for a slash command. On his debugging skill he leaves it on, so the model can decide for itself that the moment has arrived. Two categories, two ways of writing the description. Pocock documents them separately, which is the part worth copying. Tan goes the other way and lets the model decide on nearly all of hers, so this is his convention rather than a shared one.
The bill, which is not in any README
arena runs the same task several times over in parallel, reads every candidate, picks a base and grafts the strongest pieces of the others onto it. Theo likes it. He also says it has cost him hundreds of dollars in inference, because it does the work more than once and then pays a model to read all of it.
He does not say how many attempts it fans out to, and the arithmetic is the same either way: N attempts at one task are roughly N times the tokens, plus the pass that reads them all to pick a winner. On a plan with weekly limits you will feel that inside a day. No README leads with this, and it is the number that decides whether the technique is available to you at all.
Two smaller observations from the same video. Pocock’s skill files are full of em dashes, and Theo catches his own agent picking the habit up in its replies, which is a reminder that an instruction file shapes the voice of the model and not only its behaviour. And parts of pstack are wired tightly enough to Cursor that they do not do what they promise anywhere else.
Taking
unslop(pstack). Strips AI writing patterns and puts a voice back in. I run something like it already, as a chain of passes with a gate at the end. The rules underneath Tan’s version are sharper than mine, in particular: say what a thing does, not how it feels, and cut any sentence that could sit unchanged in another project’s documentation.blast radius(pstack). Work out what a change breaks somewhere else before it ships. Nothing in my setup was asking this question.show your work(pstack). A decision log in TSV, one row per decision, append only, a wrong call superseded by a new row rather than edited away.wizard(Pocock). Writes a guide through the steps only a human can perform. My agents stall on a dashboard login about once a week.
Leaving
- The main flow (Pocock), the fixed route from grilling to spec to tickets to implementation to review. It is coherent and it is not how I work. Adopting it would mean adopting the whole method, which is a bigger decision than installing a file.
arena, until I can see the bill in advance.grill me(Pocock), only because I already have a brainstorming skill doing this job. His asks harder questions, and I have stolen two of them.
The caveat
There is no review step for any of this. A pull request that changes behaviour gets read by somebody. A markdown file that changes behaviour gets a star. These files decide what an agent reaches for, in what order, and in whose voice, and the only quality signal attached to them is a counter that measures how many people have heard of the author. No test suite catches a skill that quietly makes your agent worse, because nothing is asserting on the output in the first place.
Letting a skill fire on its own is a standing permission, not a convenience. You are not choosing to use it on this task. You are agreeing that a future version of it may join work you have not thought about yet, on a description you wrote once and forgot. That is the argument for keeping the files in your own repository instead of subscribing to a managed plugin: the managed one moves when the author moves, the copied one moves when you do. Take both and you end up holding every skill twice.
The skill you install is a skill you stop practising. Reaching for blast radius means you are no longer the one asking what a change breaks elsewhere, and after a few months of that you may not notice when the question goes unasked. Theo’s insistence on reading the files before installing them is really about this. The reading is the part that transfers something to you; the installing only transfers it to your agent.
What I am doing
Neither package is installed here. Three files are: copied out, rewritten in my own words, and dropped in the shared folder where the rest of my skills live. The blast radius rule became a question in my review pass rather than a skill of its own. The decision log is queued for the first run I let go unattended.
The paste test stays, though. It costs nothing and it answers the only question that matters at that point, which is whether the thing changes anything you can see.
Frequently asked questions
How do I decide which skills are worth my time?
Have your agent read your own history and rank a package against it, the way Theo did. Then read the top few files yourself before you install anything. They are short, and the ones I opened took a couple of minutes each.
Why does the description of a skill matter so much?
Because it is the only part the model reads before deciding. A skill that never fires is not a skill, and one that fires on the wrong task is worse than not having it.
Can a package like this make my agent write worse?
Yes, and Pocock’s is a live example. His files are full of em dashes and Theo caught his agent copying them into its answers. An instruction file carries a voice whether or not you meant to send one.
Sources
- Theo (t3.gg), “So I tried Matt’s skills…”, YouTube, 19 August 2026. Runtime 38 minutes 22 seconds; 178,000 views as of 21 August 2026.
- Theo (@theo) on X, announcing the same video, 19 August 2026; 198,100 views as of 21 August 2026.
mattpocock/skillson GitHub, README and installation instructions. Retrieved 21 August 2026; 228,000 stars, 19,500 forks, 451 commits, MIT licence.aihero.dev/skills, the documentation for the same package, grouping the skills into getting started, main flow, shaping, upkeep and productivity. Retrieved 21 August 2026.cursor/plugins, directorypstack, README by Lauren Tan. Retrieved 21 August 2026; MIT licence.
Checked on 21 August 2026. Star, fork and view counts are snapshots from that day and will have moved. I have not watched the video: Theo’s remarks come from the automatically generated captions, so the wording is the machine’s and the substance is his. His claim that the package ranks among the ten most starred repositories on GitHub is one I did not verify. One rule I am taking across, about proving the one or two facts a summary rests on by running code, comes up while Theo is working through blast radius. Whether it lives in that file or in the separate prove-it skill of the same package I could not establish, so I quote it without a filename.