intellij-sdk-docs: the source repository behind the IntelliJ Platform SDK documentation

A documentation site with its source in Git

The IntelliJ Platform SDK Documentation repository is the source for the documentation site at plugins.jetbrains.com/docs/intellij. The README calls it the repository for the site and links the published version from the header.

The primary language in the repository metadata is Markdown, which is the obvious choice for a documentation source tree and is a useful signal about what a contributor is expected to edit.

The README is deliberately short. It carries an official JetBrains project badge and links to the JetBrains Platform blog on Bluesky, the platform account on X, the platform forum and the code samples workflow, and then it has two sections: Feedback, which asks people to report content inconsistencies, outdated materials and cosmetic issues through the channels listed in the Getting Help page, and Contributing, which points to the contributing steps.

That brevity is the main thing to understand about this project. It is infrastructure for a large body of documentation rather than an explainer, so the useful information is in the layout and in the automation, not in the README.

The repository is not archived, the last push was on 2026-10-19, the licence is Apache-2.0 with a `LICENSE.txt` file at the root, and there are no GitHub releases, which is unsurprising for a documentation source that is published as a website rather than as an artefact.

The directory layout is the table of contents

The top level of the repository is a documentation project's working set, and reading the file names tells you more about how the content is organised than the README does.

There is a `topics/` directory, which is where a Writerside project keeps its topic-structured pages, and a `reference_guide/` directory, which is the reference material. Between them those two directories are the documentation itself.

Then there is `code_samples/`, the sample projects the documentation refers to, and `images/`, the diagrams and screenshots. There is a `cfg/` directory for configuration, and an `intellij-sdk-docs.iml` file, which is the IntelliJ IDEA module file, so the project opens in the IDE that the documentation is about.

The `.idea/` directory is present as well, so the project ships with IDE settings, and there is an `.editorconfig` and a `.gitattributes`.

Then there are the four root files that are unusual enough to be worth naming: `c.list`, `v.list`, `labels.list` and `ijs.tree`. Their purpose is not explained in the README, and the names suggest they are auxiliary data files used by the documentation build rather than content. A `labels.list` next to a `c.list` and a `v.list` in a Writerside project is most likely a set of term or label definitions, and `ijs.tree` is likely a navigation or hierarchy tree, but the README does not say, and a reader should not assume more than the names support.

`writerside.cfg` sits at the root as well, the configuration file for the JetBrains Writerside toolchain that builds the site. A `.gitignore`, a `CODE_OF_CONDUCT.md`, a `CONTRIBUTING.md` and a `README.md` complete the set.

The code samples are built in continuous integration

One workflow is called out in the README header: the code samples workflow, with a badge pointing at the GitHub Actions run for the `code-samples.yml` workflow on the main branch.

That is a meaningful piece of infrastructure for a documentation project. A code sample in documentation is a promise that the code works, and the usual failure mode of technical documentation is that the sample compiles in the author's IDE and nowhere else. A workflow that builds the samples on every change turns that promise into something checked.

The badge is in the README rather than buried in the `.github/` directory, which suggests the maintainers consider sample correctness part of the documentation's contract rather than an internal detail.

There is a second repository involved, and the README points to it in a tip. The code samples can also be found in the IntelliJ SDK Code Samples mirror repository. So the samples live in one place and are mirrored elsewhere, and the tip exists for readers who want the samples without the documentation around them.

For a reader, that mirror is the practical starting point. Cloning the documentation repository gets you prose with samples embedded in it, while the mirror gives you a buildable set of projects that stands on its own.

Feedback and contribution both go through the published site

The README does not describe a GitHub-based contribution flow. It points elsewhere for both reporting problems and contributing.

For defects, the instruction is to report content inconsistencies, outdated materials, cosmetic issues and other defects using the channels listed in the Getting Help page. That page is part of the published documentation rather than the repository's own `CONTRIBUTING.md`.

For changes, the instruction is to follow the steps outlined in the Contributing page, which lives at the path intellij-sdk-docs-original-contributing in the published documentation. The name of that page, with `original` in it, is a small piece of history: it suggests the page was written for an earlier arrangement of the documentation and kept in place when the site was reorganised.

The repository does have its own `CONTRIBUTING.md` and a `CODE_OF_CONDUCT.md` at the root, alongside the `.github/` directory, so the conventional governance files are there. But the README routes contributors to the website, which means the canonical contribution instructions are outside version control in this repository.

That is an unusual arrangement, and it has a practical consequence. A contributor who wants to know the house rules has to read the live documentation rather than the repository, and if the two ever disagree, the live site wins. It also means the documentation is written in the same place it is read, which is a defensible choice for a vendor whose documentation is a product surface.

Where intellij-sdk-docs is the wrong place to look

The first wrong case is a developer looking for the SDK itself. This repository contains no Java, no Kotlin and no Gradle plugin. The IntelliJ Platform, its APIs, the plugin development tooling and the runtime are all elsewhere, and what you find here is prose about them.

The second wrong case is a team that wants to consume the documentation as data. The published artefact is a website. There is no package, no structured export and no API described in the README, so if you want to search the documentation from a tool, index it from the site or ask JetBrains for something else.

The third wrong case is a contributor who wants to fix a code sample and nothing else. The samples are mirrored in a separate repository, and the workflow builds them, so a change to a sample belongs in whichever repository the sample is sourced from, and the documentation repository is where the prose that references it lives. Getting that backwards produces a mismatch between the two trees.

The fourth wrong case is expecting the README to tell you what the documentation covers. It does not. The repository is a large body of content spread across `topics/` and `reference_guide/`, and the way to find out what is in it is to browse the published site, or to read the tree.

What the repository is good for is narrow and real: it is where the IntelliJ Platform documentation is written, where the samples are built, and where a correction to the platform documentation actually lands.

Editorial conclusion

intellij-sdk-docs suits a plugin developer who wants to read the platform documentation at its source, contribute a correction, or run the code samples locally, and it is the place to check how the documentation itself is maintained. It does not suit someone looking for the IntelliJ Platform SDK itself, the APIs, the Gradle plugin or the runtime, none of which live here, and it does not suit a project that wants to consume the documentation programmatically, since the published artefact is a website rather than a package. Before using it, read the pages under `topics/` and `reference_guide/` for the content itself, follow the contributing steps for anything you want to change, and remember that the code samples are also mirrored in the separate IntelliJ SDK Code Samples repository, which is the better starting point if you only want to run them.

Frequently asked questions

Official sources

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