
# Your AI Skills Need a Package Manager

Every time I start a new project, I have to do some mumbo jumbo to get the correct skills available for my project and client. Copying skills from one project to another, or installing them globally. It's a mess. I want to be able to manage my skills and agents like I manage my code dependencies. 

I play around with different coding agents and I need to do this whole copy-paste-install process every time. Forgetting to copy a skill, and then wondering why the behavior of this new coding agent is different.

[skills.sh](https://skills.sh) is a nice tool to install skills. But there is no management. I have to remember which skills I need to install, and updating only works on global skills. So I decided to build dependency management for agents.

Enter [agentdeps](https://www.npmjs.com/package/agentdeps).

**Agentdeps** allows you to create an `agents.yaml` file in your repo. This file contains the skills and agents you want to use. You can commit this file, just like your pom.xml or requirements.txt, and everyone working with the repo will have the same skills and agents. When you change the file, everyone can update their environment with a single command.

### Adding skills and agents to your repo

With the `add` command you can interactively add skills and agents to your project (or globally). You can select the ones you want and it will create an `agents.yaml` file in your repo. If there is already an `agents.yaml` file, it will update it with the new skills and agents you selected.
 
```
npx agentdeps add vercel-labs/agent-skills
```

Choose your skill (or all):
<img src="/images/installing_skills.png" alt="Select skills" style="max-width: 600px;" />

### Updating

Did the config change, or did you just clone a repo with an `agents.yaml` file? Run `install`.

```
npx agentdeps install
```

### Configuration

On first run, **agentdeps** will ask for some configuration. Mainly, which cloning mechanism to use (https/ssh), and how to install skills and agents (symlink or copy). You can change this configuration at any time. Just run `npx agentdeps config` and it will ask you the configuration questions again.

***We've been managing code dependencies for decades. Why are we still manually wrangling our AI skills? Give [agentdeps](https://www.npmjs.com/package/agentdeps) a try and let me know what you think.***


I built a package manager for AI agent skills. Here's why.

Your AI Skills Need a Package Manager


# Demystifying the AI Agent

"My coding Agent is the best!" I keep hearing this in developer communities. People debate which agent is the best AI coding tool. Claude Code, OpenCode, Cursor, etc. And people are passionate about their choice and trying to get their company to support their agent of choice. But here's the thing: the agent isn't doing what you think it's doing.

[Jeroen Dee](https://aishepherd.nl) pointed me towards [Pi](https://pi.dev) and together we expiremented with it this week. Pi is a minimal AI agent with just four tools: read, write, edit, and bash. That's it. No MCP, no Todos, no sub-agents, and no fancy UI tweaks. Just four tools and a model. And it works.

That got me thinking. If four tools are enough, what exactly are all these agents *actually* doing?

## What is an Agent, Really?

An agent is three things:

1. **A system prompt.** This is the "personality" and "harness" of the agent. It tells the model how to behave, what tone to use, what rules to follow. 

2. **A list of tools.** These are the actions the model can ask to perform. Read a file, write a file, run a command in bash. Each tool has a name, a description and a schema that defines the arguments. This way the model knows when to use it and how.

3. **A loop.** The agent takes your question/prompt, attaches the system prompt and tool list and sends it to the model. The model either responds with text (shown to you) or asks to use a tool. If it's a tool call, the agent executes it and sends the result back to the model. Repeat until the model sends back text. That's when the loop is done and the agent waits for user input.

That's it. That's the whole thing.

The model decides what to do. The model decides which tools to use. The model decides when it's finished. The agent is the plumbing. The model is the brain.

## So Where's the Magic?

The magic is in the model. Always has been. When Claude Code writes a beautiful refactoring of your messy function, that's Claude Opus/Sonnet/Haiku doing the thinking. The agent just handed it the right files when the model asked for it. 

So when someone says "my agent is better," what they usually mean is "my model + context + UX combo is better." Some agents may have a better (for you) system prompt than others. It may have a nicer UX and some quality of life features. These things matter a lot day-to-day. But the actual intelligence? That comes from the model.

## Skills Are Just Text Files

After my Pi discovery, I had another "wait, that's it?" moment about skills. In my [AI Coding Ladder](/blog/the-ai-coding-ladder) post, I described Level 5 (the Agentic Coder) where the AI gets access to tools and organizational knowledge. Skills are a big part of that.

But a skill is nothing more than a name, a description, and a markdown file. The system prompt nudges the model to check available skills to see if the task matches a skill description. When it matches, the model reads the skill file (by asking via a tool call). What you put into that file is up to you. References to websites, scripts, templates, coding standards. The model will just receive the SKILL.md and based on the content may try to read further resources or perform certain actions (again through tool calling). The outcome depends on how good your SKILL.md is.

There's no framework. No magic folders. It's a text file that the model reads when it seems relevant. That's the whole mechanism.

## Pi: Power Through Simplicity

This is what makes [Pi](https://pi.dev) so interesting. Instead of building a massive tool with hundreds of features, it gives you the bare essentials and says: "You figure out the rest."

Four tools. Read, write, edit, bash. With these four, the model can do almost anything. Need to search your codebase? Bash. Need to run tests? Bash. Need to modify a file? Edit. Need to understand what's going on? Read. Need MCP? Just let it write a bash script!

But here's the really clever part: from what I've tried so far, Pi can extend itself. Want a new feature? Ask Pi to build it and add it to Pi. It writes its own tools. It has a very powerful extension mechanism, with which you can tweak everything, from UI to system prompt. It grows with your needs instead of shipping with a thousand features you'll never use.


> [!NOTE]
> Pi is also the core of [OpenClaw](https://openclaw.ai)

## Why Does This Matter?

Because understanding the simplicity changes how you work.

If you know the agent is just plumbing, you stop attributing magic to the wrong thing. You focus on what actually matters: the model you're using, the context you're providing, and the instructions you're giving. A better system prompt will improve your results more than switching agents. Whenever something strange happens, look at the context. What did the model receive and why did it do what it did?

It also means you don't need to wait for your favorite agent to ship a feature. Need something? Build it. Write a skill. Add a tool. The barrier is surprisingly low.

## Build Your Own

I think we're moving into an era where heavy, expensive SaaS solutions are being replaced by in-house, purpose-built tools. Why buy an expensive software solution with a lot of functions you don't need, when building it yourself is cheaper? If we developers think we can easily build any system, why should our AI coding agents be any different?

Start bare. Add what you need. Remove what you don't. No need to try to understand all the features that your agent brings. You only add the features you need. Your agent should fit like a glove, not like a one-size-fits-all winter coat.

The next time someone tells you their agent is the best, ask them: which model does it use?

That's where the real answer lives.


AI agents sound complex, but they're surprisingly simple. A system prompt, a few tools, and a model doing the real work. Here's what's actually under the hood.

Demystifying the AI Agent


# Kotlin's LSP Problem is Real

I wrote about [The Kotlin Paradox](/blog/java-vs-kotlin-ai) last month. Back then, it was mostly theoretical: "In an AI-driven future, Java's robust LSP might beat Kotlin's nicer syntax." It felt like speculation about a problem I foresaw.

It's not theoretical anymore. I'm living it.

## The Daily Grind

Here's my typical day: I have AI agents writing code across multiple worktrees. They're doing the implementation while I architect and review. When I need to check something, I just want to **click through the code**.

That's it. Go-to-definition. Find references. Basic navigation.

With IntelliJ, this works perfectly. It's a nice IDE, but it is too heavy for my task. Opening IntelliJ for each git worktree (is that even working now? There was a bug with git worktrees) is killing my productivity. 

I don't want a full IDE. I want to open Helix, or Zed, or VS Code, navigate quickly, and close it.

## The Remote Work Problem

It gets worse. A lot of my work happens in devcontainers or on remote boxes.

Open a full remote JetBrains session? Tried that, and 5GB of memory is gone, just to watch a few files. The process is also painful. I just want to `hx .` and browse to the file and check something. With all other options, I have to click through menus, to open a folder somewhere on the remote filesystem. With [OpenCode](https://opencode.ai) and [Claude Code](https://github.com/anthropics/claude-code), my work happens more and more in the terminal. Needing to leave the CLI, breaks my flow.

With Go or Python, I'd just open Helix or VS Code Remote if I want a little more tools. The LSP connects, and I'm navigating code within seconds. `gd` to jump to definition, `gr` to find references. It just works.

With Kotlin? I get a text file with pretty colors.

The Kotlin LSP situation is terrible. Jetbrains is working on one, but it's pre-alpha and barely works.

## The Agent Perspective

The AI agents ([OpenCode](https://opencode.ai), [Claude Code](https://github.com/anthropics/claude-code)) face the same problem. When I'm working with Go or Python codebases, I see them using LSP features. I'm not sure which features are used, but I do see error messages coming back. This allows for faster iteration, because the agent already sees the error, before needing to compile and wasting time waiting on the results.

## The Breaking Point

I feel sad and frustrated. Kotlin is still a nice language, and a few months ago I was in camp: "Use an IDE to develop, not a text editor!". But I don't write code by hand anymore. My agents do. And when I need to review, navigate, or verify, I need tooling that works outside the JetBrains ecosystem.

If I were starting a new project today, knowing what I know now about agentic workflows and the importance of universal tooling?

Kotlin wouldn't be my choice.

## What Would Fix This

JetBrains, if you're reading: the community needs a real Kotlin LSP. Not "pre-alpha." Not "experimental." A proper language server that works in all editors and AI agents that support it.

Until that changes, every new project I start is going to be a harder sell for Kotlin. And I suspect I'm not alone.


I just want to click through code. The state of Kotlin's LSP is driving me away from the language.

Jeroen Gordijn

Latest Articles

Your AI Skills Need a Package Manager

Demystifying the AI Agent

Kotlin's LSP Problem is Real

Ready to Develop Faster with AI?