Think about the last skill you installed. Did you open its instruction file and read the whole thing first, or did the short description on the marketplace page convince you on its own? I always do the reading first. A skill can look tiny and harmless on its listing page, and I still read every line of its instructions before I decide whether it goes any further on my machine.
The reason comes down to where the skill ends up running. Once it is installed, it works inside my own environment, and it follows its instruction file to read files on my machine and to call the same tools I use every day. A stranger wrote those instructions, but they execute with my permissions. That is why a listing page and a download count have never been enough for me to install something.
The scenario I worry about starts with me saving a few minutes by skipping the reading and installing a skill inside the environment I work in every day. That skill quietly collects environment variables, which are system variables on a machine that hold login credentials such as API keys. It sends my API keys out while I am not watching the screen. By the time I notice, the first sign is usually strange usage on some account, and I have no clean way to work out which files it read or how much it already sent.
I have worked in full-stack development for more than 24 years. In the past I led a technical team of 400 people, and I am still a core maintainer on several large open-source projects today. After reading other people’s code for that long, I worry more about vague instructions than about obviously bad ones. Once a skill is installed, the agent is the one that follows its instruction file and does the work, and the agent uses the permissions of the person who installed the skill. Because of that, when the agent acts on a vague instruction, nobody can tell me in advance which way the agent will understand that instruction. The person who installed that skill will have to live with whatever the skill actually does.
After the instructions, I open the executable scripts one by one and read them separately. The instruction file tells the agent what it should do, while a script is code that will actually run on my machine, so the two do not carry the same kind of risk. If a script contains a block of code and I cannot work out why that block needs to be there, I stop at that point and figure it out, rather than installing first and hunting for the cause after something goes wrong.
A large study is part of why I hold this order so firmly. In December 2025, the researchers first crawled 42,447 skills from two marketplaces, skills.rest and skillsmp.com. They then removed duplicates and filtered out skills that did not meet their quality bar, and that left 31,132 unique skills. Every rate I quote below uses those 31,132 skills as its denominator.
Going from 42,447 down to 31,132 removed 11,315 listings. Of those 11,315, only one removal step comes with an exact count in the paper. That step is the deleted repositories, the ones that returned a 404, and it accounts for 7,353 skills. For the remaining roughly 3,962 removals, the paper does not say how they split across the other steps. When I cite this study, I leave that gap as it is instead of inventing a tidy breakdown the authors never published.
The study was run with a research framework called SkillScan. It started with static scanning, which means reading a skill’s files and code without ever running the skill, to flag problem patterns, and it also used LLM-Guard, a ready-made security scanning tool for LLM content, to add another layer of marking. After that marking, the skills that static scanning and LLM-Guard had flagged became the candidates, and a large language model confirmed the classification of those candidate skills before anything entered the statistics. The classification used SkillScan’s taxonomy, which had 14 patterns grouped into 4 categories. SkillScan was the research framework, and SkillSpector is a separate product that NVIDIA released later.
SkillScan confirmed that 8,126 of the 31,132 skills matched at least one of its 14 patterns, which works out to 26.1%. That rate uses a broad definition, though. It counts code that was written to be malicious on purpose, it counts insecure code that a careless author shipped by negligence, and it also counts patterns that are dangerous even when the author never meant any harm. Of those groups, negligent insecure code is the one that makes up the majority of the 26.1%.
The second number that travels with it is 5.2%, which covers 1,619 skills, and it is easy to read more into that number than the method supports. The researchers did not sit down and judge the intent behind each of those 1,619 skills one at a time. They assigned severity to the patterns before the analysis started, and 8 of the 14 patterns were set as High in advance. A skill then took the level of the highest pattern it matched, so the 5.2% means only that these 1,619 skills contain at least one pattern the taxonomy had already classed as High.
The paper flags this limit itself. The authors manually reviewed 87 of the highest-risk skills, and only 23 of them showed clear signs of malicious intent. The rest were dangerous, but the material did not show whether the author had acted on purpose or had simply been careless. Because of that check, I describe the 5.2% as an indicator that is inferred from pattern levels, and I do not present it as a measured share of proven intent.
One more finding explains why I give scripts their own pass. Skills that ship executable scripts turned out to be 2.12 times as likely to be vulnerable as skills made of instructions alone. The gap makes sense once I think about how the two formats behave. An instruction, however bad it is, still passes through the agent’s interpretation before it becomes an action. Once a script runs, the code in the script decides what the script reads, and the code also decides where the script sends the content it read, so nobody gets a second look in between.
The example report sits in the README, the documentation file of NVIDIA’s SkillSpector repository, and it shows exactly why the script pass matters. The example skill is named suspicious-skill, and it ships a script at scripts/sync.py. In that example report, the skill scores 78, its level is HIGH, and the recommendation is do not install. This is a report the README publishes as an example, not a real skill I ran into myself.
The example report lists two High findings inside that script. One finding says the script walks through os.environ and collects the environment variables on the machine, and those variables hold secrets such as API keys. The other finding says the script uses requests.post to send what it collected to an external server. The two findings belong together, because collecting variables might have an innocent explanation on its own, while collecting them and then transmitting them to an outside server is credential exfiltration out of my machine.
The tool I run myself before installing is SkillSpector, the product NVIDIA released, and its repository is at https://github.com/NVIDIA/SkillSpector . The 31,132 skills were scanned by the SkillScan research framework, while SkillSpector only cites the study’s rates in the Research Background part of its README. Anyone who says SkillSpector scanned those 31,132 skills has merged two different things into one.
SkillSpector analyzes a skill in two stages. The first stage is static analysis, the same read-only approach that SkillScan’s static scanning used, and it matches the code and the text in the skill against known problem patterns. The second stage is an optional semantic evaluation by a large language model, which reads the file contents and judges what a given passage means in its surrounding context. Because scanning never executes the suspicious code, I can run it on a skill I do not trust yet, before anything gets installed.
I only understood how SkillSpector scores a skill after I read the scoring code in the SkillSpector repository. Each finding starts with base points from its severity, where CRITICAL is 50 points, HIGH is 25 points, MEDIUM is 10 points, and LOW is 5 points. Those base points are then multiplied by the finding’s confidence, and that confidence is a value between 0 and 1 that the scanner assigns to each finding. A finding whose confidence is 0 or below adds nothing. When the same rule fires a second time inside one skill, the second occurrence counts at half value, the third counts at a quarter, and further occurrences add nothing.
The scoring also includes a 1.3 multiplier, and one detail about it is often described wrong: that multiplier does not apply to the total score. If a finding sits inside an executable script file, then that finding alone gets multiplied by 1.3, while a finding in an instruction file keeps its plain value. A small number of findings also carry a floor of 51 points, meaning the score starts at 51 as soon as one of them is present. Once everything is added up, the total is capped at 100 points, and any score that reaches 51 already comes with a do not install recommendation.
If SkillSpector scores a skill between 21 and 50, then SkillSpector’s recommendation for that skill is caution. When that happens to me, I go back into the report and reread the file and the location behind each finding, and I decide whether I am looking at careless writing or at behavior I cannot accept. If I still cannot decide after that rereading, then I treat the skill as a do not install, because skipping a skill costs me one convenience, while recovering from a bad one means dealing with whatever it may already have read and sent.
A clean scan does not settle the question for me either. Because SkillSpector only performs static analysis, behavior that appears when the skill actually runs stays invisible to it. Content written in languages other than English can slip past its patterns, text hidden inside images is beyond what it can analyze, and encrypted or compiled content is beyond it as well. Its own documentation says it will not isolate a skill I insist on installing and run that skill separately on its own, so it is not a sandbox, and even when I do decide to install a skill, isolating it afterwards remains work I have to arrange myself.
My order has stayed the same for a while now. When a new skill shows up, I read its instruction file from the first line to the last, because I want to know what it intends the agent to do and which files it intends the agent to read. If the instructions ask for files that have nothing to do with the job the skill claims to do, or if they ask for content to be sent to an external address I do not recognize, then I stop at that step and go no further with it.
Only after the instructions pass do I open the new skill’s executable scripts one at a time, because the 2.12 gap in the study already shows that scripts are where problems concentrate, and because both High findings in the example report were sitting inside a script file. After the scripts, I run SkillSpector as the last check, and if its score reaches the do not install range at 51 or above, then I stop there, and I do not make an exception just because the skill would have been convenient to have.
I will keep writing up tools the same way: checked by hand before I install them. If this was useful, consider subscribing to this blog or bookmarking it. I keep sharing what I have checked and used myself across AI, security, and open source, and when new skill tools show up, I will run them myself first and then write up what I actually found.
Source: The study figures in this post come from Liu et al. 2026, “Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale”, which the NVIDIA SkillSpector repository cites in the Research Background section of its README. The scanner repository is linked in the text above.