Oracle Skills: A Domain-Routed Skill Collection for Oracle Work
Oracle Skills is a curated, open-source collection of practical, installable skills for working with Oracle technologies. It provides developers, administrators, and AI agents with high-quality, source-backed guidance across the entire Oracle ecosystem.
At a glance
- What is it?
- Oracle Skills packages Oracle guidance as installable units, one per domain, so that a developer or an AI agent loads only the material relevant to the task at hand. The design is a routing layout with a version-coverage rule, not a library of code.
- Who is it for?
- Adopt oracle/skills if you work inside Claude Code or another agent that consumes the skills format and you want Oracle Database, OCI, or GraalVM guidance pulled in per task rather than pasted from browser tabs. Skip it if you need Oracle Fusion or Oracle APEX content today: the README describes both as future roots, and the repository layout shows only a SKILL.md in each.
- Can I use it commercially?
- Yes. UPL-1.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Oracle Skills addresses is retrieval, not capability
Oracle documentation is not scarce. It is spread across product families that share a vendor and almost nothing else. A developer moving between an Autonomous Database migration and an OKE cluster design is switching vocabularies, toolchains, and release cadences. Oracle Skills takes the position that the useful unit of help is a small, installable skill scoped to one domain, with a SKILL.md acting as a table of contents and category directories underneath it. The README states the goal plainly: give developers and agents a single place to find source-backed Oracle guidance across Oracle Database, Oracle Cloud Infrastructure, GraalVM, Oracle Fusion, Oracle APEX, and future domains. The audience is two-fold. Developers and administrators get curated guidance. AI agents get the same material in a form they can load on demand, which is the more interesting half. An agent that installs the db domain does not carry OCI IoT Platform digital twin workflows in its context. That selectivity is the whole point.
Domain directories, SKILL.md routing, and the version notes rule
The repository is a set of sibling domain directories: db, oci, fusion, apex, and graal. Each has its own SKILL.md. For a real domain, the README instructs authors to organize content by category directories and use SKILL.md as the table of contents, and it names the sections a domain SKILL.md should normally include: How to Use This Domain, Directory Structure, Category Routing, Key Starting Points, and Common Multi-Step Flows. That is a routing layer, not a knowledge dump. The db directory shows the shape at full size, with subdirectories for admin, agent, appdev, architecture, containers, design, devops, features, frameworks, migrations, monitoring, ords, performance, plsql, security, sql-dev, sqlcl, and vecdb. The oci directory is organized differently, around enterprise-ai, functions, iot-platform, and oke, and several of those carry their own scripts, templates, agents, shared, examples, and tests folders. The README explicitly permits this: each domain can evolve its own taxonomy without breaking repo-wide consistency. What holds the collection together is a version rule. Any skill covering version-specific behavior must include a section named Oracle Version Notes (19c vs 26ai), with 19c as the baseline compatibility target unless stated otherwise, and newer-release features must be called out alongside 19c-compatible alternatives where practical. That single convention is what makes the collection checkable rather than merely large.
Installing a domain through npx or as a Claude Code plugin
There are two supported installation paths. The first is the skills CLI, where you append the root-level domain directory to the repository name. The README gives these examples: npx skills add oracle/skills/db, npx skills add oracle/skills/oci, npx skills add oracle/skills/graal. The second path treats the repository as a Claude Code plugin marketplace. The file .claude-plugin/marketplace.json publishes each domain folder (apex, db, fusion, graal, oci) as its own plugin. Registration and installation use slash commands inside Claude Code: /plugin marketplace add oracle/skills, then /plugin install db@oracle-skills or /plugin install graal@oracle-skills. If you already cloned the repository, the README shows pointing the marketplace at the local path with /plugin marketplace add ./ instead. Installed plugins are tracked in .claude/settings.json under enabledPlugins, and /plugin browses and toggles them. The README's Start Here sequence is three steps: pick the domain closest to your task, install that domain skill, and add other domain skills only when needed. Note the naming mismatch you will hit in practice: the marketplace publishes apex and fusion as plugins even though both are described as roots for future skills, so installing them gets you a stub.
Where the collection is thin, and where it will mislead you
The README is candid about maturity, and the candor is worth taking literally. Oracle Fusion and Oracle APEX are described as roots for future skills, and the repository layout confirms it: fusion/ and apex/ each contain a single SKILL.md and nothing else. The README's own guidance for stub domains is to keep SKILL.md minimal and point users back to README.md and SKILL_AUTHORING_GUIDE.md. So an agent that installs the apex plugin gets a pointer, not APEX guidance. The second limitation is scope asymmetry inside the active domains. oci/ spans enterprise AI, Functions, IoT Platform, and OKE, and those subdirectories carry scripts, templates, and tests. db/ is broad by category but the layout shows no equivalent tests directory at the domain root. If you are choosing where to spend trust, the oci subtree is the one with visible verification scaffolding. Third, the version rule is a documentation standard, not an enforced check. Nothing in the supplied material shows a validator that fails a build when a skill omits its Oracle Version Notes section. The convention only holds if contributors follow it, and the README phrases it as a standard rather than a gate. Finally, the repository has no retrieved releases, so there is no versioned artifact to pin. You are tracking the main branch.
How this differs from Oracle's own documentation and sample repositories
The obvious alternative is reading docs.oracle.com directly, and the README lists four sources it draws on: the OCI Container Engine documentation, the OCI Internet of Things documentation, the oracle-samples/oci-iot-samples repository, and the GraalVM Native Image reference manual. The difference is packaging and granularity. Vendor documentation is organized by product and assumes you already know which product you need. A sample repository gives you a working artifact for one scenario. Oracle Skills sits between them: it is organized by task domain, and its unit of delivery is a skill an agent can load. Consider the GraalVM case. graal/native-image/ contains four files: build-native-image.md, native-build-tools.md, reachability-metadata.md, and troubleshooting.md. The GraalVM reference manual covers far more than Native Image, and it does not split build configuration from reachability metadata from troubleshooting. The skill layout does, which matters when an agent needs the reachability metadata rules without the rest of the manual. The trade-off is currency and depth. A curated skill is a snapshot with an editorial point of view; the upstream manual is authoritative and continuously updated. For a feature that changed in a recent release, the skill may lag, which is exactly what the Oracle Version Notes section exists to surface.
Licence and the cost of keeping skills current
The repository is licensed under UPL-1.0, the Universal Permissive License. It is a permissive licence, and permissive terms generally allow modification and redistribution, but the obligations differ from Apache-2.0 and MIT in ways worth reading rather than assuming. This is a description of the licence identifier in the repository metadata, not legal advice; check the actual licence text before redistributing the skills or bundling them into a product. On maintenance, the cost structure is unusual. There is no runtime to upgrade, no dependency graph to resolve, and no retrieved releases to pin against, so the ongoing cost is editorial rather than operational. Someone has to keep each domain's SKILL.md current as Oracle ships new releases, and the README's version rule means that work includes revisiting the 19c versus 26ai notes in every skill that touches version-specific behavior. The repository was last pushed in September 2026 according to the metadata. If you install through the Claude Code marketplace, updates arrive when the marketplace refreshes; if you clone, you own the pull. Either way, the thing that decays is the accuracy of the guidance, not the installation.
Editorial conclusion
Adopt oracle/skills if you work inside Claude Code or another agent that consumes the skills format and you want Oracle Database, OCI, or GraalVM guidance pulled in per task rather than pasted from browser tabs. Skip it if you need Oracle Fusion or Oracle APEX content today: the README describes both as future roots, and the repository layout shows only a SKILL.md in each. Before relying on any domain, check whether its SKILL.md carries the required Oracle Version Notes section, since the README sets 19c as the baseline and requires newer features to be flagged with 19c-compatible alternatives.
Community notes