Oracle Skills: five domains declared, two with content behind them

The unit of installation is a domain, not a skill

Installation appends a root-level domain directory to the repository name.

npx skills add oracle/skills/db
npx skills add oracle/skills/oci
npx skills add oracle/skills/graal
...

That is the whole model, and it has a consequence worth internalising before you install anything. You are not picking a skill; you are pulling a folder. The repository's stated guidance is to pick the domain closest to your task, install that one, and add others only when needed, which is a sensible instruction only if you know which folders exist and what is in them. There is a second, separate installation path for Claude Code, so there are two mechanisms to keep straight, and the second one derives a hyphenated marketplace name from a slash-named repository.

The Claude Code path republishes each domain as its own plugin

The repository also ships as a plugin marketplace, with a manifest in a plugin directory at the root, and each of the five domain folders published as its own plugin.

# Register this repo as a marketplace
/plugin marketplace add oracle/skills

# Install one or more domain plugins
/plugin install db@oracle-skills
/plugin install graal@oracle-skills

Two details make this usable. The plugin identifier is hyphenated, so a repository called oracle/skills becomes the marketplace `oracle-skills`, and domains are referenced with an at-sign rather than a slash. And if you have already cloned the repository you do not have to re-fetch it, because the marketplace can be pointed at a local path instead.

/plugin marketplace add ./

What you install is then browsable and toggleable with a single plugin command, and the enabled set is recorded in the agent's settings file under an enabled-plugins key rather than in the repository.

Three of the five domains are declared as roots for future work

The domain list is where the honest assessment starts. The database domain is described as the active one, covering database work, REST services, the SQL command-line tool, the vector database, frameworks, containers and agent workflows. The cloud infrastructure domain is described in similar detail, covering function deployment and troubleshooting, Kubernetes Engine cluster design, IoT digital twin workflows, and an Enterprise AI area spanning generative models, agents, retrieval, governance, model endpoints, the autonomous database, APEX and integrations. Everything else is a promise. The Fusion domain and the APEX domain are each described as the root for future skills. The GraalVM domain contains GraalVM skills, starting with Native Image, which in practice means one sub-topic. So of five advertised domains, two carry material and one carries a single folder.

The layout tree lists the cloud domain with nothing inside it

The repository includes an explicit directory tree, and comparing it against the prose is instructive. Inside the database domain the tree shows a skill file and eighteen category directories: admin, agent, application development, architecture, containers, design, devops, features, frameworks, migrations, monitoring, REST services, performance, PL/SQL, security, SQL development, the SQL command-line tool, and the vector database. That is a wider spread than the prose summary, which names only seven areas. In the other direction, the tree shows the cloud infrastructure directory with no contents at all beneath it, even though the prose describes it as the second most substantial domain. The Fusion and APEX entries show only their skill file, and the GraalVM entry shows its skill file plus one subdirectory.

A domain SKILL.md is a table of contents with five required sections

Each domain carries its own skill file, and the authoring rules define what goes in it. A real domain is organised into category directories with the skill file acting as the table of contents, and that file should normally include five sections in order: how to use the domain, the directory structure, category routing, key starting points, and common multi-step flows. The third and fourth of those are the ones that make the file load-bearing rather than decorative. Category routing is what lets an agent pick a topic without reading the whole tree, and key starting points is what tells it where to begin when a question could plausibly belong to three folders. Stub domains are told to keep their file minimal and point readers back to the readme and to a separate authoring guide at the repository root.

A mandatory section heading forces the 19c question every time

The version coverage standard is the most distinctive rule in the repository and it is three lines long. Any skill that includes version-specific behaviour must include a section with a specific name, comparing the 19c and 26ai releases. The baseline compatibility target is database release 19c unless a skill states otherwise. And features that require a newer release have to be called out explicitly, with a 19c-compatible alternative offered where that is practical. This is the mechanism that stops a skill confidently describing a feature that does not exist on the release a reader is running, which is a failure mode that documentation written for the newest release produces constantly. Requiring it as a named section rather than a general instruction means a reviewer can grep for it.

Four sources back a repository that claims to be source-backed

The emphasis on source-backed guidance is repeated in the goal statement and the domain description, so the sources section is worth reading closely. It lists four items: two Oracle documentation pages covering Container Engine and the internet of things, a GitHub repository of IoT samples, and the GraalVM native-image reference manual. Two of the four are about IoT, and one is about native compilation. Nothing in that list points at database release documentation or at the retrieval and agent material the cloud domain is described as covering. Individual skills are presumably expected to carry their own citations, since the authoring standard says as much, but the repository-level evidence base is thin and skewed towards two of its five domains.

Reachability metadata gets its own file in a four-file GraalVM folder

The GraalVM domain is the smallest populated one and it is worth looking at anyway, because its shape tells you what the authors consider hard. The Native Image subdirectory contains four documents: one on building a native image, one on the native build tools, one on troubleshooting, and one on reachability metadata. That last file is the interesting one. Reachability metadata is what lets a native-image compiler see through reflection and dynamic class loading to code it cannot see statically, and getting it wrong is the single most common reason a Java application compiles to a binary that fails at runtime rather than at build time. Giving it a dedicated document in a folder with only three siblings is a reasonable editorial judgement about where the difficulty actually sits. The domain also carries a skill file of its own, so the GraalVM material is reachable without reading the repository readme.

Editorial conclusion

Oracle Skills suits someone who wants Oracle guidance available inside a coding agent rather than in a browser tab, and who needs to know which database release a piece of advice applies to. Four things to check first. Decide whether you want the database domain or the cloud one, because they are separate installs and the database domain is the one with content behind it today. Expect to install a whole domain rather than a single skill, because the unit of installation is the domain directory. Read the version standard before trusting any skill that mentions a feature, since the repository requires a dedicated section comparing 19c with 26ai but cannot guarantee every third-party page follows it. And note the licence, which is Oracle's own permissive UPL rather than a standard open-source licence.

Frequently asked questions

Official sources

1. Issues
2. License: UPL-1.0
3. oracle/skills on GitHub
4. README