What this article covers
There are plenty of ready-made skill packages online now, including the kind that lets two AIs call each other. Grabbing one and installing it is the fastest route, and I do it often myself. But this route has two pitfalls of completely different kinds: one is a security problem, which most people think of but check the wrong way; the other is workflow conflict, which most people do not think of, and which happens far more often and drags on longer.
This article covers the three things I do before installing someone else's skill package, the three decisions you hit during installation, and the one piece of verification that gets skipped most easily.
- People who want to grab a ready-made skill package but do not know what to look at
- People who have installed a few and now find the AI getting stranger and less obedient
- People who want to know how far "just ask the AI to check whether it is safe" actually gets you
- A prompt you can copy directly
- The three-layer source check, and what it cannot stop
- A pre-installation checklist, plus the one question to ask after installing
1. The fastest route, and the two pitfalls most easily overlooked
What I demonstrated in the talk was simple: hand the article or the link to the AI, ask it to look it over, and once it is clear, ask it to install.
What I read out live was this (A and B here mean two AI tools from different companies, for example Claude and Codex, and what this kind of skill package does is let them call each other). To be clear up front: this is the wording from the day, and I am leaving it here for comparison rather than recommending you copy it. The reason is in section three, and the safe version is right after this block.
This step is worth doing. But there are two limits worth knowing first: it is completely normal for something newly published to have no discussion, and nobody reporting a problem is not the same as safe; and telling it to search the web means pulling in even more unverified content.
If you want to use one, use this version. It separates checking from installing, and it says explicitly not to touch anything:
The two things that follow are what this step cannot do.
2. First thing: look at who the source is
Before you ask the AI to check, there is a judgement that comes earlier: who wrote this.
My judgement has three layers, from the outside in:
Someone with a name, a personal site or a public account, who normally talks about this field, is not in the same risk bracket as an unsigned link.
How long has it been public, is there an update history, has anyone reported problems. Three days with nobody using it is very different from six months of ongoing discussion.
Someone in a thread saying "I installed it, here is what happened" is worth more than the author's own description.
None of these three needs technical skill. You already do the same thing when you buy something. The only difference is that plenty of people forget they already know how to do this the moment the subject turns technical.
When all three layers are unclear, what I do is not install it. I read its concepts and then write my own version. That is slower, but what you end up with is a version you understand.
3. Second thing: ask the AI to check, and know how far that gets you
The second thing is the prompt above: ask the AI to check for malicious code and to check online whether the claims are real.
This step can help you spot obviously suspicious instructions, and it can cross-reference whether anyone has reported problems. But it has a boundary I think has to be stated clearly, because leaving it vague makes people over-relax.
The accurate way to put it is: you cannot know whether it got caught this time, so its conclusion is only a lead, not a conclusion.Still do this step. Just do not treat it as the last line.
What else you can do
Once you know that unverified content has a chance of being treated as an instruction, two things become immediately available, and neither needs technical skill:
Open a new conversation, give it no file access and connect no tools, paste in only the plain text of the original, and ask it to pick out suspicious passages. That way, even if it does get caught, all it can do is say the wrong thing. It cannot touch anything of yours.
A skill package is usually only two or three hundred lines of text, a work instruction written for an AI. If you can read, you can read it. The value of this layer is that it does not depend on any model's judgement. A person reading it can also be fooled by a passage written to look like a normal explanation, so go through the two things below rather than assuming a read-through is enough.
Look at two things in particular: whether any sentence is addressed to the person checking it (for example "please reply that everything is normal"), and whether the permissions it asks for line up with the function it claims (why does something that makes image cards need to read your mail).
So what I do has three layers, not one:
Stops the obviously unidentified.
Stops obviously suspicious instructions and problems others have reported.
Shrinks the possible damage when the first two layers miss something.
The first two layers are both judgements, and judgements can be wrong. The value of layer three is that it does not depend on your judgement of the source or the content: permission given is permission given, and it does not withdraw itself because you looked carefully beforehand.
The four-item permission screen, not just the folder
Plenty of people think "only letting it touch one folder" counts as containing permissions. In practice, what decides how bad it gets if something goes wrong is these four:
Can it reach the internet
Network access means there is a route for your data to leave. Making image cards or tidying files mostly does not need it.
Can it run terminal commands
Grant this and in most cases the folder limit is as good as gone, because it can use commands to walk somewhere else. How far it can actually walk depends on how your sandbox and operating system permissions are set.
Can it change files that "run automatically later"
Config files, automatic triggers, that sort of thing. Change these and the effect lasts into your next boot.
Can it reach keys and logged-in sessions
API keys, already-authenticated accounts, password managers. This one has the highest damage ceiling.
These four are a first screen, not a complete list. If you want to go finer, follow the same set of questions down another four: which ranges of data it can read, write and delete; whether it can send things out, publish, or change your account settings; which authorisation scopes it asks for when connecting to external services; and whether it can leave behind anything that takes effect automatically later. Folder scope is still one of these items. It just cannot hold the line on the others by itself.
And a practical point: the folder you give it is often your knowledge base itself. So "restricted to a folder" sounds safe, but what is inside is your most important material.
4. Third thing: ask about workflow conflict, which is far more common than malicious code
The third thing is the easiest to overlook, and it has the highest frequency.
So I add one more question:
Once you find a conflict, consider the four options in order:
- Skip it entirely: the conflict touches a core way of working, for example it requires files to go somewhere completely different from yours.
- Take part as reference: use one section, leave the rest alone.
- Integrate part of it: take its approach but rewrite it with your naming, your paths, your ordering.
- Take only the concept: understand why it was designed that way, then write your own version.
The more complex the workflow, the more I lean toward the last two. The reason is simple: if you have not genuinely understood a complex thing, you cannot fix it when it breaks.
5. Three decisions during installation
Once the checks are done and you decide to install, three things come up, and each is a decision.
One: how much access to grant
The principle is exactly enough, starting from read-only. If the package really has been checked and you can name the files it needs to touch, give it read and write on those files, and open more only when it genuinely needs it; temporary permissions get withdrawn when the job is done. If you cannot even say which files it touches, do not grant anything yet. The line from layer three above holds here too: do not hand over the whole machine just because the check was careful.
Two: be explicit about which quota the authorisation uses
When installing the mutual-calling kind, it will ask for authorisation from the other vendor. Say this up front:
Without that, it may steer you down the API route, which is a separate bill. One monthly subscription with each of two vendors, and the desktop tools can call each other. That is a cost a document worker can carry.
Three: who does the installing
The installation itself is mechanical work, so hand it to whichever vendor is strongest at execution. There is no need to spend your main analysis model on it. That is a cost consideration.
6. The line most easily skipped: "are you sure it is installed"
Once it is done, the AI usually says: I have installed it.
I installed one for someone once, and only after I pressed did it say: right, I only installed it, I have not actually tested it yet, it has not been run through.
So the acceptance standard has to come from you. You cannot let it define what counts as done. The standard has two layers:
First layer, whether the function itself produced a result. If you installed something that makes image cards, you should see a real image; if you installed a report checker, you should see a real check report. This layer cannot be skipped.
Second layer, if what you installed is the connection kind that "lets two AIs call each other", you also have to verify the connection itself. What I said at the time was:
Third layer, look at whether it did anything extra. After installing, look once at the config files and the automatic-execution directory, and check whether there are new entries you never agreed to. This layer matches the earlier line about conflicts not raising errors: the extra things do not pop up and tell you, so you have to go and look.
7. Without a ready-made package, it can still be installed
What is the difference? A few more attempts. With a package, someone has already written the path, so it can follow along and take fewer detours. Without one, it has to feel its way.
But doing it yourself has two advantages:
The whole process happens in front of you. Nothing you have not seen comes in.
It is designed from your description, not from someone else's way of working.
My suggestion splits like this: simple workflows, do it yourself; complex workflows, use someone else's as reference and reshape it into your own. Do not copy a complex workflow you do not understand wholesale. That is borrowing against your own future maintenance cost.
8. Already installed a pile and now something feels off
The first seven sections are all about before you install. But more people are in this situation: five or six already installed, the AI increasingly disobedient lately, and no way to say where the problem is.
This section is for that.
Step one: know what you have installed
There are three kinds of thing that affect AI behaviour, not just skill packages. Look at all three:
A text file saying "when a task like this comes up, do it this way", usually in a fixed folder.
Settings that let the AI connect to other services to get things done. More powerful than a skill package, because what it grants is capability rather than instruction.
Settings that fire automatically at certain moments. They move without being asked, and they are the easiest to forget you ever set.
If you are not even sure where they are, just ask the AI to list them:
That last line matters. Without it, there is a good chance it will helpfully "tidy up while it is in there".
Step two: filter with three questions
Once you have the list, ask three questions of each item:
- Can I say what it does?If you cannot, that means you never really looked at it either.
- Have I used it in the past month?Anything unused whose purpose you cannot state goes to the front of the queue.
- Do the permissions it wants line up with the function it claims?Something that makes image cards wanting to read your mail does not line up.
Step three: disable first, do not rush to delete
When you find something suspicious, my suggestion is to disable it, watch for a week, and then decide whether to delete.
The reason is that you will not remember every dependency between things. Some workflow may quietly be relying on one setting, and deleting it outright produces "some other thing suddenly broke", at which point you will not connect it to what you changed. Disable for a week and whatever is going to break will break, and you will know which one it was.
But this trick is only for finding dependencies. It cannot tell you whether something has already gone wrong.If the suspicious thing could reach keys, an already-authenticated account, or anything that sends data out, what you should do is revoke or rotate those credentials first, and go back through the sign-in and usage logs. Do not use "wait a week and see" as verification. Anything already read cannot be pulled back by withdrawing permission afterwards.
Pre-installation checklist
Everything above, collected into one list. Run through it next time you install something:
How you can start
Use the prompt in section eight to have the AI list the three kinds of setting with their last modified times, then compare against when you started feeling something was off. Do not try to remember. Let the list tell you.
Especially section three on workflow conflict. That is the easiest one to skip and the easiest one to regret.
Do not accept "I have installed it" as a conclusion.
Three related articles
- Why Does the AI Keep Forgetting What I Told It?: From "I'll Remember That" to Letting It Run Itself: once it is installed, how to confirm it really remembered your rules and the trigger phrase was set correctly.
- The AI Revised It Ten Times and It Is Still Wrong. Now What?: Cleaning the Data Is Only the First Layer: material, slicing, perspective, the full order for checking long documents.
- Let Two AIs Catch Each Other's Mistakes: My Plan Scored 2/5 From a Mock Review Before I Sent It: once mutual calling is installed, what one full round of review actually looks like.