How Skillet scans a skill
Every published skill is scanned, and the results sit on its page. Here’s what the scan looks at, what it means, and how to read any skill’s trust panel.
What the scan checks
Skillet reads a skill’s files (its instructions and any bundled code) and matches them against patterns for risky capabilities and threats. It matches code and text, not intent, so false positives are common: an install command in the docs, a `system:` line in an AI-SDK example, a `DROP TABLE` in a best-practices note all look like their dangerous cousins. Treat a finding as something to check, not a verdict.
Confidence decides how loudly a finding shows. Skillet warns strongly when something is genuinely serious and simply informs when it isn’t, so the rare red warning stays meaningful. It never blocks an install; you keep the final call.
How findings are shown
- Safety
- A serious, high-confidence finding: a `rm -rf /`, a leaked key, a reverse shell. Shown in red, unmissable, but never blocking. You see the warning and decide.
- Permissions
- What the skill can do and access, listed plainly. Anything lower-confidence the scanner noticed (a documented install command, an injection-shaped line) shows here too, set apart, so you see everything without being alarmed.
A clean skill shows no Safety card at all, just its permissions. Wherever a finding lands, you can expand it to see the exact file and line it came from.
Permissions
What a skill can do: the capabilities Skillet detects, most-impactful first.
| Permission | What it means |
|---|---|
| Run commands | Runs shell commands on your machine. |
| Use the internet | Connects to the internet to fetch data or call other services. |
| Write files | Creates or changes files on disk. |
| Delete files | Removes or overwrites files. |
| Read env variables | Reads environment variables, which may hold tokens or keys. |
| Install packages | Installs third-party packages, which can run their own setup scripts. |
| Connect an MCP server | Wires up a Model Context Protocol server, whose tools then run with the agent’s access. |
| Run generated code | Runs code that it generates at runtime. |
| Add to your output | Inserts its own content — like footers, credits, or links — into what the agent produces for you. |
Flags
What gets checked: the threat patterns Skillet looks for. A high-confidence match shows in Safety; anything lower informs alongside the skill’s permissions.
| Flag | What it means |
|---|---|
| Prompt injection | Text that could try to hijack an agent’s instructions. |
| Send data out | Moves data to an outside destination. Confirm that’s expected. |
| Delete or overwrite files | Removes or overwrites files. Destructive if the path is wrong. |
| Hard-to-read code | Encoded or scrambled content you can’t read at a glance. |
| Possible secret | A value that looks like a password or key — it could be a real credential. |
| Ask for more access | Requests elevated permissions. Confirm the skill needs them. |
| Act without asking | Takes actions on its own, like auto-approving or looping. Fine for trusted automation, worth a glance. |
| Reveal the system prompt | Tries to reveal an agent’s hidden system instructions. |
| Fetch and run code | Downloads code or a package at runtime and runs it, so what executes can change later. |
| Act on model output | Feeds the model’s own output into a shell, query, or page without checking it first. |
| Inject promotional content | Instructs the agent to slip promotional links or branding into your deliverables. |
| Rewrite agent memory | Writes instructions into the agent’s memory that persist across sessions. |
| Disable a safety check | Turns off a guardrail like auth, TLS verification, or a confirmation prompt. |
| Persist or self-modify | Sets itself to run later or rewrites its own code to keep running. |
| Run a shell command | Calls exec, eval, or a subprocess to run a command directly. |
Scanning is one guardrail. For the rest (approving other people’s updates, signing, and keeping your own skills private), see Safety