intellij-sdk-code-samples is a shelf of runnable IntelliJ plugin projects

Samples that run, rather than fragments that compile

The IntelliJ Platform SDK Code Samples repository describes itself as a mirror of the IntelliJ SDK Docs code samples, and the readme puts the intent plainly: learn how to build plugins using the IntelliJ Platform SDK for the JetBrains products by experimenting with our code samples, and these samples show you how features work and help you jumpstart your plugins.

The word that matters is experimenting. These are not documentation snippets. Each one is a separate directory in the repository, a stand-alone project, and the table says they are all available for running with the Gradle runIde task. So the learning loop is: open a sample, run it, and see the feature in a live IDE.

That is a different proposition from a code listing in a manual. A listing shows you the shape of an API call. A sample shows you the whole assembly, because a plugin feature is never just one class, it is a class, a registration in the plugin definition file, and a place in the settings or menu where the user meets it. The samples cover that whole assembly, and the descriptions in the table name the user visible surface, which is what tells you where a feature lives in the IDE.

The primary language is Java, and the licence is Apache 2.0, in the LICENSE.txt file at the root. The repository is not archived, and the last push was on 2026-10-07.

The audience is a plugin developer at the stage where the API documentation has told them which extension point to use but not what a working implementation looks like, and a teacher or workshop leader who needs something that runs on a projector.

Every sample is its own Gradle project

The structure section explains the build, and it is short. Code Samples depend on the IntelliJ Platform SDK and Gradle as a build system, and the main plugin definition file is stored in the plugin.xml file, which is created according to the Plugin Configuration File documentation. It describes the definitions of the actions, extensions or listeners provided by the plugin.

So the anatomy of every sample is the same. A Gradle project that pulls in the platform SDK, a plugin.xml that declares the extension points, and code in the source set.

The plugin.xml point deserves emphasis, because it is the file that beginners underrate. In the IntelliJ platform, most features are not discovered by classpath scanning or by magic. They are registered, by name, in the plugin definition file. An action, an inspection, an intention, a facet, a tool window, a project model component: each one is a line in the XML pointing at a class. Move the class, forget the line, and the feature simply does not appear in the IDE, with no compile error and usually no obvious message.

That is why the readme points you at the available Extension Points, at the IntelliJ Platform Explorer for seeing how extension points are used in open source plugins, and at the documentation page on exploring the IntelliJ Platform API. The samples show the usage, the extension point list shows the vocabulary, and the Explorer shows how other people solved the same problem.

The top level of the repository shows the shape of the whole set: one directory per sample, each named after the feature it demonstrates, so action_basics, editor_basics, facet_basics, framework_basics, live_templates, module, project_model, project_view_pane, project_wizard, psi_demo, run_configuration, settings, simple_language_plugin, theme_basics, tool_window, tree_structure_provider, and the inspection and intention samples alongside them. There is also an oauth2 directory, a _gradleCompositeBuild directory, a SAMPLE_README.md and a CONTRIBUTING.md.

The catalogue covers one feature per sample

The table of samples is the best part of the readme, because each row names a feature and the place in the IDE where the user will meet it.

Action Basics implements the Action and Action Group patterns and adds entries to the Tools menu. Editor Basics is a basic Editor APIs example with an editor popup menu with extra actions. Project Model interacts with the project model and adds menu items to the Tools and Editor Context menus. Project View Pane is a project view pane listing only image files. The Comparing References Inspection is a local inspection tool that adds entries to Settings, Editor, Inspections, Java, Probable Bugs. The Conditional Operator Intention is an intention action that suggests converting a ternary operator into an if block and adds an entry to the Intentions settings. The Kotlin Class Name Convention Inspection is a local inspection tool that checks the Kotlin class name convention and is allowed to be run in Qodana.

The structural samples follow the same logic. Facet Basics adds an SDK Facet to the Project Structure dialog. Framework Basics adds SDK Demo Framework support to the File, New, Project, Java wizard, and Module does the same for an SDK Demo Module. Live Templates adds an entry to the Live Templates dialog for the Markdown language. Max Opened Projects uses application services and listeners to show a warning when more than 3 projects are open. Run Configuration implements a run configuration with a factory, options and UI. Settings adds a settings panel under Tools. Theme Basics is a theme plugin with basic interface modifications. Tool Window demonstrates a tool window. PSI Demo presents the PSI navigation features. Project Wizard is a project wizard example with demo steps.

And then there is Simple Language Plugin, which defines a new Simple language with syntax highlighting, annotations, code completion and other features. That one is the outlier and the most valuable, because a language plugin is where all the platform pieces come together, and no amount of reading about actions and intentions prepares you for it.

The target platform is the latest GA minus three releases

One line decides whether a sample runs on your IDE, and it is short. All Code Samples target the Latest GA - 3 Releases platform.

That is a moving target in the literal sense, since the latest GA changes with each release, and it is also a deliberate policy. A plugin built against a platform that is three releases old will keep working for longer, and it will not break the moment a new IDE release changes an internal API. The cost is that you are not developing against the newest APIs, and some features available in the current build will not be in your plugin.

For a sample repository the choice is obvious, since a sample that only runs on the newest build is a sample most people cannot run. For your own plugin, the same policy is a reasonable default, and the extension point documentation is where you check whether the API you need exists in the version you target.

The build infrastructure is the other half of the answer. The repository has a GitHub Actions workflow for the code samples, so the samples are compiled in continuous integration against the platform, and a broken sample is a red build rather than a broken link in the documentation.

One thing to keep in mind when you copy a sample. The samples are written to be read and run, not to be published, and the documentation does not describe adding a compatibility range, signing the plugin or preparing it for the marketplace. That work is yours, and it is the part of the readme that is deliberately absent, because the repository is about how the platform works rather than about how to ship.

Where the samples stop and your plugin begins

The honest limitation is that a sample is a demonstration, and a demonstration optimises for being understood rather than for being shipped.

The most obvious gap is the plugin definition file. A sample declares the extension points it needs to show one feature working. A real plugin needs the compatibility range so the IDE knows which builds to load it in, the plugin id, the vendor and the description, and a published plugin is usually signed so users can verify it. None of that is in these samples, because none of it demonstrates a feature.

The second gap is structure. A sample is one directory with one feature, and it is not organised the way a plugin with many features has to be organised. There is no packaging step, no localisation plumbing, no separation of the plugin descriptor from the code beyond what a single sample needs, and no build configuration for producing a distribution archive. The samples are the raw material for a plugin, not the container for one.

The third gap is that they show the platform doing what the platform does, not the platform in production. There is no error handling for a plugin that has to survive a user's broken state, no performance work, no compatibility testing across platform versions, and no automated tests in the samples as presented.

None of that is a criticism, because the samples are not claiming to be any of those things. They are a teaching surface, and the value is that the code is short enough to read in one sitting and real enough to run. The trap is treating a sample as a starting point you extend, when the right way to use it is to read it, then write your own plugin with the platform documentation open beside you.

A mirror, a licence, and where to ask questions

The repository is a mirror, and the readme says so. The code samples can also be found in the IntelliJ SDK Code Samples mirror repository, and the readme is a copy of the samples published alongside the SDK documentation, whose own tree is linked as the homepage.

That arrangement has a practical consequence. If you want to propose a change to a sample, the mirror is not obviously the place to do it, since the documentation repository is where the change would have to land for the copy to stay in sync. The CONTRIBUTING.md in the repository is the file to read before you open a pull request, and it will tell you which side owns the change.

The licence is Apache 2.0, in LICENSE.txt, and the repository has a CODE_OF_CONDUCT.md, so the terms are the permissive ones with the explicit patent grant. For code samples that is the right licence, because you are expected to copy from them.

The community channels are linked in the readme badges. There is a Bluesky account at platform.jetbrains.com, an X account at JBPlatform, the JetBrains Platform Forum, and the official JetBrains project badge marks this as a first party repository rather than a community one.

And the documentation is where the code lives in context. The Code Samples topic describes how to import and run the samples, and the readme asks you to browse the available extension points and explore the IntelliJ Platform API. The samples are the executable half of that documentation, and the prose half is what explains why each one is shaped the way it is.

Editorial conclusion

The IntelliJ SDK code samples are worth adopting if you are writing an IntelliJ plugin and the documentation's prose has not told you what the code actually looks like, because each directory is a project you can run and edit rather than a fragment to copy. They are the wrong tool if you want a production plugin skeleton, because the samples are teaching artefacts with no publishing, signing or compatibility range work in them. Before you start, pick the sample closest to the feature you need, run it with the Gradle runIde task on a matching platform build, and read the plugin.xml documentation alongside it, because the plugin definition file is where the sample declares everything the platform needs to know.

Frequently asked questions

Official sources

1. Issues
2. JetBrains/intellij-sdk-code-samples on GitHub
3. License: Apache-2.0
4. Project website
5. README