Roblox creator-docs: the documentation is a git repository

The published docs are built from this repository

This repository holds the source code for the creator documentation at create.roblox.com/docs, and the primary language is recorded as TypeScript, which reflects the tooling around the content rather than the content itself. The default branch is main, the last push was on 2026-10-20, and the project publishes no GitHub releases, because the deliverable is a website rather than a package.

The README says what is in there today, with a caveat that matters for contributors: currently the repository has guides, tutorials, educational content, and a read-only version of the Engine API reference.

That last phrase is the one to notice. The API reference is present as source, and the README says the files are provided so that you can view the source and use them in your own projects, but it also says in bold that they no longer accept pull requests on the reference yaml files. So a third of the visible documentation is deliberately closed to editing, and the editable surface is the guides and the tutorials.

For anyone who wants to file an issue rather than a pull request, the README routes them to the Roblox developer forums bug report page, which is a sensible split because an issue is usually about the content being wrong rather than about the text being wrong.

There is also a video linked for people unfamiliar with the GitHub contribution process, which tells you something about the expected audience for this repository.

Two licences: one for the prose and one for the tooling

The licence arrangement here is unusual and worth understanding before you contribute.

The repository's licence field is CC-BY-4.0, which is what you would expect for documentation, and the top-level listing has both a LICENSE file and a LICENSE-CODE file. The package.json, which describes the tooling rather than the words, records the licence as MIT.

So the split is: the documentation content is Creative Commons Attribution 4.0, and the code that builds and checks it is MIT. That is a sensible pairing. It means you can quote and translate a page with attribution, and you can take the checking scripts and reuse them without a licence negotiation.

The pull request agreement reinforces the same point from the contributor's side. You agree that the contribution was created in whole or in part by you and that you have the right to submit it under the terms of the repository's open source licences, that you understand the contribution and a record of it are public, maintained indefinitely, and may be redistributed under those terms, and that to the best of your knowledge all proposed changes are accurate.

The phrase maintained indefinitely and may be redistributed is the part that catches people out. A pull request to a Creative Commons documentation project is a grant of broad reuse rights, and it is worth reading before you click, even though the terms are not unusual for a volunteer documentation project.

Three document types, and the rule that decides which one to write

The documentation has three main document types, each with a different location and a different contract.

The guides are conceptual and task-based .md files in content/en-us. They teach you about a feature or a workflow without being overly prescriptive about the end result, they introduce concepts and features, and they cover the tasks you can accomplish using various tools or other approaches. The README also gives the practical advice that guides benefit massively from real-world use cases, images, code snippets and diagrams, and that most task-based content should include a numbered list.

The tutorials are .md files in content/en-us/tutorials. Compared with task-based guides, they are more self-contained and take you from nothing to something. That focus on creating something specific means they are typically much more prescriptive than guides, and they often touch multiple features and concepts at once, demonstrating the connections between tools and strategies.

The API reference is .yaml in content/en-us/reference, and it is the read-only one.

The rule that decides which one to write is given as an example pair, and it is the single most useful line in the README for a first-time contributor. The preference is for pages like Building User Interfaces over pages like Creating a Speedometer for a Racing Game. In other words, the test is whether the page applies to a wide variety of experiences and use cases, and a narrow, project-specific page is not wanted here.

The README is unusually direct about what that means in practice. Any addition has to fit within the larger whole, so even a long, accurate and well-written blog post or technical whitepaper might not have a home on the website. And if your contribution does not fit the categories or covers a particularly narrow subject, the advice is to post it to the developer forum instead.

The size of the change decides your workflow

Three contribution paths are documented, and they differ mostly in how much of the repository you have to touch.

For a simple change that touches a single file, the README recommends GitHub's web-based editor. The steps are: find the file in content/en-us and click Edit this file, click Fork this repository, make your changes and click Commit changes, give the change a descriptive commit message and click Propose changes, make sure the base repository is Roblox/creator-docs and the base branch is main, and then fill in the pull request details and create it. Six steps, no local clone, no tooling.

For larger changes that touch multiple files, the recommendation is github.dev, a more full-featured text editor based on Visual Studio Code that runs in the browser. You fork the repository, press the . key while browsing your fork to open github.dev, create a branch from the Source Control menu, find the files you want to update in content/en-us in the Explorer menu, commit and push, then go to github.com/Roblox/creator-docs, click Compare and pull request, verify the base repository and branch, and fill in the details.

The offline path exists but comes with a warning. The repository is extremely large, so the README recommends the online options whenever possible, and if you must work offline it asks you to set up Git and Git LFS, or install a client like GitHub Desktop, then fork, clone, branch, commit, push and open a pull request against main. The size of the repository is the reason the browser editor is the default, and the Git LFS requirement is the reason a plain clone is not.

In all three cases the target is the same, a pull request against the main branch of Roblox/creator-docs, and CONTRIBUTING.md is where the detailed version of these steps lives.

Keep the change small, and follow two style rules

The contribution basics section is where the review expectations are, and they are worth reading as a contract.

Try to limit your edits to one class or feature so that the pull request is easier to review. Bug fixes and smaller improvements have a higher likelihood of fast approval, while large guides often require significant back-and-forth before publication. That is a clear statement about how review capacity is spent, and it tells a first-time contributor to start small.

Formatting is handled by tooling. The README recommends text editors like github.dev that let you preview Markdown as you write, and the repository carries a .prettierrc.json and a .prettierignore, so the formatting of the content is machine-checked.

Prose has its own guide. For prose, follow the guidelines in STYLE.md, and for code samples use the Lua Style Guide. Two separate documents for two separate kinds of writing, which is a sensible division, because a page of explanation and a code sample fail in different ways.

There is also a neat trick for reviewing your own work. To view a page fully formatted as the maintainers see it on the main branch, replace the entire URL from content/ and before, and files with the basename index should have that name. In other words, the preview is a URL, and the naming convention for index files is fixed.

The governance files support all of this. There is a CODEOWNERS file, which decides who reviews what, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, and a .husky/ directory with a prepare script that installs the hooks, so the same checks run before a commit leaves your machine.

The npm scripts show what the project actually checks

The package.json is where the maintenance machinery of a documentation set becomes visible, and it is more than a formatter.

The content checks are npm run check, which runs tools/checks/main.ts, and npm run redirects, which runs tools/redirects/main.ts. Redirects matter more than they sound: a documentation set accumulates pages that move, and a repository that owns the redirect table owns the links, and the tool that keeps them honest has to be automated.

Formatting is Prettier, with a format script for the whole tree and a separate pair for content/en-us, so the content and the tooling can be formatted on their own schedule. The markdown linter is markdownlint-cli2 run over md and mdx files with the .markdownlint.json configuration and a fix flag. The test runner is Jest, invoked with NODE_OPTIONS=--experimental-vm-modules because the package is an ES module, with a jest.config.json at the root. Husky is installed by the prepare script, which is what runs the checks on commit.

The most interesting family is forum-doc-eval, which has a dozen subcommands: diagnose, open-prs, replay, restore-questions, search-ab and webprobe. The names describe a system that takes posts from the developer forum, evaluates them, opens pull requests, replays a run, restores questions and runs an A and B search experiment. That is a content pipeline rather than a documentation repository, and it explains why the primary language is TypeScript.

Alongside it there is an ai-review script that runs an AI editorial review over the content, and a docs-slack-bot. The engines field pins Node at ^22.10.0 and npm at ^10.9.0, which is a recent baseline for a repository that runs its checks in CI.

Where each kind of feedback should go

Putting the README's routing rules together gives a clear picture of how the documentation project is organised, and it is a good model for any open documentation set.

Text changes go to the repository. A single-file fix goes through the web editor, a multi-file change goes through github.dev, and a large offline change goes through Git with Git LFS. Every path ends in a pull request against main, and the review criteria are the same in each case.

Content that does not fit the documented categories goes to the developer forum, and the README repeats this twice, once for narrow subjects and once for specialised guides, with a link to a forum section for resources in both cases. So the answer to whether your topic belongs in the documentation is not a matter of taste, it is a test the README states, and the forum is the fallback rather than a rejection.

Bugs in the documentation go to the developer forum bug report page, again rather than to the repository's issue tracker, which the README reserves for pull request work.

What is left in the repository is the machinery: .env.default for the defaults of the toolchain, .gitattributes, .npmrc, .nvmrc, tsconfig.json, the .vscode/ directory, tools/ with the TypeScript sources, and content/ with the documentation itself. The last push was on 2026-10-20, so the tree is being worked on daily, which is what you would expect of the source of a platform's documentation.

Editorial conclusion

Adopt this repository as a contribution channel if you write Roblox tutorials or guides, because the guide and tutorial format is defined here and the review criteria are written down, which removes most of the guesswork from a first pull request. Do not expect to change the API reference, because the README says pull requests on the reference yaml files are no longer accepted, and do not pitch a narrow, project-specific page, because the stated preference is for content that applies to a wide variety of experiences, with specialised content routed to the developer forum instead. Before you open a pull request, read STYLE.md for prose and the Lua style guide for code samples, keep the change to one feature so it can be reviewed quickly, and run npm run check and npm run format:check locally, because those are the checks the project runs on every submission.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-4.0
3. README
4. Roblox/creator-docs on GitHub