@litfamily/litgrok 1.0.0

package/.grok/skills/lsp-setup/references/csharp/README.md

@@ -0,0 +1,64 @@
+# C# — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `csharp-ls`
+- **Extensions:** `.cs`
+- **Install hint:** `dotnet tool install -g csharp-ls`
+
+## Install
+
+Requires the **.NET SDK**. Install the tool globally:
+
+- **macOS:** `dotnet tool install -g csharp-ls`
+- **Linux:** `dotnet tool install -g csharp-ls`
+- **Windows:** `dotnet tool install -g csharp-ls`
+
+Global .NET tools land in `~/.dotnet/tools` — ensure that directory is on PATH (Windows: `%USERPROFILE%\.dotnet\tools`).
+
+Confirm it resolves:
+
+```bash
+command -v csharp-ls
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+## Razor / Blazor
+
+Razor and Blazor files use a separate server, `roslyn-language-server --stdio`.
+
+Install it (requires **v5.8.0+**; see [dotnet/razor](https://github.com/dotnet/razor)):
+
+```bash
+dotnet tool install -g roslyn-language-server --prerelease
+command -v roslyn-language-server
+```
+
+## Alternatives
+
+**OmniSharp** — legacy C# language server. Still works but is being superseded by
+the Roslyn-based servers; prefer `csharp-ls` / `roslyn-language-server`.
+
+## Troubleshooting
+
+- **PATH:** `csharp-ls` / `roslyn-language-server` on PATH (`~/.dotnet/tools`); reopen shell after install.
+- **No .NET SDK:** install the SDK (not just the runtime) before installing the tool.
+- **No symbols:** run `dotnet restore`; an unrestored solution yields empty results.
+- **Razor needs v5.8.0+:** older `roslyn-language-server` builds lack the `--stdio` Razor support — install with `--prerelease`.
+
+## Verify
+
+```bash
+command -v csharp-ls
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.

package/.grok/skills/lsp-setup/references/dart/README.md

@@ -0,0 +1,48 @@
+# Dart — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `dart language-server --lsp`
+- **Extensions:** `.dart`
+- **Install hint:** `Included with the Dart/Flutter SDK`
+
+## Install
+
+The language server ships inside the Dart SDK (and the Flutter SDK, which bundles Dart). There is no separate package to install — just put `dart` (or `flutter`) on PATH.
+
+- **macOS:** `brew install dart` (or install Flutter and use its bundled `dart`)
+- **Linux:** install the Dart SDK from your package manager / `https://dart.dev/get-dart`, or install Flutter
+- **Windows:** install the Dart SDK or Flutter SDK and add its `bin` to PATH
+
+Confirm it resolves:
+
+```bash
+command -v dart
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+## Alternatives
+
+None.
+
+## Troubleshooting
+- **PATH:** `dart` must be on PATH; reopen the shell after installing the SDK. Flutter users: ensure `<flutter>/bin/cache/dart-sdk/bin` or the Flutter `bin` is exported.
+- **Flutter vs Dart:** if you only have Flutter installed, the bundled `dart` works — make sure Flutter's `bin` is on PATH rather than relying on a separate Dart install.
+- **SDK out of date:** run `dart --version` / `flutter upgrade` if analysis behaves oddly on newer language features.
+
+## Verify
+
+```bash
+command -v dart
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.

package/.grok/skills/lsp-setup/references/elixir/README.md

@@ -0,0 +1,51 @@
+# Elixir — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `elixir-ls`
+- **Extensions:** `.ex .exs`
+- **Install hint:** `https://github.com/elixir-lsp/elixir-ls`
+
+## Install
+
+ElixirLS needs Erlang/OTP and Elixir installed first. Build the release from
+`https://github.com/elixir-lsp/elixir-ls` and put the `elixir-ls` launcher script on PATH.
+
+- **macOS:** `brew install elixir-ls` (Homebrew provides the launcher), or build the release manually
+- **Linux:** clone elixir-ls, run `mix deps.get && mix compile && mix elixir_ls.release2 -o release`, then add `release/` to PATH
+- **Windows:** build the release and add the `release` dir (use the `.bat` launcher) to PATH
+
+Confirm it resolves:
+
+```bash
+command -v elixir-ls
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+## Alternatives
+
+- **lexical**: launch it as `lexical` — fast, modern alternative LSP.
+- **next-ls**: launch it as `nextls --stdio` — from the elixir-tools project.
+
+## Troubleshooting
+- **PATH:** `elixir-ls` must be on PATH; reopen the shell after install.
+- **asdf users:** the launcher is a shim — after `asdf install`, run `asdf reshim elixir` so the `elixir-ls` shim resolves, and ensure the Erlang/Elixir versions match the build.
+- **First start is slow:** ElixirLS compiles your deps on first run; initial diagnostics can take a while on large projects.
+- **OTP mismatch:** build elixir-ls with the same Erlang/Elixir versions you use for the project to avoid bytecode errors.
+
+## Verify
+
+```bash
+command -v elixir-ls
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.

package/.grok/skills/lsp-setup/references/go/README.md

@@ -0,0 +1,53 @@
+# Go — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `gopls`
+- **Extensions:** `.go`
+- **Install hint:** `go install golang.org/x/tools/gopls@latest`
+
+## Install
+
+- **macOS:** `go install golang.org/x/tools/gopls@latest` (or `brew install gopls`)
+- **Linux:** `go install golang.org/x/tools/gopls@latest`
+- **Windows:** `go install golang.org/x/tools/gopls@latest`
+
+Requires the Go toolchain. `go install` drops the binary in `$GOPATH/bin`
+(default `~/go/bin`) — that directory must be on PATH.
+
+```bash
+export PATH="$PATH:$(go env GOPATH)/bin"
+```
+
+Confirm it resolves:
+
+```bash
+command -v gopls
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+## Alternatives
+
+None — `gopls` is the official and de facto sole Go language server.
+
+## Troubleshooting
+- **PATH:** `gopls` must be on PATH; ensure `$(go env GOPATH)/bin` is exported, then reopen the shell.
+- **No diagnostics / "no required module":** open the directory containing `go.mod` as the workspace root. Outside a module, gopls degrades. Run `go mod tidy` if dependencies are unresolved.
+- **Stale toolchain:** reinstall with `go install golang.org/x/tools/gopls@latest` after upgrading Go.
+
+## Verify
+
+```bash
+command -v gopls
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.

package/.grok/skills/lsp-setup/references/haskell/README.md

@@ -0,0 +1,57 @@
+# Haskell — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `haskell-language-server-wrapper --lsp`
+- **Extensions:** `.hs .lhs`
+- **Install hint:** `ghcup install hls`
+
+The `-wrapper` binary detects your project's GHC version and dispatches to the matching HLS build.
+
+## Install
+
+- **macOS:** `ghcup install hls` (install ghcup via `brew install ghcup` or the official script)
+- **Linux:** `ghcup install hls` (ghcup script from https://www.haskell.org/ghcup/)
+- **Windows:** `ghcup install hls` (ghcup is installed via the Windows installer / PowerShell bootstrap)
+
+HLS needs a working GHC plus Cabal and/or Stack. Install a matching toolchain first:
+
+```bash
+ghcup install ghc
+ghcup install cabal
+```
+
+Confirm it resolves:
+
+```bash
+command -v haskell-language-server-wrapper
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+## Alternatives
+
+- `ghcide` (the core HLS engine, standalone) — largely superseded by HLS.
+- `hlint` standalone for lint-only checks; `ormolu`/`fourmolu` for formatting.
+
+## Troubleshooting
+- **PATH:** `haskell-language-server-wrapper` on PATH; reopen shell after `ghcup install`.
+- **GHC mismatch:** the installed HLS must support your project's GHC version — run `ghcup install hls` for that GHC, or align GHC to a supported one.
+- **No cradle:** multi-package repos may need a `hie.yaml`; generate one with `gen-hie > hie.yaml`.
+- **Slow first load:** HLS compiles dependencies on first open; let it finish indexing.
+
+## Verify
+
+```bash
+command -v haskell-language-server-wrapper
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.

package/.grok/skills/lsp-setup/references/java/README.md

@@ -0,0 +1,55 @@
+# Java — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `jdtls`
+- **Extensions:** `.java`
+- **Install hint:** `https://github.com/eclipse-jdtls/eclipse.jdt.ls`
+
+## Install
+
+- **macOS:** `brew install jdtls`
+- **Linux:** Download from [eclipse-jdtls/eclipse.jdt.ls](https://github.com/eclipse-jdtls/eclipse.jdt.ls) releases, extract, and wrap the launcher as `jdtls` on PATH (some distros package it as `jdtls`/`jdt-language-server`).
+- **Windows:** Download the release archive and add the `jdtls` launcher (`bin/jdtls.bat` or the Python wrapper) to PATH.
+
+Requires a **JDK 17+** to run the language server itself (the project may target an older Java version).
+
+Confirm it resolves:
+
+```bash
+command -v jdtls
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+Most settings (runtimes, format, import order) come from `settings.java.*`
+defaults and work for Maven/Gradle projects with a standard layout.
+
+## Alternatives
+
+**No mainstream alternative.** `jdtls` (Eclipse JDT Language Server) is the
+de-facto standard and powers the official VS Code Java extension.
+
+## Troubleshooting
+
+- **PATH:** `jdtls` on PATH; reopen shell after install.
+- **No JDK found:** server exits immediately — set `JAVA_HOME` to a JDK 17+.
+- **Slow / no completions at first:** the initial classpath index can take a minute or more on large Maven/Gradle projects; wait for it to finish.
+- **Stale state:** delete the jdtls workspace data dir to force a clean re-index if results go wrong after big dependency changes.
+- **Build tool required:** keep `pom.xml` / `build.gradle` valid; a broken build descriptor breaks symbol resolution.
+
+## Verify
+
+```bash
+command -v jdtls
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.

package/.grok/skills/lsp-setup/references/julia/README.md

@@ -0,0 +1,56 @@
+# Julia — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `julia --startup-file=no --history-file=no -e "using LanguageServer; runserver()"`
+- **Extensions:** `.jl`
+- **Install hint:** `julia -e 'using Pkg; Pkg.add("LanguageServer")'`
+
+The PATH executable is `julia`; LanguageServer.jl is launched through the `-e` snippet, not as its own binary.
+
+## Install
+
+Install Julia (juliaup recommended), then add the `LanguageServer` package:
+
+- **macOS:** `brew install juliaup && juliaup add release`
+- **Linux:** `curl -fsSL https://install.julialang.org | sh` (installs juliaup)
+- **Windows:** `winget install julia -s msstore` (installs juliaup)
+
+Then add the package — ideally into a shared `@lsp` environment so it is not tied to one project:
+
+```bash
+julia --project=@lsp -e 'using Pkg; Pkg.add("LanguageServer")'
+```
+
+Confirm Julia resolves (the LSP binary IS `julia`):
+
+```bash
+command -v julia
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+## Alternatives
+
+- The VS Code Julia extension bundles the same LanguageServer.jl server.
+
+## Troubleshooting
+- **PATH:** `julia` on PATH (not a `julials` binary); reopen shell after juliaup install.
+- **First run precompiles — be patient:** the initial launch compiles LanguageServer.jl and may take minutes with no output; do not kill it. Subsequent starts are fast.
+- **Package not found:** `LanguageServer` must be installed in the environment the server runs in (e.g. `@lsp`); add it there and set `JULIA_PROJECT`.
+
+## Verify
+
+```bash
+command -v julia
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.

package/.grok/skills/lsp-setup/references/kotlin/README.md

@@ -0,0 +1,58 @@
+# Kotlin — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `kotlin-lsp`
+- **Extensions:** `.kt .kts`
+- **Install hint:** `https://github.com/Kotlin/kotlin-lsp`
+
+## Install
+
+The official **JetBrains Kotlin LSP** is pre-release. Download a build from the [Kotlin/kotlin-lsp](https://github.com/Kotlin/kotlin-lsp) releases and put the `kotlin-lsp` launcher on PATH.
+
+- **macOS:** Download the release archive, extract, then symlink the launcher: `ln -s /path/to/kotlin-lsp/kotlin-lsp.sh /usr/local/bin/kotlin-lsp`
+- **Linux:** Same as macOS — extract the release and place/symlink `kotlin-lsp` on PATH.
+- **Windows:** Extract the release and add the directory containing `kotlin-lsp.bat` to PATH (invoke as `kotlin-lsp`).
+
+Requires a **JDK** on the machine to run the server.
+
+Confirm it resolves:
+
+```bash
+command -v kotlin-lsp
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+The server resolves classpath from Gradle/Maven; keep the build descriptor
+importable.
+
+## Alternatives
+
+**`fwcd/kotlin-language-server`** — older community server. Still usable but less
+actively maintained than the official JetBrains one; launch its own launcher
+instead if you prefer it.
+
+## Troubleshooting
+
+- **PATH:** `kotlin-lsp` on PATH; reopen shell after install.
+- **Pre-release churn:** the JetBrains server is early; pin a known-good release and expect occasional breakage.
+- **No JDK:** server fails to start — install a JDK and/or set `JAVA_HOME`.
+- **Slow first import:** Gradle resolution on first open can be slow on large projects; let it complete.
+- **`.kts` scripts:** build/script files resolve more slowly than `.kt` sources; this is expected.
+
+## Verify
+
+```bash
+command -v kotlin-lsp
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.

package/.grok/skills/lsp-setup/references/lua/README.md

@@ -0,0 +1,48 @@
+# Lua — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `lua-language-server`
+- **Extensions:** `.lua`
+- **Install hint:** `https://github.com/LuaLS/lua-language-server`
+
+## Install
+
+See `https://github.com/LuaLS/lua-language-server`.
+
+- **macOS:** `brew install lua-language-server`
+- **Linux:** download a release from GitHub, or `pacman -S lua-language-server` (Arch) / AUR
+- **Windows:** download a release from the GitHub releases page and add its `bin` to PATH
+
+Confirm it resolves:
+
+```bash
+command -v lua-language-server
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+## Alternatives
+
+None.
+
+## Troubleshooting
+- **PATH:** `lua-language-server` must be on PATH; reopen the shell after install.
+- **Undefined `vim` global:** add `vim` to `diagnostics.globals` and set `workspace.library` in `.luarc.json` (see above) for Neovim work.
+- **Wrong runtime version:** set `runtime.version` (`LuaJIT`, `Lua 5.4`, etc.) to match your interpreter, or stdlib functions report as undefined.
+
+## Verify
+
+```bash
+command -v lua-language-server
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.

package/.grok/skills/lsp-setup/references/php/README.md

@@ -0,0 +1,49 @@
+# PHP — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `intelephense --stdio`
+- **Extensions:** `.php`
+- **Install hint:** `npm install -g intelephense`
+
+## Install
+
+Intelephense is a Node package, so Node.js (and npm) must be installed first.
+
+- **macOS:** `npm install -g intelephense`
+- **Linux:** `npm install -g intelephense`
+- **Windows:** `npm install -g intelephense`
+
+Confirm it resolves:
+
+```bash
+command -v intelephense
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+## Alternatives
+
+**phpactor** — pure-PHP, no Node dependency. Launch it as
+`phpactor language-server`.
+
+## Troubleshooting
+- **PATH:** `intelephense` must be on PATH; reopen the shell after a global npm install. If missing, check `npm bin -g` is on PATH.
+- **No Node:** Intelephense fails to start without Node.js. Install Node, then reinstall.
+- **Wrong PHP version inference:** set `intelephense.environment.phpVersion` (via your editor's init options) to match your project.
+
+## Verify
+
+```bash
+command -v intelephense
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.

package/.grok/skills/lsp-setup/references/python/README.md

@@ -0,0 +1,60 @@
+# Python — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `basedpyright-langserver --stdio`
+- **Extensions:** `.py .pyi`
+- **Install hint:** `pip install basedpyright`
+
+## Install
+
+- **macOS:** `pip install basedpyright` (or `uv tool install basedpyright`)
+- **Linux:** `pip install basedpyright` (or `uv tool install basedpyright`)
+- **Windows:** `pip install basedpyright`
+
+Prefer `uv tool install basedpyright` when the project uses uv — it keeps the
+server isolated from project venvs and always on PATH.
+
+Confirm it resolves:
+
+```bash
+command -v basedpyright-langserver
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+## Choosing a server
+
+Type checkers and the linter serve different roles. Run a type server, and
+optionally `ruff` ALONGSIDE it (not instead). Launch the server accordingly:
+
+| server launch                        | install                | role                                    |
+| ------------------------------------ | ---------------------- | --------------------------------------- |
+| `["basedpyright-langserver", "--stdio"]` | `pip install basedpyright` | strictest types, **default**       |
+| `["pyright-langserver", "--stdio"]`  | `pip install pyright`  | upstream Microsoft type checker         |
+| `["ty", "server"]`                   | `pip install ty`       | Astral, very fast, pre-1.0/experimental |
+| `["ruff", "server"]`                 | `pip install ruff`     | lint + format only, complements a type server |
+
+Recommended: keep `basedpyright` as the Python server. `ruff` does not
+type-check, so if you want lint diagnostics too run it as a separate tool rather
+than replacing the type server.
+
+## Troubleshooting
+- **PATH:** `basedpyright-langserver` must be on PATH; reopen shell after install. `uv tool install` writes to `~/.local/bin`.
+- **Wrong interpreter / missing imports:** the server must see the project venv. Set `python.pythonPath` / `venvPath` in `pyrightconfig.json`, or activate the venv before launching.
+
+## Verify
+
+```bash
+command -v basedpyright-langserver
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.

package/.grok/skills/lsp-setup/references/ruby/README.md

@@ -0,0 +1,53 @@
+# Ruby — LSP setup (Grok Build / LitGrok)
+
+- **Recommended server:** `rubocop --lsp`
+- **Extensions:** `.rb .rake .gemspec .ru`
+- **Install hint:** `gem install rubocop`
+
+> **Note:** the executable invoked is **`rubocop`** (`rubocop --lsp`). RuboCop must be installed: `gem install rubocop`.
+
+## Install
+
+- **macOS:** `gem install rubocop`
+- **Linux:** `gem install rubocop`
+- **Windows:** `gem install rubocop`
+
+In a Bundler project, prefer adding `rubocop` to the `Gemfile` and running via `bundle exec`.
+
+Confirm it resolves (check `rubocop`, since that is what runs):
+
+```bash
+command -v rubocop
+```
+
+## Server settings
+
+Grok Build documents no project language-server schema, and LitGrok ships no server
+configuration: the only documented code-intelligence surface is the built-in tool
+behind `GROK_LSP_TOOLS=1` / `[features] lsp_tools`, which is off by default (see the
+`lsp` skill). Installing the server binary on PATH is the whole setup this reference
+can vouch for. Do not add a server entry to `.grok/config.toml`; that key is not a
+documented Grok Build surface.
+
+## Alternatives
+
+- **Shopify `ruby-lsp`** — the standalone `ruby-lsp` executable, richer navigation than RuboCop alone. launch it as `ruby-lsp`.
+- **`solargraph`** — older completion/type server; install with `gem install solargraph`, launch it as `solargraph stdio`.
+
+## Troubleshooting
+
+- **PATH:** `rubocop` on PATH (that is the invoked binary); reopen shell after install.
+- **`rubocop` not found:** install RuboCop with `gem install rubocop`.
+- **Bundler mismatch:** if the project pins RuboCop in its `Gemfile`, run inside the bundle so versions match.
+- **No diagnostics:** check `.rubocop.yml` is valid and not disabling everything.
+
+## Verify
+
+```bash
+command -v rubocop
+```
+
+A resolving executable is the only claim this reference makes. Whether Grok Build's
+built-in code-intelligence tool picks the server up is undocumented; confirm tool
+visibility inside the session as the `lsp` skill describes, and fall back to the
+project's own checks when it is absent.