Skip to main content

serverbox-onboarding

Orientation for working on ServerBox from source — bootstrapping the Flutter + Rust + Node development environment, running, testing and building the app and the ServerBox Monitor, and explaining how the project actually works (SSH vs monitor HTTP, the shared Rust parser, SQLite storage, Riverpod state). Use this whenever someone asks how to get the repo running, why a build fails, where to start contributing, or how some part of the code or its design works — including questions that never name the project outright, such as "how do I get this repo running", "pub get fails after cloning", "where does the status data come from", or a first-time contributor asking where to start. Using the app or deploying the Monitor on a server is the `serverbox-help` skill instead.

Source facts

Repository
lollipopkit/flutter_server_box
Last source activity
November 12, 2026 at 04:36
Detected SKILL.md language
English
Stars
8,995
Forks
578

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
4 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
serverbox-onboarding
description
Orientation for working on ServerBox from source — bootstrapping the Flutter + Rust + Node development environment, running, testing and building the app and the ServerBox Monitor, and explaining how the project actually works (SSH vs monitor HTTP, the shared Rust parser, SQLite storage, Riverpod state). Use this whenever someone asks how to get the repo running, why a build fails, where to start contributing, or how some part of the code or its design works — including questions that never name the project outright, such as "how do I get this repo running", "pub get fails after cloning", "where does the status data come from", or a first-time contributor asking where to start. Using the app or deploying the Monitor on a server is the `serverbox-help` skill instead.
# ServerBox onboarding ServerBox is a Flutter app (iOS, Android, macOS, Linux, Windows, watchOS) for managing Linux, BSD and Windows servers: status charts, SSH terminal, SFTP, containers, processes, systemd. The repository is a monorepo: | Path | What it is | |---|---| | `lib/` | The Flutter app | | `crates/sbm_parser` | Shared status parser — one source of truth for the command manifest and the parsing, used by the app over FFI and by the monitor | | `crates/sbm_ffi` | flutter_rust_bridge binding crate, built into the app by `hook/build.dart` | | `crates/sbm_native` | Native per-platform sampler, monitor only | | `monitor/` | ServerBox Monitor: a Rust program installed on a server, plus its Svelte panel | | `packages/` | Vendored Dart forks, each a submodule, referenced by path from `pubspec.yaml` | | `docs/` | The documentation site (Astro Starlight), English with a `zh/` mirror | A server can use **SSH, a Monitor's HTTP API, or both**. Each configured transport contributes its own capabilities; see `references/principles.md`. ## Work out which question this is first People arrive at this project from two directions, and the answers barely overlap. This skill is for working on it; someone *using* the app or running the Monitor on a server wants the `serverbox-help` skill, which is also what the app's own Agent is given. Read the one reference that matches, not all of them. | The person wants to | Read | |---|---| | Build and run the project from source, or contribute | `references/dev-setup.md` | | Understand how something works, or why it was built that way | `references/principles.md` | | Install or use the app, or deploy and configure the Monitor | the `serverbox-help` skill | Mixed asks are common and the wording rarely says which is which. "The terminal button disappeared" is the Monitor's capability model (`serverbox-help`), not a bug. "`flutter pub get` fails right after cloning" is almost always uninitialised submodules (`dev-setup.md`). When it is genuinely ambiguous, ask whether they are running ServerBox or working on it. ## The repository outranks this skill Versions, ports and command names drift; a skill file that quietly disagrees with the repo is worse than no skill. Inside a checkout, prefer these: | Question | Authoritative file | |---|---| | What commands exist | `make help` (the `Makefile`) | | Flutter / Dart minimum | `environment:` in `pubspec.yaml` | | Rust channel and shipped targets | `crates/sbm_ffi/rust-toolchain.toml` | | Node version | `monitor/frontend/.node-version` | | Every Monitor config key | `monitor/config.example.toml` | | Contribution rules and checks | `CONTRIBUTING.md` | | Working rules for agents | `CLAUDE.md`, `monitor/CLAUDE.md` | | User-facing documentation | `docs/src/content/docs/**` | Outside a checkout the reference files here are the fallback. Say so when you are answering from them — the numbers below were true when this was written and nothing keeps them current. `scripts/check-env.sh` reports what is installed against what the repo asks for, and changes nothing. Run it before diagnosing a build failure by hand; most first-run failures are one of the four things it checks. ## The commands that cover most of it ```sh make deps # flutter pub get make run # flutter run make gen # build_runner + gen-l10n — after touching any annotated model make analyze # flutter analyze lib test integration_test make test # flutter test cargo test --workspace # parser, native sampler, FFI, monitor make monitor-dev # Monitor API on :3770 + panel dev server on :3000 make build PLATFORM=<android|ios|macos|linux|windows> ``` Values as of writing: Flutter >= 3.50.0, Dart SDK >= 3.11.0, Rust pinned to 1.98.1 for the FFI crate, Node 24 for the monitor panel and the docs site. ## What costs people an afternoon Each of these has bitten someone. The reason matters more than the fix, because the symptom rarely names the cause. - **Initialise submodules before fetching Dart dependencies.** `packages/*` are path dependencies, so `flutter pub get` fails on a missing directory rather than on anything that mentions submodules: `git submodule update --init --recursive`. - **Rust is not optional, even for `flutter run`.** `hook/build.dart` compiles `crates/sbm_ffi` into every app build as a code asset. No Rust toolchain, no app. - **`flutter_rust_bridge` is pinned to the same prerelease in two files** — `pubspec.yaml` and `crates/sbm_ffi/Cargo.toml`. When they disagree, `RustLib.init` throws at startup and the message does not mention versions. - **Regenerate after changing an annotated model** (`freezed`, `json_serializable`, `riverpod`, hive): `make gen`. Never hand-edit `*.g.dart`, `*.freezed.dart` or anything under `lib/src/rust/`. - **Never run a formatter.** The formatting in this codebase is deliberate, and a reformat buries the actual change in noise. - **Do not start a second `flutter run`** when the user already has the app running from their IDE. Two debug builds compete for the same window and you end up inspecting an instance nobody is looking at. Hot reload through the dart MCP server instead (`CLAUDE.md` has the sequence). ## Answering "how does X work" The longer explanations live in `docs/src/content/docs/development/` and the `CLAUDE.md` files next to the code — read them rather than paraphrasing from memory. `references/principles.md` maps questions to the right files and notes the design decisions that explain common behavior, so you can find answers without repeating a broad search. When the answer is about code rather than design, read the code. The docs describe intent; `lib/data/provider/`, `lib/data/store/` and `monitor/src/api/` are what actually runs. ## Reference files | File | Covers | |---|---| | `references/dev-setup.md` | Toolchain bootstrap, the run/test/build loop, monitor development, and a symptom-to-cause table for first-run failures | | `references/principles.md` | How the app is put together and which document answers which question | | `scripts/check-env.sh` | Read-only environment check: toolchain versions, submodules, dependency state, FFI version parity |
View on GitHub