Why I Built SkillTrust

SkillTrust started with a skill I almost installed.

I was looking for a skill to help my coding agent with a routine task. I don’t remember the exact task anymore, but I remember how I found a directory with thousands of skills, chose one, briefly read the description, and opened the installation instructions.

I switched to my terminal and was about to run the command. Then I stopped.

What was I actually about to install? Was it safe? And how could it harm my computer?

The moment I hesitated

I hadn’t found anything malicious. I hadn’t even reviewed the skill closely enough to know whether there was a problem. That was what bothered me: I was about to use something I didn’t yet understand.

When you add a new third-party dependency to your project, you should review its source code and understand what it does. GitHub stars aren’t a measure of safety, and popularity isn’t a guarantee either. You should always review the code yourself to understand what it does. So why do we blindly trust skills written by someone else and listed in a marketplace?

Depending on its tools and permissions, a coding agent can read files, run commands, and interact with other systems. I started thinking about what could happen if the instructions I gave it were unsafe. Could they lead it to expose private data or secrets? Delete files? Do something I never intended?

I wondered whether the directory had already checked for those risks. I couldn’t tell what checks had been performed or how much confidence I should place in them.

I could have read through the skill myself and tried to understand everything it did, as I usually do with dependencies. But that takes time, especially when there are scripts and other files to follow beyond the main instructions. Would I actually do a thorough review every time I wanted to try a new skill? The skill was supposed to save me time.

So I wanted a quicker way to spot potential risks before using it — not to replace reading the files, but to help me understand what needed a closer look.

Starting with a local tool

That question led me to build Skill Detector, a CLI tool written in Go that I could run locally to check skills for potential security risks.

I’ll leave the implementation details for another post. The initial goal was straightforward: give myself a way to examine what I was going to add to my agent’s environment.

As I worked on it, I started thinking beyond the main instruction file. A skill can include other files and call scripts. A repository can contain multiple skills alongside other instructions and agent configuration.

Checking each skill separately meant repeating the same work and still only seeing part of the setup. I wanted to check the skills, scripts, and agent configuration together, so I could get a fuller picture without going through them one by one. That’s how Skill Detector grew from checking individual skills to checking a repository’s coding-agent setup.

From Skill Detector to SkillTrust

A CLI was a useful starting point, but it wasn’t how I wanted to run every check. Sometimes I just wanted to run a check in my browser and look through the results.

I teamed up with product designer Alex Galagan to build SkillTrust, a web app with Skill Detector running the checks.

At skilltrust.app, you can submit a public repository URL or upload a ZIP archive to check coding-agent skills and configuration for known security risks. The submitted files are analyzed without being executed.

It also gives me and Alex a product we can share, get feedback on, and keep improving.

Why I want to keep working on it

I’m interested in security and AI, and I want to build something useful for developers and teams working with coding agents.

The question that made me pause before installing that skill still feels worth asking: what are we adding to our development environment, and what do we know about it?

I’d like checking skills and agent configuration to become a normal part of setting up a development environment. I want it to be easy enough that I actually do it before installing something, rather than skip it because I’m in a hurry.

SkillTrust has limits. Static analysis can miss issues, and a report with no findings does not guarantee that something is safe. Findings also need context. I see these checks as useful information for a decision, not a replacement for judgment or sensible limits on an agent’s access.

If you use coding-agent skills, I’d like you to try SkillTrust. Check a skill or repository you’re considering using, look through the report, and see whether it helps.

I’d be interested to hear what makes sense, what feels unclear, and what you wish it checked. You can reach me on X (Twitter), LinkedIn, or by email. Questions and feedback will help me decide what to improve next.