pixtuoid: a Rust terminal office whose feature table is generated from JSON

Three of the README's most read sections are generated from JSON

The install block, the feature table and the supported-tools table all carry a comment saying the same thing: generated from a JSON file under site/src by a just recipe, and the file to edit is the JSON, not this block. The two channels in that block are:

brew install pixtuoid
npm install -g pixtuoid

Homebrew is labelled for Linux, macOS and WSL2, and npm for any OS, which is the practical way to reach Windows today. Cargo installs, prebuilt binaries and Debian packages exist but are listed on the site rather than in the page, and after installation the command is simply pixtuoid. The three generated blocks are also the three that change most often, as tools land and features ship, so generating them is defensible. The justfile explains the other half: one recipe group regenerates committed artifacts and another checks them, so a stale generated block in a commit is a failing check rather than a documentation bug nobody notices. The consequence for a reader is simple, an edit to those tables is overwritten on the next generation run.

Five crates in the workspace, and only two with a public API contract

The Cargo workspace lists five members, a core crate, a scene crate, the binary crate, a hook crate and a web crate, all sharing version 0.19.0. The interesting part is what the lint configuration does with them. The workspace deliberately does not set the missing-docs lint, and the comment says why: it is a public-API gate, so it lives inside the two published crates rather than across the workspace, scoped the same way as the semver checks and the API surface gate. The justfile then names the same two crates as the only ones whose public API is a contract, the binary library target excluded, and single-sources that fact so the two gates over it cannot drift from each other. The rest is conservative by default: unreachable-pub is warned on so a layer-internal item cannot leak as crate API, and rustdoc's intra-doc link lints are denied because they only fire in a doc build.

Windows support is marked experimental and unsigned

The supported-tools table has two rows with a full OS column, Claude Code and Codex CLI, and both Windows entries carry an asterisk. The footnote under the table defines the asterisk as experimental, with limited testing and unsigned binaries. Everything else, fourteen further command line agents including Copilot CLI, Cursor CLI, opencode, Grok Build and the Kimi Code CLI, appears in a single paragraph of also supported with no OS column at all, so the platform story for most of that list lives on the site rather than in the repository. Adding one is a code change rather than a documentation change: implement the Source trait, or, for a tool that only speaks hooks, a hook-only path. The README cuts off in the middle of that sentence, which is where the extension point is defined.

The hook shim cannot block an agent, and the release profile aborts on panic

One row of the feature table is the reason a visualiser is safe to wire into a coding tool: the hook pixtuoid installs always exits zero, so even a stuck office cannot block the agent it is watching. The wiring is visible in two places. The Sources panel flags a source whose hooks are connected but broken, and pixtuoid doctor produces the full health report, so a failure is reported rather than silent. The release profile explains why the shim has to be a separate small program: it sets panic to abort, so a fault in the office process ends it instead of unwinding through the caller, and with link-time optimisation, one codegen unit and debuginfo stripped from the release binary. Hook execution, then, is the one integration point designed around the assumption that the visualiser will sometimes be broken, and the doctor command exists to make that recoverable without touching the agent.

The Rust floor is 1.98 and the toolchain is pinned in the repository

The workspace asks for edition 2024 and a rust-version of 1.98, with a rust-toolchain.toml at the repository root, so a contributor gets one toolchain rather than whatever is newest on their machine. The release profile is tuned like a shipped binary rather than a developer build: link-time optimisation on, one codegen unit, debuginfo stripped, panics aborting. The comments in the lint section read like someone arguing with past decisions, including the note that an allow outlives the warning it silenced and an expect fails once its lint stops firing, which is why allow attributes are warned about both with and without a reason. Clippy runs in CI with warnings denied, so those workspace warnings are hard gates rather than suggestions, and the site lives in the same repository as an Astro project with its own build.

Recipe arguments reach the shell as $1, not as just parameters

The task runner file is the most opinionated thing in the repository, and it explains itself. Recipes are grouped by intent into rust, site, gen, release and meta, and the git hooks and the workflow files call those recipes rather than restating the commands, so a command lives in one place. Every recipe runs under the same shell, bash with errexit, nounset, pipefail and pipefail errors surfaced, because Git Bash is already present on the Windows runners and one dialect is cheaper to maintain than two. The argument rule is the interesting one: recipe parameters are passed as positional shell arguments and never interpolated into recipe text, because an interpolated value is re-parsed as shell code, so a quote or a command substitution inside an argument would execute. One exception is documented, the workspace version, which is read rather than passed.

The colours come from the working directory, so the room reads as an org chart

The visual encoding is derived rather than assigned, which is what makes a glance useful. Each agent's shirt and trousers take their colours from the working directory, so every session on the same repository looks the same and the office resembles an org chart, while hair and skin vary per agent and there are sixteen curated outfits to keep two neighbours apart. State is on the desk as well: characters type while working, raise a question mark when a permission prompt needs a human, doze when finished, and walk A-star routed paths between desks. The monitor glow reports the tool in use, blue for Edit, orange for Bash, cyan for Read, and paper stacks accumulate as tokens are spent through tiers at 250K, 2M and 16M, with a larger spend dropping a fresh sheet and a hover showing the exact total. Decoration is separated from state elsewhere: a cat or dog per floor sleeps near idle agents, and a lobster wanders when an OpenClaw gateway is live, its movement indicating health.

An agent-focused Rust repository with the agent tooling checked in

The top level tells you what kind of project this is. Alongside the Rust workspace there are agent directories, a Claude directory, a Codex directory and a general config directory, an AGENTS.md, a REVIEW.md and a SECURITY.md, plus a policy directory, a gitleaks configuration and a gitleaks identity file, a cargo-deny configuration, clippy and codecov configuration, release-plz, a mergify configuration, and a requirements-dev.txt in a project that has no Python code of its own. That last one is a loose end worth asking about, since the site build and the fixture tooling are where a Python dependency would come from. Shipping the hook configuration in the same repository as the tool that installs it is a deliberate choice, and it is the kind of choice that makes a reviewer read the hook shim twice.

Editorial conclusion

pixtuoid is a presentation layer with an unusual amount of discipline behind it, and the discipline is in the repository rather than in the demo: generated artifacts that CI checks for drift, lint rules chosen for what they catch, a panic-abort release profile and a hook shim that cannot block your agent. Judge it on the integration, not the art. Adding a tool means implementing a Source trait or a hook-only path, Windows support is marked experimental and unsigned, and the token meter is the one number on screen that comes from real usage. If your workflow is several agents across several repos, the org-chart colouring is the part that earns the install.

Frequently asked questions

Official sources

1. IvanWng97/pixtuoid on GitHub
2. License: MIT
3. Project website
4. README
5. Releases