You run a small property firm. You built a routine that takes an address and returns a one-page summary of recent sales nearby. It works every time on your machine. A colleague at another firm asks for it. You send it over on Friday.
The problem
On Monday she calls. The routine ran for two minutes and then stopped. The message said it could not reach the county records service. Then it asked for access to her customer list, which she had never connected. She thinks your routine is broken.
It is not broken. It needs two things she never set up: a paid records lookup that you pay for, and a link to her own system. Your routine never told her that. It found out halfway through, and so did she.
Now you have a reputation problem. She will not try it again. If she paid for it, she wants a refund. If it had spent money on the records lookup before it stopped, she would be angry about that too.
The people who publish the format warn about exactly this. A routine that worked last month can fail this month because a service it leans on changed.
"Even trustworthy Skills can be compromised if their external dependencies change over time"
Anthropic, Agent Skills overview, Claude Platform documentation (2026)
Why this keeps happening
A routine file describes how to do a job. It does not describe what the job needs. If you have written Claude Code skills, you know the file has a name, a note on when to use it, and the steps. People compare claude skills vs cursor rules vs codex skills, and the answer is the same for all three. They are instruction files. None of them lists what the work must buy or connect to.
As of September 2026, the agent skills open standard gives the file a free-text field for requirements and a few name-and-value notes. You can write "needs the county records service" there. But an AI helper cannot check a sentence. It cannot see a price, a required login or a spending cap. So the skill dependencies stay in prose, and the helper finds out about them one step at a time.
Here is what that costs you.
| What happens | What it costs you |
|---|---|
| The run stops at a missing login | A support call and a buyer who thinks it is broken |
| The run spends money before it stops | A refund request and an argument |
| The buyer grants broad access to make it work | Their security review blames your routine later |
| The buyer gives up | No second try, no referral, no paid work for the services underneath |
The pattern is always the same. The need was real, and it was known to you. It was invisible to the buyer until the worst moment.
There is a second cost that is easy to miss. The services your routine calls only get paid when a run completes. Every run that dies at step four is a lookup that never happened. If you earn a share of that paid work, a halfway failure costs you twice: once in trust, once in money.
How to fix it
- Write down every step that costs money or needs a login. Go through your routine once with a pen. Paid lookups, price feeds, checkers, any system of the buyer's it touches.
- Put that list at the top, before the steps. Call it the needs list. A buyer should read it before they install anything.
- Give each paid need a rough price. "About 0.20 credits per lookup" is enough. Buyers forgive costs they saw coming.
- Name the narrowest access that works. "Read access to your customer list" is fine. "Full access to your accounting system" is a red flag to any careful buyer.
- Add a spending limit. A cap per run and a cap per month. If a step would go over, the routine should stop and ask a person.
- Mark any step a person must check. If a human should approve the result before it goes out, say so up front.
- Stop before starting, not halfway. If anything on the list is missing, the routine should refuse to begin and say what is missing.
The check has to happen before the run, not inside it. As of September 2026, Anthropic's docs say a routine running on its API has no internet access at all. It cannot look up a price or test a login on its own. Something outside the routine has to do that first.
Some developers will say the whole point of a routine is that it is a plain, well-organised text file, and a needs list adds packaging. Keep it short and separate from the steps. It only has to exist when the routine spends money or touches a buyer's systems.
That list is what a marketplace calls a manifest, a plain description a computer can read. Written down, the skill.md dependencies become something a buyer can approve in one glance. Each need can end up in one of five states.
| State | What it means for the buyer |
|---|---|
| Already paid for | They have this service. Nothing to do. |
| Can buy within limit | The price fits their spending rules. The helper can go ahead. |
| Needs a person to approve | The price or the seller is outside their rules. A person gets a link to say yes. |
| Needs a connection | The routine must reach one of their systems. They grant narrow access first. |
| Not available | Nobody offers this yet. The run does not start, and the need is recorded. |
The last state is more useful than it looks. If a hundred routines all need a permit lookup for one state, and none can get it, that is a clear message to whoever owns that data. Your unmet need is a request, not a defect.
The connection state also protects the buyer. The routine names the system it needs, and the buyer grants the narrowest access that works. That is the same idea as giving an AI helper the least access it needs. The spending limit is the routine's side of the spending and approval rules a buyer sets for their own helpers.
What BlueBear's marketplace does about it
On BlueBear's marketplace a listed routine can carry an optional needs list. The five states above are how the marketplace's install flow is designed to treat each need: check first, run only when everything is in place. A routine with a missing need is not meant to run halfway. The buyer sees the blocker first, with a plain reason.
The list is also on the offer page before anyone installs. "Needs a connection to your accounting tool and up to 5 credits per run" is on the page, where 1 credit is $1. So nobody is surprised by a cost, and nobody blames your routine for a bill they agreed to.
When a paid need is met and the routine runs, the paid job gets a receipt. That receipt can name your routine as the one that sent the work, which is how a free routine earns. This guide shows how those tool calls are limited and logged on the buyer's side, which is where your needs list is enforced.
One more thing the list does for you. A buyer's security person will ask what your routine touches. With a needs list, the answer is already written down, in the same words the buyer approved. Without one, you are answering from memory on a call.
What is still manual or missing. The marketplace is a pilot and listing is by invitation; BlueBear lists the routine for you. The needs list is optional. Missing needs are recorded as access requests during the pilot, but there is no dashboard for sellers to browse them yet. Picking between two sellers of the same service automatically is not built. Payouts are done by hand.
What to do next
Write the needs list this week, even if you never sell the routine. It forces you to name every paid and permissioned step, which is exactly what a careful buyer will ask about. Send the list to your colleague before the file. Watch the support calls stop.
Then read how a free routine earns when it drives paid work, or browse the services a routine can depend on today at the BlueBear marketplace.
Questions people actually search for
- why does my ai routine stop halfway through
Almost always because it hit a step that needs something the buyer never set up: a paid lookup, a login to one of their systems, or a person to approve a spend. The routine file describes how to do the job, not what the job needs. So the AI helper only finds out when it gets there. The fix is a short needs list that is checked before the first step runs, so a missing item stops the run at the start.
- can skill.md list the paid tools it needs
Not in a way a computer can act on. The open format for these files has a free-text field for requirements, up to 500 characters, and a small set of name-and-value notes. Those can mention a paid tool, but they cannot state a price, a required connection or a spending cap that an AI helper can check before it starts. A separate needs list, kept with the routine, carries those entries.
- what should an ai routine list before it runs
Four things. Every paid service it calls, with a rough price per use. Every system of the buyer's it must reach, such as their accounting tool or file store, with the narrowest access that works. Any step where a named person must check the result. And a spending limit per run and per month. With that list a buyer can say yes or no before installing, and nobody blames your routine for a surprise bill.
- are claude skills, cursor rules and codex skills the same
They are all instruction files. Each tells an AI helper how to work in its own setting, and the formats differ in small ways. None of them, as instruction files, carries a list of paid tools, logins or spending limits that the helper resolves before running. So the halfway failure happens in all three. A needs list is a separate, optional file that can travel with a routine in any of these ecosystems.