Answering quickly to help unblock you right now - these can be worked into proper docs after the fact.

Do rules need to be compiled to JS before being usable?

It's generally best to pre-compile them, but you could also leverage ts-node/tsx to avoid that - just depends if you want the lint-time perf hit or not.

When I worked at Meta we used to use @babel/node to transpile our rules (written in flow) on the fly because there wasn't a good spot in the lint pipeline to do a build. We consumed it by adding require('@babel/node') to the plugin root index.js.
At Canva (where I work now) we build the rules to JS ahead of time because of the way the repo is organised.

Can the rule from the code snippet in the documentation be directly consumed in your eslint config, or does it need to be wrapped in a plugin?

Either - you can use the runtime rules setup if you would like because rules made with our tooling are just plain old lint rules (you'd probably want to pre-compile them unless you want users to run the lint like ts-node ./node_modules/.bin/eslint --rulesdir eslint_rules).
You can also create your own plugin package locally and consume that either as a local node module, or I believe you can also use the absolute path via require.resolve.

At both Meta and Canva we defined a separate plugin just because it allows better isolation of the codebases. At Meta we used a yarn link: dependency to install it and at Canva it installs the directory (yarn add ../my-custom-plugin IIRC?).

If you've got a multi-package monorepo style project you can also use yarn workspaces to do it - this is how we do it in this project - yarn creates the appropriate symlinks at install time and ESLint just sees our plugins as plain old node modules.

What tsconfig is recommended when compiling a rule?

Whatever you need to support the node version your repo uses, plus strict: true would be all we recommend as a baseline.

are there package naming recommendations on top of the naming instructions from eslint itself?

Nope - just ensure you follow ESLint's requirements and that's all you need to do. ESLint's requirements must be adhered to in order for ESLint's "name shortening" to work.

should typescript and @typescript-eslint/*** packages be part of your (peer/dev-)dependencies?

It depends what you use - if you use our utils, then you should add @typescript-eslint/utils as a dependency. Avoid peer deps - peer deps are something you should only really use if you're "plugging" in to the system or it's a hard requirement for the user but you don't want to control their version.

You'd want to have:

• a peer dep on TS (so that strict package managers won't error when you access TS)
• a peer dep on ESLint (to signal that you're "plugging in" to ESLint and also to signal what versions you support)
• and a full dep on our utils (if you use them)

I'm trying to view the documentation for custom rules but the page seems to be broken. https://typescript-eslint.io/custom-rules

The page has moved
https://typescript-eslint.io/developers/custom-rules