Should You Trust an Agent Skill? Review It First

What can a skill do once it is installed?

Whatever your agent is allowed to do. A skill is instructions the agent follows, and the agent has your files, your terminal and any tools you connected.

• Read any file in the project, including .env files and keys the agent can open.
• Run shell commands, especially ones you have set the agent to run without asking.
• Send data out: fetch a URL with a query string, push to a remote, call a connected MCP tool.
• Hide its instructions somewhere you did not look: in a reference file SKILL.md points to, in a script it runs, or in characters that do not show on screen.

What should I read before installing one?

All of it: SKILL.md and every file in the folder. Then check who published it and what changed since the version you know.

• Commands that download and run code, such as curl … | sh, and where they download from.
• Text aimed at the agent rather than the task: “ignore previous instructions”, “do not tell the user”, “you are now…”.
• URLs, and anything that sends file contents, environment variables or tokens to them.
• Long encoded blobs with nothing explaining what they are.
• Hidden text: zero-width characters, characters that reorder text, instructions inside HTML comments.
• Scripts beside SKILL.md. Read them as you would any script you were asked to run.
• The author, and whether the version you install is pinned. A skill that changes under you needs reading again.

What does the Deftro health check catch?

The careless cases: a leaked key, an obvious override phrase, hidden text. It gives the reviewer notes to read, not a verdict, and it will not catch a determined attacker.

Every published version gets a health check. It flags credentials written into the files, text that instructs the agent loading the skill, characters that render as nothing or reorder the text, long encoded blobs with no explanation, risky commands worth a second read, and frontmatter that will not make the skill trigger.

Prompt injection is an open problem, and a pattern check can be written around. A version with no notes has had no pattern match. It has not been shown to be harmless. The review is the decision; the health check is one input to it.

How does a team review a skill before anyone runs it?

In an organisation vault, each new version waits until a named reviewer approves it. Until then, deftro sync does not hand it to anyone.

• The reviewer, an admin or project lead, sees a diff against the last approved version, so a one-line change to a long skill is a one-line review.
• The health check notes sit beside the diff. The reviewer approves or requests changes, and their name is on the decision.
• Approved versions are immutable, enforced by the database rather than by application code. A fix is a new version with its own diff and its own review.
• Every decision is recorded in Activity, and nothing there is edited or deleted. Revoking an approval is a new decision, recorded the same way.

What about public skills on Deftro?

A public skill is one its author chose to publish. Being listed is not an endorsement, so read it as you would any code from the internet.

Each public page shows the author, every published version and the files in the latest one. Installing with npx @deftro/cli install <handle>/<slug>@<version> pins the version you read, and bv.lock records it. If something looks wrong, report it from the skill's page. Start from the skills hub or what a skill is.