skyl

getting started

Install

Skills are plain markdown, so every tool that reads a rules directory can use them. One command writes them, and the only thing that changes per tool is where.

The CLI

npm
  1. Run it without installing anything. This is the whole of it.

    $npx skyl.dev scan
  2. Or keep it around, if you will run it in more than one project.

    $npm i -g skyl.dev
  3. Name the layers yourself when you already know them.

    $skyl add android/core kotlin compose

scan reads your build files, proposes the 13 skills that match, and writes nothing until you say so. Every command takes --target to pick the tool, and the full reference is on the docs page.

Claude Code

Plugin marketplacewrites .claude/skills/
  1. Add the marketplace, once per machine.

    $/plugin marketplace add skyl-dev/skyl
  2. Install the family you need.

    $/plugin install skyl-android@skyl

Runs inside Claude Code, no terminal. Updates arrive with /plugin marketplace update.

The CLI writes a directory per skill: SKILL.md with the name and description Claude Code reads, and references/ beside it.

The CLI works here too, and gives you the lockfile and per-project selection.

Cursor

Rules directorywrites .cursor/rules/
  1. Let it read the project and propose.

    $npx skyl.dev scan --target cursor
  2. Or name the layers yourself.

    $npx skyl.dev add android/core kotlin compose --target cursor

Writes .mdc files with the frontmatter Cursor expects, so each rule stays scoped instead of always-on.

One file per skill, so the reference files a rule points at stay behind. add says which ones, and they are on this site under each skill.

Codex

Reads AGENTS.mdwrites .agents/skills/
  1. Read the project and propose.

    $npx skyl.dev scan --target agents

Codex picks up the AGENTS.md convention, so it takes the same target as anything else that reads it. Nothing here is Codex-specific.

A directory per skill holding SKILL.md, with the reference files beside it.

AGENTS.md

Open conventionwrites .agents/skills/
  1. Write the shared convention.

    $npx skyl.dev scan --target agents

The vendor-neutral path. Any tool that reads AGENTS.md picks these up, and nothing in the files names a vendor.

A directory per skill holding SKILL.md with name and description, and references/ beside it.

Windsurf

Rules directorywrites .windsurf/rules/
  1. Read the project and propose.

    $npx skyl.dev scan --target windsurf

Writes plain markdown with the trigger field Windsurf reads, so each skill applies when its description fits rather than always.

Windsurf reads 6,000 characters of a rule and 12,000 across all of them, and truncates the rest silently. Most skills here are past the first number, so add prints the sizes and you choose what to install. References stay behind for the same reason Cursor's do.

Continue

Rules directorywrites .continue/rules/
  1. Read the project and propose.

    $npx skyl.dev scan --target continue

Writes plain markdown with name, description and alwaysApply: false, so a rule is offered rather than always on.

One file per skill, so reference files stay behind.

Everything else

Any tool that reads markdownwrites .agents/skills/
  1. Write the neutral directory, then point your tool at it.

    $npx skyl.dev add android/core --target agents

A skill is a markdown file with a heading and a list of rules. There is nothing in it that needs a particular tool, so a tool this page has never heard of reads the same files: write them once and configure it to load that directory.

If your tool wants its own directory or frontmatter, that is a target, and a target is about twenty lines. Open an issue on the CLI repo.

What lands in your repo

One markdown file per skill, containing only the rules, with the reference files its rules point at beside it where the tool takes a directory. Plus skyl.lock, recording what was written and its content hash. Everything is reviewable in a pull request, and a reinstall produces no diff.

What does not

The reasoning, the pitfalls, and the evidence behind each rule stay in the registry. They are for you, not for the model, and sending them would spend context on text that changes nothing.

Switching tools later

Run the same command with a different --target. The skills are the same files in a different directory, so nothing is locked to one vendor. 1 family, 13 skills today.