A while back we wrote about why we don't hand clients our prompts — the short version being that the prompt is a small ingredient in a system, and it doesn't travel well on its own. A fair follow-up question came back: fine, but then what is worth keeping about prompts?
Our answer: the ones you use more than once.
Two kinds of prompt.
Most of what you type at an AI agent is throwaway. "Rename this variable everywhere." "Explain what this function does." Those prompts are about one moment in one file, and polishing them is wasted effort. Type the sloppy version, get the result, move on.
The second kind is different. It's the prompt you find yourself writing again in a slightly different form every week — interrogate my design before you build it, review this diff like a skeptic, teach me this library properly instead of just doing it for me. That prompt is a small piece of process, and it deserves to be written down once and reused, not improvised each time.
Most agent tools now have a place to put those: skills, commands, rules, whatever the vendor calls them this quarter. The mechanism matters less than the habit. When you catch yourself writing the same instruction a third time, stop and save it.
Then don't write it yourself.
Here's the part people miss. Reusable prompts have a property that one-off prompts don't: they can be shared, and once shared, they accumulate mileage. A prompt that thousands of engineers have run against thousands of codebases has had its failure modes found and patched. Your first draft has had none of that. The value isn't the wording — it's the miles.
So we mostly don't write our own. We start from published collections and adjust.
The one we reach for most is Matt Pocock's skills repository. It's the most-installed collection we know of, and it shows — the skills are opinionated, tightly scoped, and clearly the product of someone using them daily rather than publishing them for effect. Two we use constantly:
- grill-me — the agent interviews you about a plan or design, relentlessly, until every branch of the decision tree is resolved. It's uncomfortable in the right way. Half the time the design changes before a line of code exists, which is exactly when changing it is cheap.
- teach — instead of handing you the answer, the agent teaches you the thing across a working session, using the directory as a stateful workspace. Worth it any time the goal is understanding rather than output.
The other we like is the brainstorming skill from Jesse Vincent's superpowers collection. It sits earlier in the process than grill-me: you arrive with a rough idea, and it refines it through questions, surfaces alternatives you hadn't weighed, and hands back a design document in sections you validate one at a time. It is very good at catching the assumption you didn't know you'd made.
Notice what all three have in common. None of them make the model smarter. They all slow you down at the front of the work and force the thinking to happen before the typing.
The caveats.
Read a skill before you install it. It runs in your repository, with your agent, with whatever permissions that agent has. A prompt from the internet is code from the internet — treat it that way.
And a downloaded skill still isn't the system. It's a better starting point than your first draft, not a replacement for the evaluation, the review, and the plumbing around it. Everything we said in April still holds.
But between writing a clever prompt from scratch and borrowing one that has already survived a hundred thousand engineers, the second is the better bet almost every time. Save the cleverness for the problem.