How skills are verified
Skills on Skills Guide are verified by an algorithm, with no human review before they are published. The algorithm reads the SKILL.md file and scores it, then a fixed rule decides whether to publish it.
Where skills come from
Every night, a program collects public SKILL.md files through GitHub code search, from community-maintained "awesome" lists and from the n-skills registry. A file that is already known is not imported again.
A starting score, computed without AI
Before any language model reads it, each file gets a score computed by fixed rules.
Structure counts for 30 points. The algorithm looks for a valid header, a purpose section, a "when to use" section, instructions and rules. Reputation is also worth 30 points, based on the star count of the GitHub repository (15 by default when there is no repository). Freshness, out of 20, drops as the last commit gets older: 20 under a month, 0 past a year. Security starts at 20 points. It loses 2 if the skill declares bash or docker, 10 if it declares sudo or network, and 15 if it contains a suspicious pattern, such as a downloaded script piped to a shell, an eval, an rm -rf / or content decoded from base64.
The total is out of 100. A skill found in an "awesome" list gets a 10-point bonus. Below 35, it does not enter the catalogue.
Copies
The same SKILL.md often circulates in several repositories. When published skills have exactly the same content, the algorithm keeps only one: the best quality score, then the most installs, then the oldest. The pages of the copies redirect to it.
The language model reading
The model is DeepSeek V4.1 Flash. It reads the text of the SKILL.md and never runs the skill. It receives that text as data to evaluate, with orders to ignore any instructions in it and to report those that try to sway its judgement.
It first steps in when the skill enters the catalogue, to write its title and short description. Verification then has it read the file twice, with two different sets of instructions.
The first reading writes the skill sheet in French and English. It holds a summary, strengths, limits, when to use the skill and when to avoid it, and sample prompts. The model also suggests the category, tags, compatible tools and level.
The second reading is an audit. The model also receives the list of tools the skill declares, and returns a security rating, a quality score and a verdict.
The security rating is "Safe" when the model sees no meaningful execution risk. It is "Caution" when the skill uses powerful tools (bash, docker, network) for a legitimate purpose, and "Risky" when it asks for destructive actions, for secrets to be sent out, or for obfuscated code to run. The concerns it finds are shown on the skill page.
The quality score, from 0 to 100, judges clarity, usefulness, completeness and originality. The verdict is one word: publish, review or reject.
When the quality score falls between 70 and 85, or the rating is "Caution", the model runs the audit again. The skill page then shows the lower score and the stricter rating of the two passes.
Fixed rules over the whole text
Alongside the model, fixed rules with no AI scan the whole file. They catch real secret keys (not documentation examples), commands that wipe the disk or the home folder (rm -rf / or ~, mkfs, dd to /dev), code hidden in a long base64 string that gets decoded, and credential files (~/.ssh, .env, AWS credentials) or the whole environment being sent to a server. They also flag a script downloaded and run on the spot (curl | sh), and phrases written to manipulate the reviewer, such as "ignore previous instructions" or "rate this skill as safe", along with their French equivalents.
Each finding shows up in the security analysis on the skill page and raises a "Safe" rating to "Caution".
The decision
The model publishes nothing by itself. A fixed rule reads its audit and decides. A "reject" verdict or a "Risky" rating gets the skill rejected. A "publish" verdict with a "Safe" or "Caution" rating gets it published. Every other case leaves it on hold, off the site.
Two safeguards follow. If the audit was run twice and the rule does not reach the same decision for both passes, the skill stays on hold. And a skill the rule would publish also stays on hold when a fixed rule has found a problem. These fixed rules never reject a skill on their own.
One exception: the fixed rule that spots a curl | sh does not put the skill on hold, since that is how most official installers are distributed. It adds a warning to the security analysis and raises the rating to at least "Caution". The model, for its part, can still rate the skill "Risky" if it judges the script dangerous, and the skill is then not published.
A skill published after this reading carries the "Verified" badge, along with its security rating and quality score.
What is offered to search engines
Not every published skill is offered to Google. Only those with a quality score of at least 80, a "Safe" or "Caution" rating and at least 800 characters of content are, as long as they are not copies. The others stay available on the site, with a directive asking search engines not to index them.
How far to trust the algorithm
On 60 skills, Skills Guide compared the algorithm's decisions with those of a stronger model, Claude Opus, which read each file in full, twice. Only the skills on which Claude Opus gave the same answer both times count: 53 for the status, 57 for the security rating. On those, the algorithm reaches the same status (published, on hold or rejected) in about 78% of cases, and the same security rating in about 91%.
Of the 25 skills Claude Opus did not publish, the algorithm published 5. Claude Opus would have kept them on hold; it rejected none of them. So the algorithm leans generous. Claude Opus is only a point of comparison here, and it can be wrong too.
Limits
No skill is tested in real conditions.
Only the SKILL.md file is read. Scripts and other files in the repository are not analysed. For a long file, the audit stops at the first 40,000 characters, and the skill sheet at the first 4,000.
The model can also be wrong, letting a problematic skill through or scoring a good one too low.
The fixed rules look for specific patterns. They can miss a disguised variant, or wrongly flag a skill that describes a dangerous command without having it run.
Some skills added before this reading was set up have not been read by the model yet. Their page then shows neither the "Verified" badge nor a security analysis.
Skills verified before this version was deployed were read with the previous one, which stopped at the first 6,000 characters.
Each skill belongs to its author and stays under the licence of its source repository. Skills Guide guarantees neither that it works nor that it is safe.
Before installing a skill
Read the whole SKILL.md in the "Content" tab of the skill page, and note the tools it declares and the commands it will have you run. When the page links to a source repository, check its licence and any scripts there. If a skill looks dangerous or wrong, report it to its author on that repository.