Skills & Recipes

A compiled skill is a unit of your app's operating knowledge written in a form your coding agent can act on. It's how a convention stops living in someone's head: the platform holds the conventions, guidelines, and scaffolding an app should follow, and Cdx Code compiles them into IDE-native files in the repo — .claude/skills/ for Claude Code, the equivalent for Codex and Cursor.

Compiled skills are the primary build context /build builds from. They're the "out" half of an app board: analysis and monitoring flow in from the code; skills, recipes, and intents flow out to shape it.

Note

These are compiled skills — the operating knowledge an app board writes into a repo. They're distinct from insight skills, which define what an analysis looks for. When context could confuse the two, we always qualify which we mean.

A shared library, composed per app

Every app's skills are composed from a shared library that ContextDX curates and keeps growing — skills and recipes organized by category (workspace, core, infrastructure, frontend, integrations, features). You don't start from a blank page; you assemble this app from what's already there, and tailor the pieces that need it.

A skill resolves from two layers, the more specific winning:

Customizing is copy-on-write: editing a library skill makes a copy that belongs to this app, and never touches the library or any other app. When you don't need the customization anymore, Revert to default drops your copy and the app falls back to the library version. What lands in the repo is the resolved result — the developer never sees the layering, just the finished skill for this app.

Composing your app

A new app starts with no skills — you compose it. The Skills facet on the app's board is where you do it, two ways in:

• Start from a recipe — curated sets matched to your app's type. Apply one and its skills arrive together, in order (see Recipes below).
• Browse the library — pick skills one at a time, like Lego.

The library browser gives you:

• a category rail with live counts, so you can work area by area;
• search across a skill's name and description;
• a relevance filter that defaults to your app's type (a backend app leads with backend skills) — universal skills always show, and one click widens it to every app type;
• a preview of any skill in full — what it teaches an agent, what it ships with, and what it needs from you — before you add it.

Some skills take parameters (a value the skill interpolates) or allow multiple instances (one per integration, say) — you set those right as you add the skill. Once an app has skills, the same Add skills button, plus per-skill remove, customize, and revert, let you shape the set over time.

What a compiled skill contains

A skill is more than a page of prose. Alongside its SKILL.md, a skill can ship:

• Reference files — supporting docs under the skill's own folder that the agent loads on demand, so the core SKILL.md stays focused.
• Executable scripts — a scripts/ directory for the deterministic steps a skill defines (a check, a scaffold, a transform). Scripts land with the executable bit set and are shipped verbatim — they read their inputs from argv/env, so nothing inside them is rewritten on the way down.
• Sources & further reading — a section linking out to external documentation the skill draws on.

Recipes

A recipe is a named, ordered set of related library skills — a whole capability that arrives in one move rather than as loose parts. The recipe carries a short index over its members: what each one is, why it's included, and the order to work through them.

You apply a recipe from the recipe gallery, which surfaces first when an app is empty and orders recipes by how well they fit your app's type. One click adds the whole set; you can still add or customize individual skills afterward. A recipe never overrides a skill you've chosen deliberately — it fills in the rest.

A recipe compiles into the same bundle as any other skill — an index page plus its member skills — so it needs no new machinery on the developer's side. /build reads the index the same way it reads a single skill.

How they reach the repo

Developers pull the bundle with /skills:

/skills            # compile the bundle into the repo
/skills --status   # read-only: up to date? changed upstream? locally edited?

The write is never-clobber: a committed lock manifest (cdx-skills.lock.json) records what the command wrote, so any file you've edited locally — a SKILL.md, a reference, or a script — is detected and left alone, never overwritten. Commit the compiled skills and the lock, and the whole team (and every agent session) shares the same operating knowledge.

/skills and /build keep the bundle current: that knowledge keeps evolving on the platform, and each run compiles only what changed. The full command reference lives in the plugins guide.

Tip

Skill scripts need a current plugin build. If /skills reports that some files "need a newer plugin", run /update and re-run /skills — the prose and references sync regardless; only the scripts wait for the newer build.

What's next