Codee Skills: Your Own Repository for AI Skills

Working on projects with AI, I ran into two real problems. The first is security. I won't copy "skills" into a project that I haven't reviewed, pulled from random repositories I'm not sure about. The second is updates. When I build my own skills, I want to update them efficiently in one place. Not copy them back and forth every time I change a single word or add two sentences.

Those two needs are why I built the tool I describe in this post. I wrote my own CLI and my own skills repository, to keep everything in one trusted place and install it into a project with a single command. It works with Claude Code and Codex.

In this post you'll learn:

1. Why copying skills between projects doesn't work
2. What the Codee Skills repository is and how it's built
3. What global skills give you, regardless of the framework
4. What working with the ags CLI looks like day to day

The problem: the agent starts from zero in every project

An AI agent doesn't remember your conventions. In every new project it starts with no idea how you write code, how you name files, how you phrase interface copy or specifications. The natural reflex is to paste your instructions into the .claude/ directory, or another folder depending on the tool, and move on.

This approach breaks in two ways.

The first is trust. The internet is full of ready-made skills, but a skill is an instruction the agent runs on your code and in your environment. Pasting something you haven't read line by line is exactly the same risk as running someone else's script without checking it. That's why only skills I wrote or reviewed myself make it into my projects.

The second is maintenance. When I'm working and notice a skill is worth improving, adding a rule or clarifying an example, that change lives in one project and the rest don't know about it. After a few weeks I have five versions of the same skill, each slightly different, and no certainty which one is current. Copying files by hand doesn't scale when you change a single word.

What Codee Skills is

Codee Skills is a repository of AI Skills. One place where I keep all my skills, and from which I install them into specific projects. The repository is the source of truth. The copy in a project always comes from here and is updated from here.

Skills fall into two groups:

codee-skills/
  general/                     # skills independent of the stack
    code-style/
    project-organization/
    skill-creator/
    spec-writing/
    ui-copy/
    writing-questions/
  frameworks/                  # skills for specific technologies
    medusa/
    payload/

general/ are useful in every project, regardless of the technology.

frameworks/ is knowledge specific to a particular tool, for example Payload or Medusa.js conventions.

Every skill is a plain directory with a SKILL.md file. One important rule: skills must be real directories, not symlinks, because the installer skips them.

Installation always lands in two locations at once: .claude/skills/ for Claude Code and .agents/skills/ for Codex. So I don't care which agent I'm using in a given project. Both see the same, up-to-date skills.

Global skills, or what works in every project

The skills in general/ give me the most value day to day, because they aren't tied to any technology.
Right now I have a few of my own skills that I use every day:

• code-style sets the code conventions: when to comment, how to name things, how to organize files. The agent stops guessing my style and writes the way I write from the start.
• spec-writing helps with writing a specification for a specific module or feature. First a skeleton and a list of open questions to close before the rest of the document takes shape. Only then the architecture and breaking the work into small, testable steps. We start the implementation only once the spec is done. Technical skills matter here, because this skill helps build the specification, but how and in which direction to build it is the author's call.
• ui-copy sets the rules for interface text: labels, headings, error messages, empty states. A consistent product voice without rewriting it every time.
• writing-questions is a format for asking questions. Short, in the first person.
• project-organization generates a PROJECT-ORGANIZATION.md document for a new project: team, tools, workflow, sprints.
• skill-creator helps build a new skill from a ready-made skeleton, so each next one follows the same structure.

This is the core idea. Knowledge about how we work, written down once, is available in every project and for every agent, instead of living in one person's head or in a single repository.

How it works in practice: the ags CLI

I wrote a small CLI to manage skills. Under the hood, npx skills from Vercel Labs handles the installation. I didn't rewrite what already works. My ags wraps that tool so it fits one repository and two agents at once. I add three things:

• It finds the source on its own. I don't pass the repository path with every command, because ags reads it from its own location.
• It installs for both agents at once. Every install runs with flags for Claude Code and Codex in copy mode, so skills land as real directories in .claude/skills/ and .agents/skills/. I'm not tied to these two. npx skills supports other tools as well, so adding another model is just one more flag and one more location the same skill goes to.
• The picker reads skill descriptions. The list from ags skills add groups skills by folder and shows the description from SKILL.md, so you choose deliberately, not by name alone.

Commands at a glance

Not every command is equally "mine". Some are a thin pass-through to npx skills, some add logic, and two don't touch npx at all.

The repository doesn't have to be mine. ags skills add also accepts a URL, so you can pull skills straight from someone else's repository on GitHub. Framework authors already do this officially: Payload and Medusa.js maintain their own skill sets, which you plug in with a single command and update just like your own. With one caveat consistent with where I started: I read an external skill first, and only then add it. push-skill is off the table in that case, because pushing changes back only works for repositories I have locally.

Getting started in 3 steps

First you clone your (or my) repository:

git clone git@github.com:codee-sh/codee-skills.git

Then you add an alias to ~/.zshrc, replacing the path with the one where you cloned the repository:

echo 'alias ags="node /path/to/codee-skills/bin/codee-skills.js"' >> ~/.zshrc
source ~/.zshrc

Then, in the project directory, you install the skills:

ags skills add

That's it. ags skills add with no argument opens the interactive picker, where you select individual skills or a whole subfolder. You can also pass a name directly:

ags skills add code-style           # a single skill
ags skills add frameworks/payload   # a whole subfolder

After installation, a skills-lock.json file appears in the project, recording the source of each skill. That's how you know where a given skill comes from and when it was pulled.

Updates without copying

This is where my second problem gets solved. Instead of copying files by hand, I run:

ags skills update           # checks all skills
ags skills update code-style   # or one specific skill

The command first runs git pull in the source repository, so it always compares the project against the latest version from GitHub. If either location is out of date, it reinstalls the skill.

Team workflow: push-skill

Updates work the other way too. When I fix a skill directly in a project, I want to give that change back to the repository so the rest of the projects get it. That's what push-skill is for:

ags push-skill                  # shows changed skills
ags push-skill code-style       # a specific skill
ags push-skill code-style --dry-run   # preview without writing

The command scans local skills, shows which ones changed, checks whether the repository has newer changes, displays the diff, and asks for confirmation. Only then does it commit and push. Finally it syncs the copy for the other agent, so .claude/skills/ and .agents/skills/ don't drift apart.

In practice it looks like this: I fix a skill in the project I'm currently working on, run ags push-skill, and from that point every next project pulls the new version through ags skills update. One repository, one current version, no matter how many people and projects are involved.

Good practices

A few things that make this approach easier:

• Skills as real directories. Symlinks are skipped by the installer, so every skill has to be a physical folder with a SKILL.md file.
• One skill, one responsibility. Better to keep code-style and ui-copy separate than one giant skill about everything. Granular skills are easier to update and to pick for a project.
• A deliberate split between general and frameworks. If the knowledge works regardless of technology, it belongs in general. If it concerns a specific tool, it goes to frameworks.

To sum up

Codee Skills solves two concrete problems I had while working with AI agents. Security, because only skills I've reviewed myself make it into a project. And maintenance, because updating in both directions is a single command instead of copying by hand. The value grows with every next project where the same, reviewed skills are available right away.

This approach will make sense for you if you work with Claude Code, Codex, or another tool, across more than one project, and you're tired of pasting the same instructions over and over.

In the next post I'll show the other side of this setup: framework skills. The examples will be Payload CMS and Medusa.js, the two technologies I work with day to day right now.