@xgent-ai/skills 0.1.0 → 0.3.0

package/skills/working-with-mbx/references/cookbook/fork-prs.md

@@ -0,0 +1,82 @@
+CI with fork pull requests
+
+CI with fork pull requests [​](#ci-with-fork-pull-requests)
+
+Open-source repositories take pull requests from forks, and forks change what a CI run may hold: GitHub withholds secrets and OIDC tokens from fork-triggered runs, so a fork's job cannot authenticate to a [cache server](https://mr-boxington.jdx.dev/remote-cache). mbx's own [write policy](https://mr-boxington.jdx.dev/remote-cache#read-and-write-policy) already keeps every pull request read-only. The remaining question is which backend each run should use.
+
+If all jobs can use GitHub Actions cache, the [default action setup](https://mr-boxington.jdx.dev/github-action) already supports fork pull requests. Use this recipe when trusted runs also need a private cache server: fork pull requests use the GitHub backend instead.
+
+Protect `main` before expecting remote writes. Configure the server's read and write grants separately; client-side policy does not authorize access.
+
+yaml
+
+```
+name: ci
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+permissions:
+  contents: read
+  id-token: write # GitHub withholds OIDC from fork runs on its own
+
+env:
+  # A fork PR cannot mint an OIDC token, so it uses the GitHub backend.
+  MBX_BACKEND: >-
+    ${{ github.event_name == 'pull_request'
+        && github.event.pull_request.head.repo.full_name != github.repository
+        && 'github' || 'server' }}
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+      # Optional: a push to main also saves the local store into GitHub
+      # Actions cache, so fork PRs restore warm despite never reaching the
+      # server. The github backend only saves from the default branch, so
+      # the event guard is all this step needs.
+      - name: Mirror the store for fork pull requests
+        if: github.event_name == 'push'
+        uses: jdx/mr-boxington-action@v1
+        with:
+          backend: github
+      - uses: jdx/mr-boxington-action@v1
+        with:
+          backend: ${{ env.MBX_BACKEND }}
+          server-url: https://cache.example.com
+          namespace: acme/backend
+          oidc-audience: mbx-cache
+      - run: mbx test --workspace
+```
+
+## How it works [​](#how-it-works)
+
+- The backend expression treats pushes and same-repository pull requests as trusted, since both come from people with push access, and everything else as a fork. Fork runs get the [GitHub Actions cache backend](https://mr-boxington.jdx.dev/github-action), which restores without credentials and never lets a pull request save.
+- `id-token: write` is safe to declare at the workflow level. GitHub refuses to issue OIDC tokens to fork-triggered runs regardless of the declared permission. That is also why the fork path must not pick the server backend: it would fail asking for a token it can never have.
+- The mirror step keeps fork PRs warm. Their runs can restore only from GitHub Actions cache, and nothing would populate it if every trusted build used the server alone. Running the github backend alongside the server on `main` pushes saves the store after the build (action steps clean up in reverse order, so the mirror's save runs last), and fork PRs restore that entry.
+
+## Separate trust levels [​](#hardening)
+
+The single-workflow recipe above trusts the platform to withhold fork credentials. To make the trust boundary structural, split it in two: a router workflow whose `trusted` and `untrusted` jobs are mutually exclusive, each calling a shared `workflow_call` implementation with different permissions and inputs. [tak's ci.yml](https://github.com/jdx/tak/blob/main/.github/workflows/ci.yml) is a living example. This structure lets you enforce the following boundaries:
+
+- An untrusted run never declares `id-token: write` at all, and its first step can assert `ACTIONS_ID_TOKEN_REQUEST_URL` is absent.
+- Trust can be narrower than "same repository": tak only trusts one account, so a compromised collaborator token still cannot reach the server.
+- Each trust level can use its own runner pool, keeping fork code off self-hosted runners.
+- A `final` job asserts that exactly one route ran and succeeded, giving branch protection a single required check.
+
+Whichever shape you use, pin third-party actions to full commit SHAs in a real workflow; a mutable tag can be retargeted at any time.
+
+[Edit this page on GitHub](https://github.com/jdx/mr-boxington/edit/main/docs/cookbook/fork-prs.md)
+
+Last updated:
+
+Pager
+
+[Previous pageMigrate an existing cache](https://mr-boxington.jdx.dev/cookbook/migrate)
+
+[Next pageRemote cache](https://mr-boxington.jdx.dev/remote-cache)
+
+MIT License·Copyright © 2026· [jjdx.dev](https://jdx.dev)

package/skills/working-with-mbx/references/cookbook/local-development.md

@@ -0,0 +1,127 @@
+Local development
+
+Local development [​](#local-development)
+
+mbx can sit underneath the tools already in a Rust development loop. Editors, file watchers, terminals, and worktrees may all keep invoking ordinary Cargo; their compilations share the same cache and machine-wide scheduler. Start with [Cargo and editor setup](https://mr-boxington.jdx.dev/setup), then use the recipes below for your editor, watch loop, and machine budget.
+
+## Put editor checks through mbx [​](#put-editor-checks-through-mbx)
+
+The native mise Rust option wraps Cargo but does not configure rust-analyzer. Run setup to add the editor integration:
+
+sh
+
+```
+mbx setup
+mbx setup --status
+```
+
+Setup gives rust-analyzer's background check an absolute path to mbx's stable Cargo shim. That matters for editors launched from a desktop icon: they often do not inherit the shell activation that puts mise's Cargo wrapper on `PATH`. The override lands in rust-analyzer's user configuration file, so one run covers every workspace. Project-level `rust-analyzer.toml` files do not apply this override to the editor's Cargo process. Restart the editor after setup so rust-analyzer reloads its configuration.
+
+Setup leaves an existing rust-analyzer check configuration untouched. If `mbx setup --status` says that the editor kept its existing settings, either keep that command and make the editor inherit the shim directory printed by `mbx setup`, or change its `overrideCommand` executable to that absolute Cargo shim while preserving the command's existing arguments. Do not point the editor at a versioned mbx executable: the stable shim continues to work across upgrades.
+
+To check the path seen by a terminal, run:
+
+sh
+
+```
+command -v cargo
+mbx doctor
+```
+
+On Windows, use `(Get-Command cargo).Path` instead of `command -v cargo`. See [Cargo and editor setup](https://mr-boxington.jdx.dev/setup#verify-plain-cargo) for the shell and non-interactive `PATH` setup.
+
+## Run a watch loop [​](#run-a-watch-loop)
+
+A watcher does not need mbx-specific integration. Once plain Cargo resolves to the shim, every Cargo process it starts participates. For example, with [`cargo-watch`](https://github.com/watchexec/cargo-watch):
+
+sh
+
+```
+cargo install cargo-watch
+cargo watch -x 'check --workspace'
+```
+
+Use a second terminal for the live view:
+
+sh
+
+```
+mbx tui
+```
+
+The changed crate still has to compile, but unchanged dependencies can restore from any build or worktree on the machine. If another loop is already compiling the identical action, mbx waits for it and restores that result instead of running a duplicate compiler. The TUI makes both decisions visible by crate.
+
+An editor background check and a watcher may request much of the same work. That is safe, but Cargo still plans both builds; keep both only when the watcher runs a different command such as tests, Clippy, or another feature set.
+
+Do not add `cargo clean` to a watch loop. Cargo already rebuilds changed inputs, and deleting the target directory throws away its local freshness information. When a loop looks colder than expected, diagnose one iteration instead:
+
+sh
+
+```
+mbx explain check --workspace
+```
+
+## Keep a laptop responsive [​](#keep-a-laptop-responsive)
+
+All simultaneous mbx builds share one compiler pool. Its defaults use every logical CPU and 85% of physical memory, which favors throughput. A smaller machine-wide budget trades some cold-build speed for lower fan noise and more headroom for the editor and browser.
+
+Add a budget to the platform config file listed on the [Configuration](https://mr-boxington.jdx.dev/configuration) page:
+
+toml
+
+```
+[scheduler]
+cpus = 4
+memory = "8GiB"
+```
+
+Choose values for the machine; those numbers are an example. The CPU setting limits concurrent real compiler work across every terminal and worktree; cache hits do not consume permits. The memory setting prevents known large compilations from filling all CPU permits at once.
+
+For a watch session with a smaller shared budget, set the same values in its environment. Child Cargo processes inherit them. These are scheduler settings, so consider the other builds sharing that pool:
+
+sh
+
+```
+MBX_SCHEDULER_CPUS=2 MBX_SCHEDULER_MEMORY=4GiB \
+  cargo watch -x 'check --workspace'
+```
+
+`scheduler.priority = "low"` is useful for unattended or background builds, but it is not a power limit: it yields capacity to normal-priority builds and may still use the whole configured pool when nothing else is waiting.
+
+## Debug a binary restored from another checkout [​](#debug-a-binary-restored-from-another-checkout)
+
+Restored artifacts behave the same, but are not guaranteed to contain the same bytes as a local compile. In particular, debug information can contain the absolute source path of the checkout that populated the cache. A debugger may therefore open an old worktree path or fail to bind a breakpoint even though the program itself is correct.
+
+For a local final link while retaining cached dependency compilations, build into a separate target directory with native-link caching disabled:
+
+sh
+
+```
+CARGO_TARGET_DIR=target/debugger MBX_CACHE_LINKS=0 \
+  cargo build --bin my-program
+```
+
+Point the debugger at `target/debugger/debug/my-program`. The separate target directory forces Cargo to materialize a new build without disturbing the normal one, and disabling link caching makes the program itself local. This is usually enough to debug application code.
+
+If source paths inside every dependency must also belong to the current checkout, bypass mbx for the isolated build:
+
+sh
+
+```
+CARGO_TARGET_DIR=target/debugger-uncached MBX_DISABLE=1 \
+  cargo build --bin my-program
+```
+
+This build is cold and is best reserved for path-sensitive debugger or artifact investigations. Remove the extra target directory when finished; the shared action cache remains intact. To check whether restored bytes diverge, use [`MBX_VERIFY=1`](https://mr-boxington.jdx.dev/configuration#verify-mode).
+
+[Edit this page on GitHub](https://github.com/jdx/mr-boxington/edit/main/docs/cookbook/local-development.md)
+
+Last updated:
+
+Pager
+
+[Previous pageCargo & editor setup](https://mr-boxington.jdx.dev/setup)
+
+[Next pageManaged targets](https://mr-boxington.jdx.dev/managed-targets)
+
+MIT License·Copyright © 2026· [jjdx.dev](https://jdx.dev)

package/skills/working-with-mbx/references/cookbook/migrate.md

@@ -0,0 +1,67 @@
+Migrate from rust-cache or sccache
+
+Migrate from rust-cache or sccache [​](#migrate-from-rust-cache-or-sccache)
+
+Move one development or CI workflow at a time, verify activation, then compare a representative warm build. Keep production release jobs subject to the [release policy](https://mr-boxington.jdx.dev/github-action#production-releases).
+
+## From rust-cache or `actions/cache` over `target/` [​](#from-rust-cache-or-actions-cache-over-target)
+
+Replace the existing cache action with `jdx/mr-boxington-action`. Both actions can transport Cargo's target state, so using both for the same paths adds duplicate restore/save work. See [archive caching](https://mr-boxington.jdx.dev/compared#tarball-ci-caches).
+
+Before:
+
+yaml
+
+```
+steps:
+  - uses: actions/checkout@v7
+  - uses: Swatinem/rust-cache@v2
+  - run: cargo test --workspace
+```
+
+After:
+
+yaml
+
+```
+steps:
+  - uses: actions/checkout@v7
+  - uses: jdx/mr-boxington-action@v1
+  - run: mbx test --workspace
+```
+
+The action's default entry carries Cargo's target directory and its download caches under `~/.cargo`, so the workflow can retain dependency artifacts and Cargo downloads. The `github-cache-mode: objects` payload omits the download caches; use a separate Cargo-download cache if you need those files too.
+
+Production release jobs may use a trusted local cache, but should not restore compiler outputs from a remote or an Actions archive. See [Production releases](https://mr-boxington.jdx.dev/github-action#production-releases).
+
+## From sccache [​](#from-sccache)
+
+Both tools wrap rustc through `RUSTC_WRAPPER`, so they cannot be combined for the same build. With `RUSTC_WRAPPER` already set, mbx defers to the existing wrapper and warns that the build is not cached. Migration is removal: take sccache out of
+
+- `RUSTC_WRAPPER` in CI environments and shell profiles,
+- `build.rustc-wrapper` in `~/.cargo/config.toml`,
+- workflow steps that install or configure it ( `mozilla-actions/sccache-action`, `SCCACHE_GHA_ENABLED`, and similar).
+
+Then check the result:
+
+sh
+
+```
+mbx doctor
+```
+
+## Verify the migration [​](#verify-the-migration)
+
+Run `mbx doctor`, then your usual build. A cold object store needs work to fill it; a restored Cargo target may already be fresh and require no compilations. Neither result proves cross-target cache reuse. Follow [Measure cache reuse](https://mr-boxington.jdx.dev/cache-results#measure-cache-reuse) for a controlled comparison, and use `mbx explain --last` to understand any remaining bypasses.
+
+[Edit this page on GitHub](https://github.com/jdx/mr-boxington/edit/main/docs/cookbook/migrate.md)
+
+Last updated:
+
+Pager
+
+[Previous pageGitHub Action](https://mr-boxington.jdx.dev/github-action)
+
+[Next pageFork pull requests](https://mr-boxington.jdx.dev/cookbook/fork-prs)
+
+MIT License·Copyright © 2026· [jjdx.dev](https://jdx.dev)

package/skills/working-with-mbx/references/dashboard.md

@@ -0,0 +1,89 @@
+Cache dashboard demo | mr boxington
+
+[Skip to content](#VPContent)
+
+Return to top
+
+[mr boxington](https://mr-boxington.jdx.dev/)
+
+AC**Acme Engineering**Self-hosted
+
+Monitor
+
+Overview Namespaces Missing actions 24
+
+Manage
+
+Access Settings
+
+**Server healthy**
+
+v1.0.1 · us-east-1
+
+[View server docs ](https://mr-boxington.jdx.dev/cache-server)
+
+JD**Jordan Diaz**Administrator
+
+Acme Engineering*/***Overview**
+
+Demo dataJD
+
+Interactive preview with sample data. Changes stay in this page; no cache server is connected. [Read the server guide →](https://mr-boxington.jdx.dev/cache-server)
+
+Cache operations
+
+# Good morning, Jordan.
+
+Here’s how your build cache is performing.
+
+24 hours 7 days 30 days
+
+Hit rate
+
+**93.6%**↑ 1.8% *vs previous period*
+
+Requests
+
+**482,910**↑ 12.4% *vs previous period*
+
+Compute saved
+
+**1,042h**↑ 8.1% *vs previous period*
+
+Storage used
+
+**211 GB***of 500 GB*
+
+## Cache performance
+
+Hits and misses across all namespaces
+
+HitsMisses
+
+100%75%50%25%0%
+
+Aug 24Aug 25Aug 26Aug 27Aug 28Aug 29Today
+
+## Hit rate by repository
+
+Where your cache is working hardest
+
+View all →
+
+**acme/web**main**98.2%**
+
+**acme/api**main**96.7%**
+
+**acme/web**pull/\***91.4%**
+
+**acme/mobile**main**89.1%**
+
+## Top missing actions
+
+Highest rebuild cost this period
+
+View all →
+
+1**rustc · web\_server**acme/web · pull/1842**9m 42s**2,841 misses2**rustc · api\_graphql**acme/api · main**7m 18s**1,927 misses3**build.rs · openssl-sys**acme/mobile · main**4m 51s**1,612 misses4**rustc · integration\_tests**acme/web · pull/\***4m 06s**1,204 misses
+
+MIT License·Copyright © 2026· [jjdx.dev](https://jdx.dev)

package/skills/working-with-mbx/references/faq.md

@@ -0,0 +1,75 @@
+FAQ
+
+FAQ [​](#faq)
+
+Common questions about reuse, storage, and compatibility. For a specific build problem, start with [Troubleshooting](https://mr-boxington.jdx.dev/troubleshooting).
+
+## Is deleting the cache safe? [​](#is-deleting-the-cache-safe)
+
+The shared compiler outputs can be rebuilt. Prefer `mbx gc --dry-run` and `mbx gc` to reclaim space under the configured policy. Deleting the whole cache root also removes managed targets and private incremental state; stop running builds first. See [stability](https://mr-boxington.jdx.dev/stability#the-store-is-disposable).
+
+## Why wasn't my first build faster? [​](#why-wasn-t-my-first-build-faster)
+
+A cold store has no results to restore. The first compilation records inputs and outputs for later reuse. A second command in the same target may simply be fresh according to Cargo; use [fresh targets](https://mr-boxington.jdx.dev/cache-results#measure-cache-reuse) to measure the shared cache. See [cache results](https://mr-boxington.jdx.dev/cache-results#troubleshooting-a-low-hit-rate), and the [warm scenario](https://mr-boxington.jdx.dev/benchmarks#warm-build) for what that second build gets.
+
+## Why does a fully warm build still take time? [​](#why-does-a-fully-warm-build-still-take-time)
+
+Cargo still plans the build, mbx validates inputs and materializes outputs, and any unsupported actions run normally. Eligible host binaries and tests can be restored on Linux, macOS, and Windows; links with unmodeled inputs still run. See the [limits](https://mr-boxington.jdx.dev/limits#native-linking-is-cached-only-where-the-linker-can-be-described).
+
+## The cache stopped hitting after a Rust update. Is it broken? [​](#the-cache-stopped-hitting-after-a-rust-update-is-it-broken)
+
+No. The compiler is part of every key, so a toolchain roll invalidates every rustc action at once, and the build says so: `a manifest predicting N compilations was loaded, but none matched this build`. Actions that do not depend on rustc, such as a build script's C objects, survive.
+
+## Can I use mbx together with sccache? [​](#can-i-use-mbx-together-with-sccache)
+
+No. Both wrap rustc through `RUSTC_WRAPPER`, so they cannot be combined for the same build; with `RUSTC_WRAPPER` already set, mbx defers to it and does not cache. See [migrate from rust-cache or sccache](https://mr-boxington.jdx.dev/cookbook/migrate).
+
+## Are restored artifacts byte-identical to what a compile would produce? [​](#are-restored-artifacts-byte-identical-to-what-a-compile-would-produce)
+
+Equivalent, not always identical: rustc and C compilers record absolute source paths in metadata and debug information, so artifacts from two checkouts can differ without behaving differently. [`MBX_VERIFY=1`](https://mr-boxington.jdx.dev/configuration#verify-mode) compares bytes and names what differed. See [limits](https://mr-boxington.jdx.dev/limits#restored-artifacts-are-equivalent-not-always-identical).
+
+## Where does everything live? [​](#where-does-everything-live)
+
+`mbx cache dir` prints the store's location. Managed target directories live under that root by default; [`target.root`](https://mr-boxington.jdx.dev/managed-targets#change-target-placement) can place them elsewhere. Configuration comes from the paths listed in [Configuration](https://mr-boxington.jdx.dev/configuration).
+
+## How do I turn one feature off? [​](#how-do-i-turn-one-feature-off)
+
+Every feature has its own switch:
+
+| Switch | Turns off |
+| --- | --- |
+| `MBX_SCHEDULER=0` | [machine-wide compile scheduling](https://mr-boxington.jdx.dev/scheduling#machine-wide-compile-scheduling) |
+| `MBX_CC=0` | [build-script and `mbx exec` C and C++ caching](https://mr-boxington.jdx.dev/configuration#build-script-c-and-c) |
+| `MBX_TARGET_VIEWS=0` | [managed target directories](https://mr-boxington.jdx.dev/managed-targets#disable-managed-targets) |
+| `MBX_CACHE_LINKS=0` | [native link caching](https://mr-boxington.jdx.dev/limits#native-linking-is-cached-only-where-the-linker-can-be-described) |
+| `MBX_LEARNED_INCREMENTAL=0` | [learned incremental reuse](https://mr-boxington.jdx.dev/incremental#learned-incremental-reuse) |
+| `MBX_EVENTS=0` | [per-compilation event streams](https://mr-boxington.jdx.dev/tui#recording) |
+| `MBX_SAVINGS=off` | [the savings line](https://mr-boxington.jdx.dev/configuration#the-savings-line) |
+
+## Something looks wrong. What should a report include? [​](#something-looks-wrong-what-should-a-report-include)
+
+`mbx doctor --json`, a run with `MBX_LOG=debug`, and `MBX_BYPASS_LOG`. See [reporting a problem](https://mr-boxington.jdx.dev/troubleshooting#reporting-a-problem).
+
+## Why is it called Mr. Boxington? [​](#why-is-it-called-mr-boxington)
+
+The project is named after this cardboard box, christened “Mr. Boxington” by jdx's daughter while he was working on mbx. The name stuck.
+
+For non-English speakers
+
+The joke is in “Boxington”: it combines *box* with *-ington*, an ending familiar from English place names and surnames. The result makes an ordinary cardboard box sound like a distinguished gentleman.
+
+![A child kneeling inside a tall cardboard box decorated with a face and a strawberry](https://mr-boxington.jdx.dev/mr-boxington.jpeg)
+
+*The original Mr. Boxington.*
+
+[Edit this page on GitHub](https://github.com/jdx/mr-boxington/edit/main/docs/faq.md)
+
+Last updated:
+
+Pager
+
+[Previous pageBenchmarks](https://mr-boxington.jdx.dev/benchmarks)
+
+[Next pageConfiguration](https://mr-boxington.jdx.dev/configuration)
+
+MIT License·Copyright © 2026· [jjdx.dev](https://jdx.dev)

package/skills/working-with-mbx/references/getting-started.md

@@ -0,0 +1,147 @@
+Get started
+
+Get started [​](#get-started)
+
+mbx reuses compiler work across Rust workspaces, checkouts, and CI runs. Cargo still resolves dependencies and decides what needs building. mbx restores matching compilations and runs the compiler for everything else.
+
+You need an existing Rust toolchain and a Cargo project. No cache server or configuration file is required.
+
+## Install [​](#install)
+
+With [mise](https://mise.jdx.dev):
+
+sh
+
+```
+mise use --global --tool-option mr_boxington=true rust mr-boxington
+```
+
+This requires mise 2026.9.2 or newer. Drop `--global` for project-scoped wrapping. See [Installation](https://mr-boxington.jdx.dev/installation#mise) for older mise versions.
+
+Or install from crates.io:
+
+sh
+
+```
+cargo install mbx --locked
+```
+
+Linux, macOS, and Windows binaries are also available. See [Installation](https://mr-boxington.jdx.dev/installation) for verified downloads and platform requirements.
+
+## Run a build [​](#run-a-build)
+
+From your Rust workspace:
+
+sh
+
+```
+mbx doctor
+mbx build
+```
+
+Pass Cargo arguments as usual:
+
+sh
+
+```
+mbx test --workspace --all-features
+mbx clippy --workspace --all-targets -- -D warnings
+mbx +stable check --workspace
+```
+
+Cargo aliases, installed subcommands, and toolchain selection are preserved. Use the same toolchain, features, and profile across builds to reuse the same cached work.
+
+## Keep using plain Cargo [​](#keep-using-plain-cargo)
+
+The mise command above enables wrapping without running `mbx setup`. Use `mise exec -- cargo build`, `mise run` tasks, or plain `cargo` with mise activation or shims on `PATH`.
+
+For standalone installations, run:
+
+sh
+
+```
+mbx setup
+mbx setup --status
+```
+
+See [Cargo and editor setup](https://mr-boxington.jdx.dev/setup) to verify Cargo's path, share project configuration, configure rust-analyzer, and use mbx from desktop applications.
+
+## The first build [​](#the-first-build)
+
+A new local store has no compilations to restore. The first build fills it; later builds and equivalent worktrees can reuse that work. If Cargo already has up-to-date outputs in `target/`, it skips those compilations entirely. That is normal and will not appear as mbx cache hits.
+
+For a checkout without an existing `target/`, mbx creates a managed target and leaves a `target` symlink in the workspace. An existing directory is replaced only after you accept the interactive prompt. See [Managed target directories](https://mr-boxington.jdx.dev/managed-targets) for placement and cleanup.
+
+The first build also prints the cache location and disk budgets chosen for your machine. Automatic collection runs after builds, at most once an hour.
+
+## Read the result [​](#read-the-result)
+
+An illustrative summary looks like this:
+
+text
+
+```
+mbx[cache]: 139 hits, 8 misses, 4 not looked up, 147 prefetched, 7 bypassed; 312.4 MiB downloaded, 0 B uploaded, 280.1 MiB stored locally
+```
+
+| Result | What happened |
+| --- | --- |
+| Hit | mbx restored a matching compilation |
+| Miss | No result matched the key; successful compilation can fill the cache |
+| Not looked up | mbx lacked a usable input prediction and had to compile first |
+| Bypassed | The invocation ran without shared caching |
+
+To check reuse, build into two fresh target directories with the same command and options. The [cache reuse walkthrough](https://mr-boxington.jdx.dev/cache-results#measure-cache-reuse) shows the commands and explains why simply rerunning an up-to-date Cargo build may produce no mbx hits. Use `mbx explain --last` to inspect the last recorded build or `mbx tui` to [watch builds live](https://mr-boxington.jdx.dev/tui).
+
+## Inspect the store [​](#inspect-the-store)
+
+sh
+
+```
+mbx cache stats     # size and contents
+mbx gc --dry-run    # preview cleanup
+```
+
+A cache can always be rebuilt. Use the [management guide](https://mr-boxington.jdx.dev/managed-targets) to understand what each cleanup command removes.
+
+## Next steps [​](#next-steps)
+
+| I want to… | Read |
+| --- | --- |
+| Set up an editor or watch loop | [Local development](https://mr-boxington.jdx.dev/cookbook/local-development) |
+| Cache a GitHub Actions job | [GitHub Action](https://mr-boxington.jdx.dev/github-action) |
+| Run independent builds together | [Parallel builds](https://mr-boxington.jdx.dev/scheduling) |
+| Tune disk, output, or build policy | [Configuration](https://mr-boxington.jdx.dev/configuration) |
+| Understand an unexpected result | [Troubleshooting](https://mr-boxington.jdx.dev/troubleshooting) |
+
+<details>
+
+<summary>Looking for a section that moved?</summary>
+
+
+
+<a href="https://mr-boxington.jdx.dev/setup#verify-plain-cargo">Verify plain Cargo</a> now lives in the setup guide.
+
+<a href="https://mr-boxington.jdx.dev/installation#supported-platforms">Supported platforms</a> now lives in Installation.
+
+<a href="https://mr-boxington.jdx.dev/installation">Installation methods and Windows notes</a> have moved there too.
+
+<a href="https://mr-boxington.jdx.dev/linkers">Choose a linker</a> has its own guide.
+
+<a href="https://mr-boxington.jdx.dev/scheduling">Parallel builds</a> covers separate targets and shared budgets.
+
+<a href="https://mr-boxington.jdx.dev/troubleshooting#diagnose-the-installation">Installation checks</a> and <a href="https://mr-boxington.jdx.dev/troubleshooting#reporting-a-problem">Reporting a problem</a> now live in Troubleshooting.
+
+</details>
+
+[Edit this page on GitHub](https://github.com/jdx/mr-boxington/edit/main/docs/getting-started.md)
+
+Last updated:
+
+Pager
+
+[Previous pageDocumentation](https://mr-boxington.jdx.dev/guide)
+
+[Next pageInstallation](https://mr-boxington.jdx.dev/installation)
+
+MIT License·Copyright © 2026· [jjdx.dev](https://jdx.dev)