Verifier & security

Every version runs through the same verifier — in the registry's worker on import and again in the CLI on your machine before installation. The result is a report with checks (pass / warn / fail) and findings (security issues with file, line, excerpt and reason).

Badge levels#

The CLI installs verified packages directly. For Warning and Failed packages it prints the findings and asks first. Moderators can approve a version manually (status Verified, marked as reviewed) or block it — see Moderation.

Structure checks#

Per package type, the verifier checks:

• Files — at least one file, valid relative paths, the limits below.
• Skills — SKILL.md exists, has YAML frontmatter with a valid name (lowercase, digits, hyphens) and a description of 20–1024 characters. Very long skills (> 500 lines) get a warning.
• Cursor rules — at least one .mdc with frontmatter (description, globs or alwaysApply) and a body.
• AGENTS.md — an AGENTS.md (or one markdown file) with content.
• Subagents — markdown files with name and description.
• Slash commands — markdown files with usable command names.
• References — every relative link or image points to a file in the package (fail); backticked paths that do not exist give a warning.

Compatibility checks#

For every tool the package declares, the verifier checks that the package type can be installed for that tool and that the files have the required format (for example, Cursor needs a skill that can be converted to .mdc). Declaring a tool the package does not support fails the check.

Security rules#

The scanner has 25 rules: pattern rules that run line by line over every text file, and file-level checks for binaries, bundled scripts and unknown links. Each finding records the rule id, the file and line, the excerpt, the rule severity, the effective severity after context, the context and the reason. Click a rule id to link to it.

Links to hosts that are not on the list of well-known documentation domains are reported as unknown-url (informational only). Well-known domains:

github.com · githubusercontent.com · gitlab.com · anthropic.com · claude.ai · claude.com · openai.com · cursor.com · cursor.sh · denofy.com · agentskills.io · modelcontextprotocol.io · npmjs.com · npmjs.org · pypi.org · python.org · nodejs.org · typescriptlang.org · developer.mozilla.org · mozilla.org · wikipedia.org · stackoverflow.com · react.dev · nextjs.org · tailwindcss.com · vercel.com · git-scm.com · semver.org · json-schema.org · w3.org · schema.org · opensource.org · creativecommons.org · gnu.org · apache.org · shields.io · conventionalcommits.org · keepachangelog.com · docker.com · postgresql.org · example.com · example.org · localhost

Context rules#

The same text means different things depending on where it is. curl … | bash in scripts/install.sh runs on the user's machine; the same text in a list titled "Never do this" is advice. The verifier therefore determines a context for every match:

Details:

• Conditions ("If it is not installed, run …") and phrases like "Don't forget to run …" are not negations.
• Every occurrence on a line is evaluated; the most severe one wins.
• Hidden Unicode, Unicode tag characters, obfuscation, Base64 blobs and hidden HTML comments are always checked at full severity — there is no harmless context for them.
• Prompt-injection phrases are only lowered by a negation, not by being in prose: instructions in prose are exactly what an agent reads.
• Binaries cannot be reviewed and always count at full severity.

Diff to the previous version#

Every report is compared with the previous version of the package:

• added, removed and changed files
• new findings (by fingerprint) — highlighted in the report and the CLI
• resolved findings
• whether the risk level increased (diff.new-risks, a warning)

A package that was Verified and suddenly gets new high-risk findings therefore cannot silently keep its badge.

Reading a report#

On a package page open Verification and pick a version. Each finding shows:

• severity and the original rule severity if context lowered it
• context and reason ("Lowered: found in prose", "Allowed by author: …")
• file, line and the excerpt with invisible characters made visible (<U+200B>)
• NEW if it did not exist in the previous version

The same report is available as JSON from the API.

False positives#

If a finding is wrong:

1. Rephrase — mark negative examples ("❌ Don't:"), put explanations in prose rather than in runnable code blocks, use text blocks for output.
2. Allow it with a reason in denofy.yml — the package then shows Warning with your reason instead of Failed.
3. Report it — use Report → Security problem on the package page and describe the false positive, or open an issue on GitHub. Moderators can approve a version manually; rule fixes are applied to all packages with a re-verification.