An AI skills library holds saved procedures organised by industry, so a job that recurs in your line of work is invoked rather than re-explained each time. The useful ones come from operators describing a job they actually do, which is why a library grows by request: somebody names the task, it gets built, and everyone in that industry gets it.
What Is an AI Skills Library?
An AI skills library is a collection of reusable procedures an agent can invoke, catalogued so people can find the one matching the job in front of them. It differs from a prompt collection in that each entry carries steps and reference material rather than only wording, and it is organised by trade rather than by technique.
In Dubb Agent the library sits in the left navigation under skills, grouped by industry at the top. You switch on the ones relevant to your work, and the agent then knows how to do those jobs without being walked through them.
Table of Contents
- A Library, Not a Prompt Folder
- How the Library Gets Built
- Browsing by Industry
- What a Good Skill Request Looks Like
- Three Requests Worth Stealing
- From Skill to Routine
- Mapping Routines to the Funnel
- Where Skills Belong Compared
- Common Mistakes and Troubleshooting
- Best Practices I Actually Follow
- Proof: Why This Actually Works
- Frequently Asked Questions
- Name the Job
A Library, Not a Prompt Folder
Most people who work seriously with AI end up with a document of prompts that worked. It is better than nothing and it has two problems.
It is yours alone. The prompt you refined over six months sits in your notes, and the person doing the identical job three towns over refines their own from scratch.
It is only wording. A prompt says how to ask. A skill carries the steps, the format, and the reference material the job needs, so it produces the same shape of output every time rather than whatever the phrasing happened to elicit.
A library fixes both. The procedure is built once, held centrally, and improved as people use it, which means the version you switch on today is better than the version the first person requested.
That is the argument for a shared library over a personal folder, and it only works if the library actually contains your job. Which is the rest of this article.
How the Library Gets Built
Four steps, and the first is the one that decides everything.
Listening. Someone describes a job they do repeatedly and would rather not keep explaining.
Solving. That job gets turned into a procedure, with the steps and reference material attached.
Publishing. It goes into the library under the relevant industry, where anyone can switch it on.
Improving. Use reveals what the first version missed, and the skill gets revised.
Worth being blunt about where the burden sits. The listening is our job, not yours. But listening only works if somebody talks, and the reason a library has gaps is almost never that the job was too hard to build. It is that nobody said out loud that they do it.
That is the whole ask in this article. If you are doing something repeatedly and there is no skill for it, say so.
Browsing by Industry
The library is grouped by industry at the top, which matters more than it sounds.
Organising by technique would mean categories like summarising, drafting, analysing, and you would then have to translate your actual job into whichever abstraction fits. Organising by trade means you look under your own industry and find jobs described the way you would describe them.
Two things follow from that. If your industry is not listed, it can be added; an absent industry is a gap rather than a decision. And if your industry is listed but the specific job is not, that is the more common case and the easier one to fix.
Look before you build anything custom. The thing you were about to write a long prompt for may already exist under your trade, built and refined by someone with the same problem.
What a Good Skill Request Looks Like
The difference between a request that becomes a good skill and one that stalls is almost entirely in how the job is described.
| Include | Why It Decides the Result | Weak Version |
|---|---|---|
| The job, not the tool | Describes an outcome someone can build toward | "Something for reports" |
| How often you do it | Frequency is what separates a skill from a one-off prompt | Leaving it unsaid |
| What goes in | Names the inputs, so the skill can ask for them | Assuming it knows your data |
| What good output looks like | A format, a length, a structure. This is where most requests are thin | "Make it professional" |
| What happens next | Decides whether it should stay a skill or become a routine | Stopping at the document |
The fourth row is where most requests fail. Everyone can describe the job; far fewer can describe what a good result looks like, and without that the skill gets built to someone else's taste.
Three Requests Worth Stealing
Concrete beats abstract, so here are three shaped the way a request should be.
Real estate: a competitive analysis report. Compare a property against named comparables, weigh the factors an agent actually weighs, and produce it in a consistent layout with your branding. Done weekly, sometimes daily. The inputs are addresses and comparables; the output is a document you hand a seller.
Insurance: a quote. Take the client details and coverage requirements, apply the structure a quote needs, and produce something consistent every time. The value is not speed so much as sameness, since a quote that varies in shape between clients is harder to explain and easier to get wrong.
Any small business: a review and testimonial follow-up. Go to existing clients and ask for reviews, testimonials and case studies. This one is interesting because it barely stops at a document. The output is outreach, which means it wants to be a routine rather than a skill, and that distinction is the next section.
Notice what the three have in common. Each is a job somebody does on a schedule, each has a recognisable good output, and none of them is "help me with AI."
From Skill to Routine
A skill is invoked. You decide it is time and you run it. That is the right shape for anything where you choose the moment, such as producing an analysis when a seller asks.
A routine runs on its own. It carries the same procedure but attaches a schedule, so the work happens whether or not you remembered.
The test is simple. If you would forget to run it, it wants to be a routine. The review follow-up above is the clearest case: nobody forgets how to ask for a testimonial, they forget to ask at all, and a schedule fixes the actual problem.
This is also why it is worth mentioning what happens after the output when you request a skill. If the valuable part is a document you will use immediately, a skill is right. If the valuable part is that something happened on Tuesday without you, say so, and what gets built is a routine instead.
Mapping Routines to the Funnel
Once several routines are running, a useful way to check the set is to lay them against the funnel and look for gaps.
Top. Anything that finds or researches people who are not yet in conversation with you.
Middle. Anything that keeps an existing conversation moving, particularly the follow-ups that go missing during a busy week.
Bottom. Anything that supports a decision already being made, which is where proposals, references and social proof sit.
Most people who build a few routines discover they have three at the top and none at the bottom, because finding new people feels like progress and following up on a quiet proposal does not. The gap is usually at the bottom, and the bottom is where the money already is.
That is a fifteen-minute audit and it tends to be uncomfortable in a useful way.
Where Skills Belong Compared
Three reasonable places to keep a repeatable procedure, and they are not equivalent.
| Where It Lives | Who Benefits | Who Improves It | Best Fit |
|---|---|---|---|
| A shared skills library | Everyone in that industry | Whoever maintains it, informed by use | Jobs many people in a trade do the same way |
| A custom skill you build | You, and your team if you share it | You | Anything genuinely specific to how your business works |
| A prompt in a document | You, while you remember it exists | Nobody, usually | Something you do occasionally and can afford to get slightly wrong |
The middle row deserves defending. Plenty of what your business does is genuinely yours, and a library entry built for an industry will not capture it. The question is only whether the job is specific to you or specific to your trade, and people routinely assume the first when the second is true.
Common Mistakes and Troubleshooting
Building custom before browsing. Look under your industry first. The long prompt you were about to write may exist.
Requesting a tool rather than a job. Describe the outcome you need, not the feature you imagine.
Leaving out what good looks like. Without a format and a structure, it gets built to someone else's taste.
Assuming an absent industry is a decision. It is a gap. Missing industries can be added.
Stopping at the document. Say what happens after the output, because that decides skill versus routine.
Switching on everything. Enable what matches your work. A library you have not read is not an advantage.
Never revisiting. Skills get improved. The version you switched on months ago may have moved.
Best Practices I Actually Follow
Browse your industry before building anything. Five minutes, and it regularly saves an afternoon.
Write requests as job descriptions. The job, the frequency, the inputs, what good output looks like, what happens next.
Ask for a routine when you would forget to run it. That is the honest test and it is not about the complexity of the work.
Audit against the funnel quarterly. Look for the bottom-of-funnel gap, because it is nearly always there.
Say the thing out loud. A gap nobody names does not get filled, and describing your own job is not an imposition on anyone.
Proof: Why This Actually Works
The mechanism is unremarkable. Most jobs inside an industry are done roughly the same way by most people in it, so building the procedure once and sharing it is simply cheaper than everyone deriving their own.
Two patterns hold consistently across the people we help. The first concerns requests. The ones that turn into good skills describe a recurring job and what a good result looks like; the ones that stall describe a capability someone would like to have. The difference is not effort, it is specificity, and it is visible in the first sentence.
The second concerns what happens after a skill exists. People who convert a frequently used skill into a scheduled routine still use it months later, and people who leave it as something to invoke manually gradually stop. The work did not get harder. Remembering did.
Methodology note: these are directional observations drawn from aggregated, anonymized usage patterns across Dubb users, not a controlled study. No figures are attached to either pattern, and the picture varies by industry and by how repetitive the underlying work is.
What I take from it is that the scarce input is description rather than engineering. Building a skill from a clear account of a job is straightforward. Getting the clear account is the part that depends on somebody speaking up.
Frequently Asked Questions
What is an AI skills library?
A collection of reusable procedures an agent can invoke, catalogued so you can find the one matching the job in front of you. Each entry carries steps and reference material rather than only wording, and the collection is grouped by industry rather than by technique.
The practical difference from a personal prompt document is that a library entry is built once, shared, and improved through use, so the version you switch on is better than the version the first person asked for.
How is a skill different from a prompt?
A prompt is how you ask. A skill is the procedure: the steps, the output format, and the reference material the job needs, saved so it runs the same way every time.
That difference shows up in consistency. A prompt gives you whatever the phrasing happened to elicit that day, while a skill produces the same shape of output whoever runs it.
What if my industry is not in the library?
It can be added. An absent industry is a gap rather than a decision, and the same is true of a missing job inside an industry that is already listed, which is the more common case.
Look under your trade before building anything custom. The thing you were about to write a long prompt for may already exist, built and refined by somebody with the same problem.
How do I request a new skill?
Describe the job rather than the tool. Say what the job is, how often you do it, what goes in, what a good result looks like as a format and a structure, and what happens after the output exists.
The fourth of those is where most requests are thin. Everyone can describe the job; far fewer describe what good output looks like, and without that it gets built to someone else's taste.
Should it be a skill or a routine?
If you would forget to run it, it wants to be a routine. A skill is invoked when you decide the moment has come, which suits work like producing an analysis because a client asked for one.
A routine attaches a schedule, so it happens whether or not you remembered. Asking clients for testimonials is the clearest example: nobody forgets how, they forget to do it at all, and only a schedule fixes that.
How should I check whether I have the right routines?
Lay them against your funnel. Top of funnel finds people not yet in conversation with you, middle keeps existing conversations moving, and bottom supports a decision already being made.
Most people find three at the top and none at the bottom, because finding new people feels like progress and chasing a quiet proposal does not. The gap is usually at the bottom, which is where the nearest revenue already sits.
Name the Job
The short version: open the skills library, look under your own industry before building anything, switch on what matches your work, and convert the ones you would forget to run into routines.
Then, if the job you actually do is not there, say so. The building is not the bottleneck and never has been. Somebody describing a real job, clearly enough to build from, is the scarce part, and a gap nobody names stays a gap indefinitely.
Dubb Agent holds the library under skills in the left navigation, and requests come through the daily live sessions or a short form, both of which are easier than they sound and neither of which requires you to have worked out the solution first.
If you change one thing after reading this, audit your routines against the funnel. Fifteen minutes, and it usually finds the gap sitting closest to revenue.
