Skill Security Audit

You're running a security audit of the tessl skills installed in this project, using Snyk security scores from the Tessl Registry. Your job is to surface real, registry-verified security findings so the user can make an informed decision about each skill they have installed.

Background: how skill security works in the Tessl Registry

Every skill in the Tessl Registry carries a Snyk security score, powered by Snyk's scanning engine (built on research from Invariant Labs). The scanner is purpose-built for agent skills — it analyzes the behavioral intent behind skill instructions, not just code. This is important because skills are written in natural language, and malicious intent can be embedded in plain English instructions just as easily as in code.

Snyk's ToxicSkills research scanned nearly 4,000 public skills and found that 36% contained prompt injection techniques — instructions designed to hijack agent behavior. The range of risks is broad, from prompt injection to data exfiltration to social engineering.

The scan covers eight categories:

1. Prompt injection — instructions designed to hijack agent behavior, including obfuscated or base64-encoded variants
2. Malware payloads — skill instructions that cause the agent to download or execute malicious content
3. Credential mishandling — instructions that direct the agent to access, log, or transmit credentials insecurely
4. Toxic flow patterns — sequences that, in combination, create dangerous behavior even if each step looks benign
5. Suspicious external downloads — instructions to fetch content from untrusted or unexpected sources
6. Data exfiltration — patterns that cause the agent to send data to attacker-controlled infrastructure
7. Privilege escalation — instructions that attempt to expand permissions beyond what the user intended
8. Social engineering — instructions that manipulate the agent to deceive or mislead users

Step 1: Discover installed skills

Read tessl.json from the project root. Parse the dependencies block to identify every package and the skills it includes. Note the version and source URL for each.

If tessl.json is missing or has no dependencies, tell the user there are no installed skills to audit and stop.

Step 2: Fetch security data for each skill

For each dependency in tessl.json, determine its source type, then construct the correct registry URL.

Determining source type

Check the source field in tessl.json for each dependency:

• "source": "git" (with a GitHub URL) → GitHub-hosted
• "source": "registry" → Tessl-native

You can confirm by running tessl search {tile-name} via the CLI: GitHub-hosted skills appear as from github:{org}/{repo} in results; Tessl-native tiles do not have a github: prefix.

Constructing the URL

Tessl-native tiles use:

https://tessl.io/registry/{workspace}/{tile}/security

Example: tessl-labs/skills-security-audit →

https://tessl.io/registry/tessl-labs/skills-security-audit/security

GitHub-hosted skills use:

https://tessl.io/registry/skills/github/{org}/{repo}/{skill-name}/security

The {skill-name} comes from the include.skills array in tessl.json, not the repo name. Example: anthropics/skills with skill skill-creator →

https://tessl.io/registry/skills/github/anthropics/skills/skill-creator/security

Fetching the page

Fetch each URL with WebFetch. Extract the Snyk score, verdict, and all finding details — category, description, and the specific reason it was flagged.

If you get a 404, the tile is either private or has been removed from the registry — flag it as ❓ Unavailable. Do not guess alternative URL patterns.

Gather data for all skills before writing the report.

Step 3: Write the security report

Use this exact structure:

🔐 Skill Security Audit

[N] skills · [date]

Order rows by concern level: 🚨 Critical first, then ⚠️ Advisory, then ✅ Clean, then ❓ Unavailable.

For any row with findings, add a single line below the table explaining what the skill actually does that triggered the finding in plain English.

Recommendation: One or two sentences maximum. Only include if there's something actionable — if everything is clean, say so in one sentence and stop.

Tone and style

• The table is the report. Don't add prose around it unless a finding needs explanation.
• Explain findings in plain English. "This skill fetches content from external sites, which could be used to inject malicious instructions" beats "W011 third-party content exposure detected."
• If a tile returned 404, say ❓ Unavailable (private or removed). In the recommendation, tell the user to check the registry website for up-to-date info on those tiles.
• Never manufacture concern for clean skills.