Save the method, not the prompt
A colleague who knows I use AI daily as a thinking partner asked if I had a prompt I would like to contribute to the library. “Of course,” I said.
The one that immediately came to mind was: “What circle of hell are you in where the punishment is writing for a prompt library?”
I didn’t say that out loud because without exception the colleagues who invest their time to build and maintain these libraries genuinely want to help other people use AI easily and more effectively. I do too. So let me explain my reaction.
Most of the craft when using AI as a thinking partner is not in a prompt. It’s in the conversation. The good stuff is in the third or fourth or fourteenth exchange, not in response to the first thing you typed. A library can’t help you there. It’s a search habit, and AI as a thinking partner isn’t search. You don’t look things up. You talk to it. A saved prompt is one frozen turn of a conversation that was valuable only because it kept going.
That’s also why a bigger library of thinking partner prompts is a worse one. The more prompts it holds, the more time you spend deciding which stranger’s prompt fits your situation. Deciding that is the hard part. It’s something AI could help you with, if you just talked to it.
So for everyday work, skip the library. You don’t need a better prompt. You need to get better at the conversation.
But there’s a real exception, and it’s worth taking seriously.
Some of my thinking patterns are worth keeping. I use them again and again. When that’s true, your instinct might be to save the prompts. That’s the wrong thing to save. What’s worth keeping isn’t the words you typed once. It’s how you approach a kind of problem. And how you approach a problem isn’t a prompt. It’s a set of instructions.
Save the method, not the prompt.
So what does it mean to save a method? You write down how you think through a kind of problem, the moves you make and the questions you ask. Ask AI to help strengthen that approach. Then build it into a custom assistant.
Open it inside your conversational AI tool, and it runs your thinking pattern instead of starting from nothing. It holds the method and runs it when you ask. Every major AI tool lets you make a custom assistant this way — by writing instructions, with no code.
Here’s one of mine.
When my data points to a recommendation, my first move is to find what’s wrong with it before anyone else does. Not whether the recommendation is good. What would have to be true for it to be good, and whether those things actually hold. That’s where insight either turns into action or quietly dies.
A weak recommendation gets picked apart in the room, and the finding behind it goes down with it. So I go looking for the weak spot myself, while I can still fix it. I do this constantly. So I built it into a custom assistant.
It runs four moves, in order. It finds the one word my argument is leaning on and makes me say what I mean. It turns my opinion into conditions I can actually test. It names the one condition I’m avoiding. And it offers a way to reframe so there’s a path forward.
I don’t run it at the end, on a finished analysis. I run it the moment a recommendation starts feeling obvious. Every time.
And I do it early on purpose, because how I shape one recommendation shapes the next one. If I wait until everything is built on an answer that felt obvious, pulling it back out costs too much. Caught early, it’s just a sentence I haven’t sent yet.
Here’s what that looks like, with the details changed.
My data shows customers are frustrated with a pro-grade saw. The blade guard gets in the way of a common cut. So people are taking the guard off to get the work done. That’s a loyalty problem and a safety problem at the same time. We can’t make the guard easy to remove. But there’s a jig that makes the cut safely with the guard on.
The recommendation writes itself. Put the jig in every box. Everyone has it. The frustration goes away. Done. That’s the draft I’m typing when I stop and hand it to the assistant.
The assistant does not tell me I’m smart. Nor does it simply criticize. It runs the full four-step method.
It finds the word holding up my whole plan — bundle. When I say bundling the jig protects the relationship, it asks who it protects, and at what cost to whom. That forces me to admit the thing I skipped. Adding a part to the box raises the price.
Then it lays out what would have to be true for “bundle the jig” to actually protect the relationship. The jig has to solve the cut. People have to use it in the moment they’re frustrated. And adding it can’t create a new cost that hurts the same relationship I’m trying to protect.
That last one is the condition I didn’t want to look at. A price increase is its own loyalty event. It lands on every customer, not just the ones fighting the guard. So my clean fix might trade a small group’s frustration for a larger group’s resentment. The thing I walked in calling a solution might make the relationship worse.
Then it shows me a way through. Don’t treat “bundle it” as one move. Break it apart. We could give the jig free to the people who hit the wall, so the cost follows the problem instead of the whole base. Or put it in every box only if it can be done without raising the price.
The point isn’t for me to leave with a better answer. I leave with a better question. “Can we get the jig to the people who need it without a price change that costs more relationship than it saves?”
In my first draft, the slide had a recommendation on it. Bundle the jig into every box. A specific action, and I was sure it was right. The method showed my recommendation would have been dead on arrival. The packaging call isn’t mine to make, and the first person to do the math on a base-wide price increase would have killed it. The insight would have died on that slide.
So instead of putting a recommended action on the slide, I put the question — which reframed the problem and pointed at a specific opportunity space. That might sound like a hedge that made my insight less actionable. It’s the opposite. The question is more actionable because my initial recommendation was never going to survive first contact with reality.
Then I took that thinking to the next recommendation in the analysis. Once I’d seen it, I couldn’t unsee it. Every place I’d written down a specific action, I asked the same thing. Would this die in the room, or does it give the team a problem they can feasibly address?
Now, the fair objection. Couldn’t I just put a prompt in the library that says do all four of those things? Find my load-bearing word. Turn my lean into conditions. Name the one I’m avoiding. Offer a reframe.
I could. It might even work. But I wouldn’t use it.
This method’s whole job is to interrupt me the moment I’m most sure. And that moment, the one where the obvious answer is already flowing onto the page, is exactly when I will not stop, go find a prompt, paste it in, and feed it my situation so it can tell me I’m wrong.
The moment I need it most is the moment I’m least willing to go get it. A tool for doubting yourself can’t live somewhere that takes an act of will to reach. The will is the whole problem. So it has to be sitting there already. Something I open as a reflex.
The assistant doesn’t make me more efficient — it makes me do the critical thinking I would have skipped.
I offered my custom assistant to my colleague instead of a prompt.
A note on names. The thing I keep calling a custom assistant goes by a different name on every platform. Copilot calls it an Agent. ChatGPT calls it a custom GPT. Gemini calls it a Gem. Claude calls it a Project. Same idea every time. You save a method and open it when you need it from inside the platform. The label changes. The move doesn’t.